存在しなかった表

第2章 — 存在しなかった表

ある機械メーカーの技術者が、エスプレッソを飲みながら、穏やかなヴェネツィア訛りでこう語ってくれました。「私たちのチャットボットは、エンジンに関するあらゆることを知っていました。エンジンのデータだけは、です。」そして説明を続けました。彼らの社内AIアシスタントは、製品ラインナップ、使用状況、ブランドの歴史、競争上の優位性などを説明することができました。物語としては素晴らしいものでした。しかし、顧客がモデルCMP50Lの公称トルクを尋ねると（つまり、カタログを開くための技術データ、エンジンを購入するための数値）、チャットボットは曖昧に、時にはもっともらしく、時にはそうでない答えを返しました。5ヶ月の開発、ますます困惑する業務部長、そして誰もその理由を知りませんでした。

診断は、まるで退屈しのぎのように、終わりの見えない会議の後、データベースを手動で調べているうちに偶然に判明しました。PDFカタログには342個の技術テーブルが含まれていましたが、データベースにはゼロ個しかありませんでした。ほんの少しでもなく、ゼロ個です。一つもありません。テーブルをPDFから抽出するコードは、データをcolumnsとdataというフィールドに保存していましたが、その後それらをインデックス化するコードは、headersとrowsというフィールドを期待していました。「シノニム」が守られていませんでした。忘れられたリファクタリングで破られた社内規約です。その結果、5ヶ月間沈黙が続いた後、カタログ全体の数値的インテリジェンス—ペア、電力、直径、重量、注文コード、供給電圧—は、蛇口から流れ出ましたが、グラスに注がれることはありませんでした。342個のテーブルが、静かな儀式のように、一つずつ失われていきました。

これは、叫ばないタイプのバグです。例外を発生させたり、クラッシュさせたり、ログに表示したりすることはありません。単に、あなたのシステムにとって世界の特定の部分が存在しなくなってしまうだけで、誰も気づかないまま、粘り強く質問する（通常は怒っている）ユーザーが、その穴を明らかにするまで誰も気づきません。そしてそれは、フィールド名よりもはるかに大きな問題の象徴です。汎用的なRAGフレームワークは、現在のテキスト（記事、ウェブページ、物語の段落など）に最適化されており、テーブルを扱っても二級市民のように扱います。しかし、イタリアの企業文書はしばしばテーブルで構成されています。技術カタログ、価格表、製品仕様、安全データシート、注文書：これらの文書を参照する人にとって価値のある部分は、テーブル部分です。最初に壊れて、誰も気づかない部分です。

教訓は「フィールド名の注意」ではありません。より厄介なのは、本格的なRAGでは、あらゆる種類のコンテンツ—テーブル、画像、英数字コード、段落タイトル、脚注—に、専用の、設計され、テストされた処理が必要になることです。そして、機能テストは「チャットボットが些細な質問に答える」ことではありません—そのような回答は、壊れたシステムでも、それらしいものを構築するのに十分な浮動データがあるため可能です。真のテストは「チャットボットがパイプラインのすべての要素に触れることを強制する質問に答える」ことです。具体的で、数値的で、検証可能な質問です。正解が1つだけ存在し、システムが間違えた場合すぐにわかる質問です。

このテストを行わないと、RAGが機能しているかどうかはわかりません。単に不満を言わないだけだとわかります。そして、「不満を言わない」というのは、人々が意思決定のために使用するシステムの品質基準としては非常に低いです。