AIチャットボットの調整に何週間も費やす。回答は正確だ。関係者の承認も得て、本番投入する。3か月後、そのシステムはユーザーからの質問のおよそ3分の1に対して、自信を持って誤った回答を返している。モデルは誰も変更しておらず、プロンプトにも誰も触れていない。変わったのは世界のほうだ。価格が変わり、ポリシーが更新され、製品仕様が新しいバージョンを出荷したにもかかわらず、その下にあるナレッジストアはそれに追随しなかった。

これは仮説ではない。現在の企業AIにおいて最も一般的な本番環境での障害モードの1つであり、AIシステムがどのようにデータを取得しているかにかかわらず、ほとんどのデータエンジニアリングチームにはそれを検知する適切なツールがない。企業がAIの試験導入から大規模な本番展開へ移行する中で — Gartnerは一貫してデータ品質をAI導入の最大の障壁の1つに挙げてきた — この種の障害は、時折起きる厄介事から体系的なリスクへと変わりつつある。

障害に見えない障害

AIアプリケーションにとって、取得元がベクトルストアなのか、ドキュメントインデックスなのか、API呼び出しなのかは関係ない。仕組みが何であれ、標準的な検索パイプラインには、提供しているものがまだ正しいかどうかを確認する機能はない。古くなった価格文書は、最新の文書と同じように自信を持って取得される。なぜならシステムが評価しているのは関連性や可用性であり、正確性ではないからだ。同じ理由で、密かにフィールドが欠落したレコードも、完全なレコードと同じように問題なく通過する。

したがって、この障害は設計上見えない。古いデータや不完全なデータでも関連性スコアは高くなるか、データパイプラインが実行するよう作られたすべてのチェックを通過する。取得されたコンテキストが権威あるものに見えるため、モデルは完全な自信を持って回答する。監視しているダッシュボードはすべて緑のままだ。システムは動いているように見える。ただ、間違っている。

私はAIの文脈以外でも、フィンテックのパイプラインでこれに似た事例を見たことがある。上流システムが下流の利用者に通知せずにフィールドを変更した。パイプラインは失敗しなかった。ジョブが完了したかどうかだけを確認し、データがまだ正しいかどうかを確認していなかったため、単に不正な値をダッシュボードへ伝播しただけだった。問題が表面化したのは、顧客が不整合に気づいたときだった。その時点で、不正なデータはすでに下流へ流れていた。

古くなった文書であれ、密かに欠落したフィールドであれ、障害の形は同じだ。エラーがないことは正確であることを意味しない。そして適切な検証レイヤーを構築しなければ、パイプライン内のどこにも問題を特定できるものはない。AIエージェントが質問に答える段階から行動を起こす段階へ移るにつれ、リスクも高まっている。古い価格や廃止されたポリシーに基づいて動くエージェントは、単に誤った回答を返すだけでなく、誤った取引を実行する可能性がある。

なぜこれはデータエンジニアリングの問題なのか

この障害に直面したチームは、原因を誤って診断しがちで、しかもそれを2度繰り返しがちだ。

モデルのせいにする: 最初の本能は、モデルを責め、別のLLMを試し、プロンプトを調整することだ。しかし本当の問題はさらに上流、データエンジニアリング層にある。これは前述のフィンテックの障害と同じ発想で、監視がデータではなくパイプライン向けに作られていることに起因する。

検索レイヤーのせいにする: モデルが原因ではないと判断されると、次の本能は検索レイヤーやコンテキストレイヤーを責め、より良いものを買うことだ。このタイミングは偶然ではない。企業がこれらのシステムを実際の本番環境へ押し出す中で、まさにこのギャップが表面化し始めており、ベンダー各社の反応も相次いでいる。AWSは、エージェントの利用状況から学習するナレッジグラフで「コンテキストレイヤー」競争に参入した。Snowflakeの新しいHorizon ContextとCortex Senseは、本稿の冒頭で取り上げた症状そのもの、つまりその下にあるビジネスロジックが管理されていないためにエージェントが自信を持って誤答する問題を対象としている。

どちらも現実の問題に対する現実的な対応だが、それらは問題の1つ上のレイヤーに位置している。ナレッジグラフであっても、それに供給されるものに依存する。本当の問題はさらに上流、データエンジニアリング層にある。チームはジョブが実行されたかどうかを確認するが、そのジョブが移動したデータが今も真実かどうかは確認しない。この発想はAIより何年も前から存在している。監視はパイプラインのために作られており、データのためには作られていない。

実際に欠けているもの: データ可観測性

