ARTS チェックイン 7 日目

A：290. 単語パターン #

パターンと文字列 s が与えられた場合、s が同じパターンに従っているかどうかを判断します。
ここで、「従う」とは、パターンの各文字と文字列 s の各非空単語の間に双方向の対応関係が存在することを指します。
例 1：
入力：pattern = "abba", s = "dog cat cat dog"
出力：true
例 2：
入力：pattern = "abba", s = "dog cat cat fish"
出力：false
例 3：
入力：pattern = "aaaa", s = "dog cat cat dog"
出力：false

function wordPattern(pattern: string, s: string): boolean {
  const arr = s.split(' ')
  if (pattern.length !== arr.length) {
    return false
  }
  const map = new Map()
  const patternAppearArr = Array.from(new Set(pattern.split('')))
  let resultPattern = ''
  let index = -1
  for (let i = 0; i < arr.length; i += 1) {
    const char = arr[i]
    if (map.has(char)) {
      resultPattern += map.get(char)
    } else {
      index += 1
      map.set(char, patternAppearArr[index])
      resultPattern += map.get(char)
    }
  }
  return resultPattern === pattern
}

提出結果：

41/41 ケースがパスしました（実行時間：68 ms）
ランタイムは、typescript の提出の中で 44.12％を上回ります
メモリ使用量は、typescript の提出の中で 73.53％を上回ります（42.1 MB）

パターンに現れる文字を記録し、文字列を一つずつパターンの文字にマッチさせると同時に、マッチ結果をマップに保存します。既に現れた文字は保存された値を使用し、現れていない文字は一つ前の文字を使ってマップに保存します。最後に、現在の文字列を表すパターンを取得し、パターンと一致するかどうかを確認します。

R：LLM パターンを問題にマッチさせる方法 #

著者は以前、LLM パターンの構築と適用についての記事を執筆し、それに関する質問を受け取りました。この記事では、これらのパターンを適用する際に人々が直面する可能性のある問題についてさらに探求しています。

外部モデルまたは内部モデル、データの強い関連性または弱い関連性#

外部モデルは、完全に制御できないモデルであり、ファインチューニングすることはできません。呼び出し速度やコンテキストの長さの制限を受ける可能性があり、機密またはプロプライエタリデータを送信したことに対する懸念もあります。それにもかかわらず、外部モデルのパフォーマンスは現在のところトップレベルです。

内部モデルは、自分自身で開発およびデプロイされるものであり、外部モデルの制約はありません。一般的に、オープンソースモデルのレベルは、商業モデルに数ヶ月または数年遅れています。

LLM のパターンを適用するためには、データがアプリケーションシナリオでどのような役割を果たしているかを理解する必要があります。データは主要なコンポーネントですか、それとも副産物ですか？または、データは無関係な要素ですか？

例えば、モデルの評価やファインチューニングはデータに強く関連しています。キャッシュ、ユーザーエクスペリエンスの保護のための防御策、出力品質の保護のための「フェンスモード」は、基盤となるインフラストラクチャに関連しています。

RAG（Retrieval Augmented Generation）とユーザーフィードバックは中間に位置しています。RAG は、in-context learning のためにプロンプトを埋める必要がありますが、検索インデックスのサービスも必要です。ユーザーフィードバックデータのフィードバックを受けてファインチューニングを行うには、ユーザーインターフェースの設計、データ分析、および依存データパイプラインの設計が必要です。

パターンを問題にマッチさせる#

以下では、いくつかの問題に対してどのパターンを適用するかを見ていきます：

特定のタスクのパフォーマンス測定が不足している場合：外部モデルまたは内部モデルの場合、プロンプトの変更、モデルのファインチューニング、または RAG プロセスの改善後、改善の程度を測定し、回帰テストを行う方法が必要です。また、新しいモデルの機能がユーザーに好まれるかどうか、調整がユーザーに与える影響を測定する必要があります。これらの問題には、「評価」と「ユーザーフィードバックの収集」のタスクが使用できます。
外部モデルのパフォーマンスが低い場合：これは、モデルのトレーニングデータが古くなっている、モデルに専用データが不足している、または生成時に十分なコンテキストがないためです。これらの問題には、RAG と評価が使用できます。評価は、検索後のパフォーマンスの向上を測定するために使用されます。
内部モデルのパフォーマンスが低い場合：モデルは、抽出、要約などのタスクで事実ではない応答、オフトピック、スムーズでない回答などを生成する可能性があります。この場合、ファインチューニングとユーザーフィードバックを検討することができます。
外部モデルに制約がある場合：呼び出し回数、トークンの長さなどの技術的な制約、または機密データの送信ができないか、API 呼び出しのコストが制約になっている場合。この場合、LLM のサプライヤーに連絡してローカルデプロイを試みるか、自分でファインチューニング、ユーザーフィードバック、評価を行う必要があります。
レスポンスがユーザーエクスペリエンスの要件を満たしていない場合：一部の使用シナリオでは、モデルが数百ミリ秒で応答する必要があります。データ品質を制御する時間も含まれます。ストリーミング出力はユーザーエクスペリエンスを最適化できますが、すべてのシナリオに適用できるわけではありません。この場合、キャッシュ、フェンスモードなどが使用されます。
カスタマーエクスペリエンスの保証：LLM は必ずしも正確な出力を提供するわけではありません。その場合、エラーハンドリングのためのユーザーエクスペリエンス保証措置を講じる必要があります。正しい期待値を設定し、効果的な無視と修正を行う方法が必要です。また、エラーが発生したことを認識し、その影響を緩和する方法も必要です。これには、防御的なユーザーエクスペリエンスとユーザーフィードバックが使用されます。
ユーザーへの影響の可視性が不足している：LLM アプリケーションをリリースした場合、実際の効果が悪化したかどうかを知る必要があります。モニタリングとユーザーフィードバックの収集が必要です。

T：pyannote-audio 音声アノテーション#

音声アノテーションモデルであり、オーディオ内で異なる人々の対話を区別し、各話者の発話時間を注釈付けすることができます。これに基づいてオーディオをセグメント化し、whisper モデルに入力して音声をテキストに変換することができます。これにより、複数の人々の対話が含まれるオーディオのテキスト変換が実現されます。

S：高速読みのテクニック#

読書中に視線を後戻りさせることを避けるようにしましょう。これにより、私たちの思考を文章に追随し、切り替えることが強制されます。最初は適応するのが難しいかもしれませんが、理解が難しくないコンテンツに対しては、前の内容を完全に理解しなくても文脈から理解することができます。

参考文献：

ARTS 打刻活動