このページの内容
月曜日に商品カタログが変わるとします。しかしアシスタントのプロンプトには金曜日の一覧が残っています。チームがプロンプトを更新しても、モデルの学習例には古い一覧の別のコピーがあります。同じ会話で、アシスタントが最新の答えと古い答えを一つずつ返すようになります。
これは例示的な失敗ですが、仕組みはよくあります。一つの事実に複数の置き場所ができたのです。
プロンプト、検索、モデルの重みに関する講演は有用な境界を示します。プロンプトは振る舞いを伝えます。検索は、その課題に必要な現在の、出典を示せる知識を運びます。モデルの調整は安定したパターンを教えられます。プロンプトから始め、次に検索し、それでも答えが違えばファインチューニングするという階段として考えると、事実の誤りを見誤ります。
プロンプトはカタログに向かない
プロンプトは編集しやすいため魅力的です。一段落足せば次の要求に含まれます。ただし、その便利さには二つの費用があります。関係ない呼び出しにも毎回その事実を送ります。プロンプトが大きくなると、モデルがルールのどのコピーを使ったかも分かりにくくなります。
「キャンペーン送信前に確認を求める」といった長く通用する指示は、エージェントの近くに置くべきです。しかし、この店舗の現在のカスタムフィールド一覧は違います。管理者が属性を追加すれば変わり、テナントによって異なり、あるワークスペースでは見えても別のワークスペースでは禁止されるかもしれません。
Brevo コネクターガイドは、連絡先の同期でフィールド定義が重要な理由を示します。送信先アカウントで属性が宣言されていなければ、名前からもっともらしく見えた対応付けでも意図したフィールドは作られないかもしれません。エージェントは学習時の一般的な一覧を思い出すのでなく、アカウントの現在の契約を調べるべきです。
役立つ検索結果は、異議を唱えられる程度に小さくなければなりません。対象のアカウントやテナント、読み取った時刻、説明する操作やフィールドを示します。二つの検索結果が食い違うなら、より流暢なほうを黙って選ばず矛盾を見せます。次に必要なのは新しい照会や審査であり、プロンプトの言い回しを強めることではないかもしれません。
範囲を伴う事実を取り出す
役立つ知識レコードは文章以上のものを持ちます。出典、版または取得時刻、アカウントの範囲、削除や交換の方法が必要です。ある店舗アカウントで見つかったフィールド定義を、別の店舗の普遍的なルールにしてはいけません。
連絡先の属性について尋ねられたら、答えに必要な最小の箇所、つまり名前、型、存在するアカウントを取得できます。答えからその資料へ戻れるようにします。対応付けが失敗したときは、事実が古かったのか、別のアカウントの結果が返されたのか、正しい箇所をモデルが誤解したのかを調べられます。
修正方法はそれぞれ違います。テナント境界を越える検索フィルターは、プロンプトを調整しても直りません。誰も取得していない属性定義を、大きなモデルが補うこともできません。
MCP の解説は、エージェントがツールで照会する方法を扱います。ツールは関係する契約を返し、アプリケーションが閲覧権限を強制すべきです。「ほかのテナントを漏らさない」という文章は、範囲を限定した照会の代わりにはなりません。
この分担は修正も速くします。送信先フィールドの名前が変わったなら、スキーマの資料を更新し、影響する対応付けを無効化します。安定した指示を何度も誤解するなら、指示を変えるか、対象を絞った学習方法を試します。検索が別のアカウントを選んだのなら、モデルの重みを直しても原因は残ります。誤りの種類ごとに責任者と修正経路が違います。
- 長く通用する指示
アシスタントの振る舞い
- 範囲を絞った検索 アカウント · 版 · 時刻
今正しいこと
- 対応付けの判断
この課題に現在の事実を使う
- 権限を検証した書き込み
コードが許可と範囲を確認
パターンが安定してから教える
「頻繁に使う事実なら、小さなモデルに学習させればよいのでは」という反論はもっともです。しかし反復だけでは不十分です。モデル更新の間も事実が正しく、文脈を区別できなければなりません。
安定した分類の様式は、いずれ調整に値するかもしれません。提供元の現在のフィールド一覧は不向きです。まれにしか変わらなくても、一つの古い答えが多くのレコードに誤った対応付けを広げます。人が調べて更新できる場所に事実を置きます。
講演は、あらゆる推論の失敗を検索で解決しないようにも警告します。モデルが関係する二つの文書を正しく比較できないなら、文書をさらに50件加えても比較する力は身に付きません。まず適切な箇所が届いたかを問い、次にその箇所に対する判断が妥当だったかを問います。
連携を作る人にとって、修復の順序はこうです。誤った主張を特定し、取得されたフィールドや API の箇所を調べ、アカウントと版を確認し、必要なら資料か検索経路を直し、判断を再テストします。その後で初めてモデルの変更を考えます。
実際に運用する知識の層には費用がかかります。資料の更新、アクセス確認、出典表示が必要です。しかし、事実を一か所で訂正できるようになります。
変わった契約を、モデルが忘れるまで待たせるべきではありません。
よくある質問
エージェントのプロンプトには何を入れるべきですか？
振る舞いと境界についての小さく長く通用する指示です。変わるカタログ、テナント固有のフィールド一覧、現在の提供元ルールは、必要なときに許可された資料から取得します。
現在の文書でモデルをファインチューニングしてはいけませんか？
調整すると、変わる事実が調べたり更新したりしにくい重みに組み込まれます。まず判断時点に正しい文書が取得され、出典を示せることを確認します。
事実の誤答はどう修復しますか？
元の文書、その版、検索フィルター、返された箇所を調べます。モデルを変える前に、事実または取得経路を訂正します。