頻度は重要度ではない：失敗に終わった順位付けの軸

私たちは、最も重要な用語が厳しく予算化されたプロンプトに収まるように、ドメインボキャブラリーをランク付けする必要がありました。明白なシグナルは頻度でした。信頼できるコーパスで各用語がどれくらいの頻度で出現するかを数え、そのカウントでランク付けすれば完了です。私たちはそれを構築し、測定したところ、上位20の用語は「consultation」、「treatment」、「face」、「reservation」、そして一般的なモデルがすでに完璧に知っている他の16の単語でした。ブランド名は一つもリストに入りませんでした。特徴的なボキャブラリーを促進するために構築した軸が、まさに促進する必要のないボキャブラリーを促進していたのです。

この記事では、なぜ頻度が重要度のシグナルとして失敗したのか、その失敗の前に私たちが回避した2つの罠（使用状況から導出された頻度と生のカウント数）、そして実際に私たちを救った部分、つまり、コードと動作変更の間に分布チェックを設けることで、その軸が安価に失敗できるようにロールアウトを設計したことについて説明します。

セットアップ：30のスロット、数千の候補

このランキングの利用者は、音声認識のためのキーワードバイアスプロンプトでした。プロンプトには厳格なトークンバジェットがあり、実際には約30の用語が収まります。語彙データベースには、数千の確認済み用語が保持されています。私たちが選択するランキング関数が、語彙のどの1パーセントが文字起こしに影響を与えるかを決定します。それ以外のものは、存在しないも同然です。

既存のランキングでは、ソース信頼階層（手動入力された用語 > サイトからマイニングされた用語 > 機械生成された用語）を使用し、トークンコストを同順位決定要因としていました。問題は分布の中間層にありました。数千の用語が同じ階層を共有し、階層内では同順位決定要因が短い文字列を優先していました。人間の語彙における短い文字列は、一般的なものに偏る傾向があります。システム全体が文字起こしするために存在するブランド名がカットオフの下に位置する一方で、2文字の日常的な単語がプロンプトの最上位に浮上していました。

頻度が解決策のように見えました。重要な用語はドメインテキストに頻繁に現れるべきであり、不明瞭なノイズはそうであってはなりません。その直感は間違ってはいませんが、重要な点で不完全です。

第一の罠：使用頻度が自身の誤りを増幅させる

最初の候補コーパスは、私たち自身の使用ログ、つまりユーザーが実際に話した内容の書き起こしでした。これは実際の需要を反映しているため、最も魅力的なコーパスです。しかし、それを生成するパイプラインが修正しようとしているパイプラインそのものである場合、それは巧妙な形で汚染されています。

私たちの文字起こしエンジンは、あるブランド名を、似た響きの競合用語として誤認識していました。使用コーパスでは、正しい用語が1回出現するのに対し、間違った用語は12回出現していました。なぜなら、コーパスは話者が言ったことではなく、エンジンが書き取ったものを記録するからです。そのコーパスでランク付けすると、誤認識がバイアスプロンプトに昇格し、それによってエンジンは間違った用語への確信をさらに深め、その頻度をさらに増大させます。誤りが自らの増大を招くのです。

私たちが得た教訓は、「ランキングが修正しようとしているシステム自体の出力から、ランキングシグナルを導き出してはならない」ということです。この形のフィードバックループは、自らその存在を知らせることはありません。ただ静かに失敗モードに収束していくだけです。

罠その2: 生のカウントはコンセンサスではなく繰り返しを優遇する

2番目の候補は、信頼できるドメインのウェブサイトからのクロール頻度でした。テキストが認識エンジンを通過することがないため、これはフィードバックループを回避します。しかし、生の出現回数には独自のバイアスがあります。すべてのページ (ナビゲーション、フッター、プロモーションバナー) で用語を繰り返す単一のサイトが、それぞれ異なる真に重要な用語に一度だけ言及する10個のサイトを、数で上回ってしまう可能性があるのです。

私たちは統計情報を、生のカウントからソースレベルでの文書頻度に切り替えました。つまり、この用語はいくつの異なるサイトに出現するのか？ということです。7つの独立したクリニックにまたがって表示される用語は、ドメイン全体の共通認識です。1つのクリニックのサイトに400回出現する用語は、そのクリニックのマーケティングです。また、信頼階層を圧倒することなくその間の同点を解消できるように、軸に小さな最大値を設定しました。

これは、間違ったアイデアに対する正しい改良でした。それは操作と偏りを修正しましたが、それでも中心的な問題を修正することはできませんでした。

計測：結局は一般的な単語が勝つ

カウント、重複排除、出典元特定機能を構築・テストした上で、ライブランキングにその軸を組み込む前に、28のサイトでカウンターを実行し、分布のトップを確認しました。文書頻度によるトップ20は次の通りです。

カウンセリング、施術、顔、輪郭、トリートメント、予約、痛み、炎症、額、組織、ボディシェイプ、胸、弾力、脂肪、リフティング、フィラー、その他同様の性質を持ついくつかの単語。これらはすべて、どの音声モデルでも初期設定のままで正しく書き起こせる単語です。ブランド名は一つもありません。

