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 ミリ秒）
ランタイムは、typescript の提出の 44.12％を上回ります
メモリ使用量は、typescript の提出の 73.53％を上回ります（42.1 MB）

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

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

著者は以前、LLM パターンの構築と適用についての記事を執筆し、その後、これらのパターンを具体的な問題と対応させる方法についての質問を受け取りました。この記事では、これらのパターンを適用する際に発生する可能性のある問題についてさらに探求しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

参考文献：

ARTS 打刻活動