最初に壁にぶつかります。RAG パイプラインには「目に見えない」コンテキスト インジェクション レイヤーが存在します。
3 か月前、私は大規模なモデルに基づいた顧客サービス アシスタント プロジェクトを引き継ぎました。タスク自体は複雑ではありません。ナレッジ ベースから関連ドキュメントを取得し、プロンプトを入力してモデルに回答させます。初期のプロトタイプはスムーズに動作しましたが、製品化されるとクラッシュしました。モデルは取得したコンテンツを頻繁に無視し、独自の答えを作成することがありました。
2 日間のトラブルシューティングを経て、最終的に、問題は取得にあるのではなく、プロンプト構築層にあると判断しました。コードには、取得したテキストをシステム メッセージに直接挿入するロジックが含まれていますが、トークンの順序、冗長情報、役割の識別は考慮されていません。その結果、モデルには明確なコンテキストの代わりに「ノイズの山」が生じます。 Context Engineering の本当の意味に真剣に向き合ったのはこれが初めてでした。それは単なるプロンプトのつなぎ合わせではなく、構造化、優先順位付け、一貫性を担当する専用のエンジニアリング層でした。
私の判断方法を大きく変えた 3 つの結論
1. コンテキストは多いほど良いですが、「整合性」が高いほど良いです
初期の頃は、検索結果をすべて表示したいと常に思っていて、それらを見逃すのではないかと心配していました。ただし、運用ログでは、コンテキストの長さがモデルが効果的に利用できるウィンドウ (4K トークンなど) を超えると、精度が低下することが示されています。その後、「関連性スコア + 動的トリミング」に切り替えました。上位 3 クリップのみを保持し、各クリップが 200 トークンを超えないよう強制しました。結果はすぐに現れ、回答精度は 68% から 91% に向上しました。
2. コンテキスト挿入の順序は推論の品質に直接影響します
最初は、最も簡単だと考えて、ナレッジ ベースのフラグメントをユーザー メッセージの最後に置きました。結果モデルは後半を無視することがよくあります。文献を検討した結果、このモデルは始まり (初頭性効果) と終わり (最新性効果) に対してより敏感であることがわかりました。そこで、最も重要な事実をシステム メッセージの先頭に置き、二次的な情報をユーザー メッセージの最後に置きました。調整後、重要な情報の引用は 55% から 87% に急増しました。
3. コンテキストの「明示的な境界」を設計する必要があります。
モデルは、どのコンテンツがナレッジ ベースの信頼できる事実であり、どのコンテンツがユーザー自身の推測であるかを知りません。以前はタグを付けていなかったので、ユーザーが何気なく言った誤った情報をモデルが事実として認識してしまうことが多かったです。その後、各知識断片の前に [来源：知识库] を強制的に追加し、システム メッセージに「情報がソースを示す場合にのみ使用し、それ以外の場合は無視する」という明確な指示を作成しました。これは簡単なようですが、錯覚を大幅に軽減します。
私たちが遭遇した 3 つの落とし穴とその修正方法
落とし穴 1: コンテキスト挿入ポイントが間違った位置にある
最初は、API 呼び出しの前にすべてのコンテキスト処理ロジックを関数に入れ、サービスに分割しませんでした。その結果、注入戦略を調整するたびに、ビジネス コードを変更する必要がありました。導入サイクルは 3 日で、反復には非常に時間がかかりました。訂正: Context Engineering を独立したミドルウェア層に分割し、構成ドライバーを通じて戦略を挿入します。変更後、実験の反復は数時間に短縮されました。
落とし穴 2: コンテキストの競合への対処を忘れる
テストでは、知識ベースは「製品 A の価格は 100 元」と「製品 A の価格は 150 元（割引前）」という 2 つの相反するバージョンを同時に返しました。モデルはランダムに 1 つを選択し、ユーザーはそれを繰り返し確認する必要がありました。修正: 競合検出ロジックを追加しました。同じエンティティに異なる値が表示される場合、両方のバージョンが自動的に表示され、ソースと有効期間がマークされます。これ以降、ユーザーからの苦情は 80% 減少しました。
落とし穴 3: コンテキスト キャッシュの影響を過小評価する
重複トークンを減らすために、モデル API のコンテキスト キャッシュ機能を使用しました。しかし、キャッシュ キーの設計が大まかすぎることに気づきませんでした。システム プロンプトが変更されない限り、キャッシュは再利用されます。その結果、ユーザーの質問が異なる場合でも、キャッシュでは古いコンテキストが使用され、回答が不正確になります。修正: ユーザー クエリのダイジェスト ハッシュをキャッシュ キーに追加します。その後、キャッシュ ヒット率は 10% しか低下しませんでしたが、一貫性の質問に対する答えはゼロに戻りました。
最初にコピーする最も価値のあるステップ: ログから始めます
Context Engineering も導入したい場合は、戦略を先に書くのではなく、ログを先に作成してください。具体的な方法:
- コンテキストを注入するコードで、注入時のトークンの数、各フラグメントのソース、優先度スコア、注入場所が含まれる「コンテキスト監査ログ」を出力します。
- 「注入されたもの」と「モデルで実際に使用されたもの」を比較します。簡単な方法は、各リクエストの後に最終的に生成されたプロンプト (コンテキストを含む) を記録し、手動で確認することです。
- 文脈品質レポートを毎週作成します。どの断片が無視され、どの断片が誤って引用され、どの断片が幻覚につながるのか。
この習慣を身につければ、推測に頼るのではなく、データに基づいて戦略を最適化できるようになります。私のチームは 2 週間ログを使用し、これまでのすべての戦略の抜け穴を発見しました。
永続化する場合とルートを変更する場合
Context Engineering の効果的な境界は、関連性の高いソース テキストをシステムが安定して取得できるかどうかにあります。検索再現率が長期間にわたって 40% を下回る場合は、まず検索を修正し、状況に応じた方法で埋め合わせようとしないでください。複数ラウンドのダイアログでモデルがコンテキストを頻繁に失う場合は、注入戦略を繰り返し作成するのではなく、拡張ウィンドウ モデルまたはプラグイン メモリ モジュールを優先します。
さらに、チームが毎週コンテキスト形式の調整に時間の 50% 以上を費やしているが、その効果が明らかでない場合は、停止して、構造化された出力制約に切り替える必要があるか、モデルを微調整する必要があるかを評価することをお勧めします。私は、あるチームが半年で 5 回も注入戦略を変更しましたが、その精度は常に 75% にとどまったという事例を見たことがあります。その後、関数呼び出しを使用して構造化された事実を直接抽出することに切り替えたところ、精度は 94% にまで跳ね上がりました。
変換方向の次のステップ
Context Engineering は、AI エンジニアリング システム内の単なるリンクです。普通の開発者からエージェント システムを独自に設計および最適化できるエンジニアに変身したい場合は、コンテキスト管理、ツール オーケストレーション、ループ制御などの高度なトピックを詳細にカバーする、当社のチームがまとめた有料記事シリーズ「エージェント エンジニアリング プラクティス」を読むことをお勧めします。
コメントはまだありません