答えの背後には何があるのか

AIが生成した答えを読むとき、私たちはまず文章に目を向けがちです。意味は通るか。質問に応えているか。使える内容か。

その答えを判断の根拠にするとき、別の問いが生まれます。どの情報を使ったのか。有効だったのはどの版か。システムにはアクセス権限があったか。情報源は実際にモデルへ届いたか。答えを裏付けていたか。

こうした問いは、目に見える答えから、それが生まれた条件へと私たちを導きます。

公開したNage AI OSとSEDIMのホワイトペーパーは、その条件を可視化し、検証できる形にする方法を扱っています。中心にあるのは、組織がAIの答えについて、どのような証拠から何を確かめられるかという問いです。

情報源の道筋をたどる

文書がシステム内に存在することと、ある答えに使われることの間には、いくつもの段階があります。

文書は受け入れられ、リクエスト用に選ばれていても、文脈の組み立て時に長さの制限から外れるかもしれません。正しい情報源を見つけても、必要な情報がモデルへ届かないことがあります。

情報がモデルへ届いても、確認は終わりません。入力に一文が存在するだけでは、答えがそれに基づいて生成されたとは言えません。別の情報を繰り返したり、情報源を読み違えたり、それと矛盾する答えを出したりする可能性があります。

そのため本研究では、情報源の選択、最終入力への存在、主張への裏付け、答えへの因果的影響を別々に扱います。それぞれが異なる問いに対応し、異なる観察や実験を必要とします。

この区別には実用的な意味があります。問題が起きた段階を見分けられれば、何を直すべきかを、より明確に話し合えます。

知識にはライフサイクルがある

組織の知識は変わり続けます。指針が改訂され、文書が古くなり、情報源の利用許可が取り消されます。

そのような環境では、アクセスできるだけでは足りません。知識の識別情報、版、アクセス範囲、利用状態も管理する必要があります。

SEDIMは、Nage AI OSの中でモデル、知識、証拠を扱うアーキテクチャとして、この管理に取り組みます。Nage AI OSは、モデルの実行を、こうした制御、観察、後から調べられるリクエスト記録と一緒に考える枠組みを示しています。

重要な問いの一つが、知識の利用停止です。もう使うべきでない情報について、システム内で何が行われるかを明示する必要があります。稼働中の利用から外すこと、保存されたコピーを削除すること、事前学習済みモデルのパラメータに含まれうる情報を取り除くことは、それぞれ異なる操作です。一つが完了しても、残りの完了は示せません。

「更新済み」「削除済み」という短い言葉の背後には、範囲を明示すべき技術的判断があります。

記録は何を示せるか

後から答えを調べるには、その時点の条件が必要です。どのモデル、情報源の版、アクセス方針を使ったか。どの観察結果が得られたか。利用者へ何が届いたか。

署名付き記録は、開示された記録内容の完全性と署名を確認する助けになります。しかし、それだけで答えの正しさや、システム内のすべての出来事が記録されたことを示すものではありません。

この境界は大切です。何を検証できるかを明確にすることで、検証手段の価値を守れます。

測定できなかった場合にも、同じ明確さが求められます。得られない値をゼロで置き換えても、不確実性はなくなりません。見えなくなるだけです。値を出せなかった理由を記録することが、最も意味のある出力になる場合もあります。

研究そのものも検証できるべきである

ホワイトペーパーには、測定したエンジニアリング結果と、設計目標、受け入れ試験を待つ機能が併記されています。その状態を分けて示すことも、本稿の中心的な問いの延長にあります。

特定の条件で観察した結果を、すべての用途へ広げることはできません。ローカルでの検証が、本番環境で同じ振る舞いを保証するわけでもありません。アーキテクチャの記述と、すべての受け入れ条件の達成との間には、まだ作業が残ることがあります。

そこで、結果を方法と限界とともに読める技術的証拠の付録を添えて公開しました。CRATONのネイティブモデル研究も、独自の評価要件を持つ別の研究経路として扱っています。

こうした区別を保つことが、研究を進める条件になります。

答えを使うかどうか判断する際、追加の証拠、最新の情報源、人による確認が必要になることがあります。Nage AI OSとSEDIMが取り組むのは、その必要がどこで生じるかを、より明確に見えるようにすることです。

答えのそばに、もう一度問い直すための痕跡が残ること。

ホワイトペーパーと技術的証拠の付録