データ可観測性はよく知られた概念だが、実際にどう実装されているかという点では十分な注目を集めていない。このカテゴリー自体は過去数年で成熟してきた。Monte Carlo Dataなどの企業が専用プラットフォームを構築し、IBMは2022年にDatabandを買収して自社のデータ可観測性能力を強化した。それでも、特に既存のデータインフラの上にAIアプリケーションを構築し始めたばかりのチームでは、導入状況にばらつきがある。

重要な指標はパーセンテージではなく、カバレッジだ。重要なデータセットのうち、リネージが誰かの頭の中にだけ存在するのではなく、実際にクエリ可能な形になっているものがどれだけあるかである。

Uberは、検索拡張生成が存在するずっと前から、専用のデータ品質・可観測性プラットフォームを構築していた。同社のUnified Data Qualityプラットフォームは、2,000を超える重要データセットをサポートし、データ品質インシデントの約90%を下流の利用者に届く前に検知している。

Netflixは、同じ問題の別の部分を解決した。全社的なデータリネージシステムを構築し、誰でもデータセットがどこから来て、その過程で何に触れられたのかを答えられるようにしたのだ。それはウェアハウスのテーブルだけでなく、Kafkaトピック、MLモデル、実験にまたがる依存関係をマッピングする。Uberと同様、このプラットフォームは人間のために構築されたものだが、AI/LLMアプリケーションの増加に伴い、今ではさらに重要になっている。

UberとNetflixを合わせると、構築する価値のある4つの要素のうち2つをカバーしている。実務上、私はそれをそれぞれ独自に測定可能な4つの次元として考えている。

正確性: 各レコードが本来あるべき形とルールに適合しているか。正しいフィールド型、予期しないnullがないこと、値が範囲内にあることなどだ。Great ExpectationsやSodaのようなツールはこの点をうまく扱う。何かが壊れた後の手作業の確認ではなく、行レベルおよび列レベルの自動検証を行う。実行ごとに検証を通過したレコードの割合を追跡する。

鮮度: データが最後にチェックされた時点で新しいだけでなく、ソースに対して今も最新かどうか。ソースごとに最後の正常更新からの経過時間を追跡し、すべてに一律のしきい値を適用するのではなく、データセットごとにSLAを設定する。一部のソースは1時間ごとの更新を必要とし、そうでないものもあるからだ。

一貫性: 同じ事実が、保存またはインデックス化されているあらゆる場所で同じように読めるか。これは静かに失敗する。同じソースから供給される2つのシステムが食い違い始めて初めて表面化する。下流の宛先間で定期的にクロスチェックし、不一致率がしきい値を超えたらフラグを立てるだけで、早期に検知するには十分だ。

リネージ: 任意の出力を、そのソースと通過したすべての変換までさかのぼれるか。これはNetflixが自社システムで答えられるようにした問いと同じだ。

これらのどれも、ほとんどのデータチームがすでに持っていないインフラを必要としない。私はそれを主張しているだけでなく、実際に構築したことがあるので分かる。

Socureでは、顧客データは顧客が送りたいと思ったどんな形でも届き、ときには静かに誤っていた。課題は、誤ったデータが下流へ伝播する前に特定できるシステムを構築することだった。同じ原則が適用された。到着したものを検証し、それがどこから来たのかを理解し、不正なデータが他者の問題になるのを防ぐことだ。

Great Expectationsはその基盤の一部になった。取り込み時のスキーマと範囲の検証、鮮度に関するソース別SLA、一貫性のためのシステム横断チェック、ファイルレベルのリネージである。これらはすべてwrite-audit-publishパターンの背後に置かれ、データはステージングに到着し、検証され、必要なチェックに合格した場合にのみ下流へ移動した。

その結果は下流に現れた。レポーティング、MLモデル、そして同じデータの上に構築されたAI検索のすべてにおいて、全体的に精度が向上した。

月曜の朝に何をすべきか

本番環境で検索ベースのAIシステムを運用しているなら、診断すべき問いは次にどのモデルを試すか、あるいはどの検索アーキテクチャへ移行するかではない。もっと絞った4つの問いだ。

1. 基盤となるデータは、その利用者が求める基準に照らして検証されているか。
2. 現在、高い信頼度で提供されている最も古いコンテンツは何か。
3. 同じソースの2つのチャンクが、同じ検索結果の中で互いに矛盾する可能性はあるか。
4. それが間違っていたと判明した場合、どこから来たのかをたどれるか。

これらの問いに答えられないなら、ギャップはソースシステムとエージェントが読み取るものとの間のパイプラインにある。それはデータエンジニアリングで修正すべき問題であり、モデルの差し替えやベンダー移行ではない。

レポーティングパイプライン、MLシステム、AIエージェントのいずれを構築している場合でも、データを信頼できるものにするのは正確性、鮮度、一貫性、リネージだ。AIは、データエンジニアリングに以前から存在していた弱点を露呈させているにすぎない。