後から考えれば、この結果は明らかです。文書頻度は、複数の情報源にわたる合意度を測るものであり、独立した情報源が最も合意するのは、日常的な言語です。どのクリニックも「カウンセリング」や「予約」と書きますが、特定の機器や製品を扱っているのは一部だけです。専門的なコーパスでは、出現範囲の広さは、分布のトップにおける一般性と相関します。私たちが求めていた特徴的な語彙は、その中間に存在します。つまり、いくつかの情報源には存在するが、両極端には存在しないのです。

頻度とは、どのような種類のものであれ、「この用語はどれくらい一般的か？」という問いに答えるものです。私たちの目的における重要度とは、「この用語についてモデルはどの程度の助けを必要とするか？」ということでした。これらは、ほとんど正反対の問いです。モデルが助けを必要とする用語とは、まさに一般的なテキストではあまり表現されていない用語なのです。

うまくいった部分: コードと振る舞いの間のゲート

これが、高くつく失敗になるのを防いだ要因です。計画レビューの際、あるレビュー担当者がまさにこのリスクを指摘しました。クロール頻度が一般性と相関し、ジャンクを格下げするのではなく、逆に格上げしてしまう可能性があるというものです。私たちは議論でその問題を解決できなかったため、測定を中心としてロールアウトを再構築しました。

• その軸は、ユニットテストによって検証される不変条件付きで実装されました。つまり、すべての用語の頻度がゼロの場合、ランキングは古いランキングとバイト単位で同一になります。データが空であることは、その軸が存在しないことを意味します。
• 頻度テーブルは、スケジュールされたパイプラインではまだ意図的に有効化されていない、別のバッチステップによって入力されました。
• データ入力と採用の間には、文書化されたゲートが設けられました。分布の上位20件を検査し、もしそれが特徴的なドメイン用語で占められている場合は、その軸を採用します。もしそれが一般的な単語で占められている場合は、テーブルを切り捨て、採用をスキップします。

ゲートは失敗しましたが、その失敗は安価なものでした。私たちはテーブルを切り捨て、軸のコードをそのゼロデータの不変条件の背後で休止状態のままにし、事前に指定していたフォールバックをシップしました。それは、測定によって表面化した一般的な単語を取得し、プロンプトから用語を完全に除外するストップワードリストに追加するというものです。測定は無駄にはなりませんでした。それは、直感ではなくデータに裏付けられた、望みうる最高のストップワード候補を生成したのです。

一般的なパターンは次のとおりです。ランキングシグナルがもっともらしいものの未証明である場合、メカニズムとデータを別々にシップし、それらの間に分布チェックを置き、「失敗」がどのようなものか、そしてフォールバックが何かについて事前にコミットします。代替案、つまり軸を本番環境に直接組み込み、品質メトリクスの変動を監視して評価する方法は、数週間を要し、システム全体への信頼を損ないます。

頻度の代わりに使用するもの

そのゲートは、我々により鋭い問いを突きつけました。頻度でないとすれば、何が「モデルがこの用語について助けを必要としている」ことを予測するのでしょうか。事後検討の結果、次の3つのシグナルが残りました。

• トークナイザーの断片化。モデルのトークナイザーが多くのピースに粉砕する用語は、モデルがほとんど見たことのない用語です。これは、コーパスを一切使わず、語彙のみからオフラインで計算可能であり、我々の以前の測定では、ブランド名と日常的な単語をきれいに分離しました。
• 観測された誤認識。本番環境のインシデントから収集された、実際の誤認識の辞書は、ブースティングが必要な正確な用語を特定します。それは小規模ですが、すべてのエントリはグラウンドトゥルースです。
• 中間帯の文書頻度。頻度を使用するとすれば、有用なのは中間帯、つまりいくつかの独立したソースには存在するものの、そのすべてに存在するわけではない用語です。分布の最上位は一般的なものであり、最下位はノイズです。

これらのどれも、単なるカウントほど簡単ではありません。むしろ、それが要点なのです。

コーパスから導出されたランキングシグナルを本番適用するためのチェックリスト

• 修正しようとしているシステムによって生成されたコーパスでランキングしてはならない。閉じたループは自身の誤りを増幅させる。
• 生のカウントよりも、独立したソースを横断した文書頻度を優先し、より強力なシグナルを支配しないように軸に上限を設ける。
• 採用する前に、メトリクスの説明ではなく、分布の実際の最上位を見ること。見る前に合格基準を決定すること。
• 「データなし」が証明可能に「古い挙動」と等しくなるように、ゼロデータ不変条件で軸を実装し、データ投入と採用を別々のスイッチとして維持する。
• フォールバックを事前に決めておくこと。我々の場合は、データ駆動のストップワード拡張であり、それは失敗した軸を有用な副産物に変えた。
• 頻度が何を測定しているかを忘れないこと。一般性と重要性は、まさに語彙が専門化されているときに異なる方向を指すが、それはそもそもランキングが必要となる唯一のときである。

その軸はまだコードベース内にあり、休眠状態である。ゲートを通過するシグナルをいつか見つけられれば、採用はバッチジョブ1つで済む。それまでは、ゲートはその役目を果たした。本番環境ではなくスプレッドシート上で、もっともらしいアイデアを失敗させてくれたのだ。