6極を持っていたエンジン — 10行のコードの神話

販売されたドキュメント検索チャットボットがなぜ作り話を続けるのか、そして2026年初頭に誰かが歩み始めた別の方向性について、6回にわたる調査。

販売されたドキュメント検索チャットボットがなぜ作り話を続けるのか、そして2026年初頭に誰かが歩み始めた別の方向性について、6回にわたる調査。

はじめに — 8極を持っていたエンジン（しかし実際は6極）

2026年3月、ミラノ。あるマネージャーが社内のチャットボットを開く。それはIT部門から「2週間で」という大げさな期待とわずかな疑念を抱いて導入されたものだ。非常に簡単な質問をする。「CMP40Mエンジンの極数はいくつですか？」。チャットボットは、大規模言語モデルが示す通りの確信をもって回答する。「CMP40Mエンジンは8極です。」

間違いです。6つです。正解は、誰かが数か月前に、最大限の信頼を込めてベクトルデータベースに注ぎ込んだ422ページのカタログにはありませんでした。システムが「すべてを知る」と信じていたからです。そのデータはカタログには全くなく、SEWの技術者からのメールに添付されたPDFファイルが、誰もインデックス化する手間を惜しまなかったフォルダにアーカイブされていました。

このシーンは、業界や方言を変えて、イタリアの数百のオフィスで繰り返されています。約束はシンプルで魅力的でした。AIアシスタントにすべての社内文書を与えれば、それらについてどんな質問にも答えることができます。しかし、現実ははるかに平凡です。チャットボットは読むことはできますが理解できず、検索はできますが探し出せず、見つからない場合は—それを認めずに—作り上げます。流暢に、完璧な文法で、もっともらしい数字で作り上げます。それは、何も答えないよりもはるかに悪いことです。

2024年末から2026年初頭にかけて、私たちはこれらの失敗の解剖に数か月を費やしました。論争を煽るためではなく、一つのことを理解するためです。なぜ、それほど単純なアイデア—「文書を与えてから質問する」—が、デモの舞台から離れて、実際のサーバー室に入ると、それほど難しくなるのか。

この6章にわたる調査では、私たちが発見したことを報告します。カタログ全体を消去するサイレントバグ、スコアが誤っているクラウドの再ランク付けツール、モデルではなく数年前から汚染されたデータによって引き起こされた幻覚、すべてのクエリをその価値よりも高価にするアウトバウンド請求、そしてあまりにも多くを要求しない限り、10行のコードで全てを約束する「人気」のあるフレームワーク。そして最終章では、誰かが2026年初頭から静かに歩み始めた異なる方向性、つまり検索戦略がコードではなくなり、誰でも企業内で読み書きできるドキュメントになるアーキテクチャについて説明します。

各章は単独で成立しています。342個のテーブルが消失した話、あるいは嘘をつく再ランク付けツールの話から始めたい場合は、自由にそうしてください。しかし、全体的な物語には、最後にのみ明らかになる教訓があります。企業におけるRAG（Retrieval-Augmented Generation、つまり「まず検索したドキュメントに基づいて応答を生成する」という意味の技術的な略語）は、まだ完成品ではありません。それはフロンティアです。そしてすべてのフロンティアと同様に、これまで主に売り手によって語られてきました。内部で経験した人の話を聞く時が来ました。

第1章 — 10行のコードという神話

2023年以降、AIに関するあらゆるカンファレンスで同じスライドが使われています。「あなたの企業のドキュメントアシスタントを10行のコードで」。タイトルの下には、パステルカラーのPythonブロックがあり、有名なアメリカのオープンソースライブラリ（名前が木の連鎖やチベットのラマを連想させるもの）が、PDFを読み込み、分割し、ベクトルデータベースに貼り付け、言語モデルでクエリを実行します。5分でチャットボットが完成します。5分で拍手が起こります。5分で、イタリアの中規模企業は問題が解決し、IT部門が2週間で対応できると確信するのです。

問題点、つまりスライドに書かれていないことは、デモがよく整形された3つのPDF、コンテンツにぴったり合うように仕組まれた質問、実際のような遅延がないステージ、そしてプレゼンターが登壇する前に27回試行したことによって構築されているということです。現実には、企業のドキュメントは地質的な災害です。スキャンのスキャン、テキストと重なる表、段落に紛れ込む脚注、チャンカーが単語だと誤って途中で切り刻む「RH1M」のような英数字コード、役立つ情報の70%が含まれている画像だが誰も抽出しない、そしてパーサーではなく考古学者が必要なほど創造的なレイアウトです。

RAG — これは裏側のアイデアです — 素晴らしいアイデアです。ユーザーの質問を取り、アーカイブから最も関連性の高いドキュメントを検索し、それらを言語モデルに渡し、それらのドキュメントに基づいて回答を得ます。理論的には、これは幻覚の問題をエレガントに解決します。モデルは回答を「知る」必要がなく、「あなたが提供した部分で読む」だけで済みます。実際には、チェーンのすべてのリンク — チャンキング、埋め込み、検索、再ランク付け、最終的な生成 — に独自の故障方法があり、故障はほとんどの場合、目に見えるエラーとして現れません。それはわずかに間違った回答として現れます。そして完全に間違った回答として。そして、インターンよりも知識が少ないシステムにお金を払っている理由を疑問に思うマネージャーとして。

RAGを普及させたオープンソースフレームワークは、実用的な成果を出すためのものではなく、あくまでデモンストレーション用です。それらは非常に洗練された抽象化の連鎖であり、各層には明示されていない前提が隠されています。例えば、PDFのOCRが適切に行われていること、写真がすでに説明されていること、テーブルが特定の規則に従っていること、埋め込みモデルが実際にあなたの言語を理解していること（ネタバレ：多くのモデルは英語しか得意ではありません）、そしてあなたのアーカイブが重複からきれいにされていることなどです。これらの前提のいずれかが崩れると（少なくとも1つは必ず崩れ、ほとんどの場合3つ崩れます）、システムは停止するわけではありません。それよりも悪いことに、正常に機能しなくなるものの、応答を出し続けます。流暢で、確信に満ちた、しかししばしば真実からかけ離れた応答です。

このシステムを職業として構築する人々の間で口伝される言葉があり、チュートリアルでは決して読めないものです。「RAGは簡単に作れるが、うまく作ることは難しい」です。最初のデモと本番環境のサービスの間には、GPUを追加したりモデルを変更したりするだけでは埋められないほどの隔たりがあります。それを埋めるには、不都合な事実を理解する必要があります。企業向けのRAGを構築する場合、あなたはコードを書いているのではなく、あなたのドキュメントに合わせて調整された小さく、頑固な検索エンジンを設計しているのです。そして、それには、ノイズとは何か、シグナルとは何か、何を2回インデックス化すべきか、何を破棄すべきかなど、すべての編集上の選択が含まれます。しかし、10行のチュートリアルでは、これらの選択が誰かによって一度だけあなたの代わりに下されており、その誰かはあなたのドキュメントを見たことがありません。そして、それらはほぼ常にあなたのケースにとって間違った選択です。