戦略をドキュメントとして — 第7章

第6章 — 戦略をドキュメントとして、コードとしてではなく

RAGを2023年から構築してきた人々の話の中で、最も頻繁に「初めから理解しておけばよかった」と語られる洞察にたどり着きました。

従来のフレームワークは、検索戦略をPythonコードとして扱います。技術カタログの場合、最初に製品コードで検索し、次にキーワードで検索し、次に意味ベクトルで検索し、最後にのみ応答を生成したいですか？関数を書きます。写真アルバムの場合、従来のセマンティック検索を完全にスキップして、画像に特化したリランカーに依存したいですか？別の関数を書きます。企業ビデオの場合、オーディオをビデオトラックから分離し、個別にトランスクライブし、別々のソースとして扱い、その後最終的な応答に再構成したいですか？さらに別の関数です。コンテンツの種類、ドメイン、顧客ごとに、他のものから分岐するコードのブランチが生成され、最終的には戦略の変更にソフトウェアリリース、コードレビュー、テストサイクル、デプロイが必要になります。「技術マニュアルの検索を改善する方法が思いついた」から「アイデアが本番環境に投入された」までの時間は、アイデアごとに数週間かかります。

代替的な洞察は言うまでもなく、その影響は深遠です。検索戦略はコードではありません。それはドキュメントです。 どんな編集者でも30分のトレーニングで読み解ける構造化テキスト形式であるJSONが、次のように述べています。「まずこれを試し、次にそれを試してください。最初のものが失敗した場合は3番目に進み、このように再ランク付けし、このモデルで応答してください。」 このドキュメントはリポジトリではなくデータベースに存在します。プルリクエストではなくインターフェースから変更されます。バージョン管理、コピー、ドメインごとの専門化が行われます。技術カタログ用、写真アルバム用、インストールマニュアル用、ビデオ用、オーディオ用、法契約用、財務諸表用など、それぞれ異なる戦略です。これらはすべて同じシステム内で共存し、すべてリアルタイムで変更可能です。

このアプローチ—あまりひねりを加えずにMeta-RAGと呼ぼう—で作業した人は、エンジニアリングを超えた速度の変化を語ります。「CMP40MやRH1Mのような略称を含む製品コードの特定の検索を追加してください」といった典型的な顧客からのリクエストは、もはや2週間の開発チケットではありません。それは、JSONプロシージャに追加された新しいステップであり、ステージング環境でホットテストされ、午後には本番環境にプロモーションされます。「写真には現在のものを使用し、テキストには別の再ランク付けを使用するとどうなりますか？」という質問は、設定の1行を変更することで回答できます。実験のコストはかからず、ロールバックのコストもかかりません（単にドキュメントの以前のバージョンを復元するだけです）、そして蓄積された知識—特定の種類のコンテンツに対して何がうまく機能するか—は、特定のコードブランチを書いた人の暗黙知ではなく、バージョン管理され、転送可能な資産になります。そして、今日休暇中です。

このアプローチを採用する組織において、興味深い社会的効果も生まれます。戦略をドキュメントとして扱うことで、「開発者」と「熟練ユーザー」の境界線が曖昧になります。デジタルキュレーター、企業アーキビスト、ドメインエキスパート—技術部門の責任者、ドキュメンテーション担当者、顧客の真の疑問を誰よりも理解しているプロダクトマネージャー—は、戦略を読み解き、その内容を理解し、変更を提案し、時には直接書き込むことができます。開発チケットのプロセスを経る必要も、開発者が本来知っているべきではないことを説明する必要もありません。RAGは、消費する製品ではなく、組織の知識に基づいてモデル化できるツールへと変化します。実際に試した人々の経験から、これは指標の数値よりも前に、プロジェクトの士気を高める効果があると言えるでしょう。

魔法ではありませんし、それなりのコストがかかります。これらの戦略をドキュメントとして効率的かつ安全に実行するためのエンジンが必要です。現実のケースをカバーできるほど十分に豊富で、ターリング完全なものに扮したような過剰な複雑さを避けることができるほど簡潔な記述言語が必要です。バージョン管理、テスト、ロールバックのためのツールも必要です。しかし、これらはすべてエンジンを構築する側の問題であり、一度だけ、そしてすべてのユーザーのために解決すべき課題です。個々のエンドクライアントが見るのはたった一つ、ソフトウェアリリースサイクルではなく、思考の速度で検索戦略を進化させられる可能性だけです。そして、このことに携わっている者にとっては、業界誌でまだその名前が見つかっていない静かな革命なのです。

終幕 — 第七章、数か月後

2026年初頭、これまでの章で学んだ教訓 — 消失するテーブル、嘘をつく再ランク付け器、受け継がれた幻覚、価値よりも速く増加するクラウドの請求書、有望だが堅牢でないフレームワーク — を踏まえ、イタリアのある人物が、異なるRAGサーバーの構築に着手しました。Pythonで記述され、アクセス可能なハードウェアで動作するように設計されており、必要に応じてクラウドモデルと通信し、プライバシーが求められる場合やコストが合わない場合にはローカルモデルと通信できます。検索戦略が編集可能なドキュメントであり、再ランク付け器がGPU上のローカルプロセスであり、テーブルがファーストクラスの市民として扱われ、写真は他の時代の埃っぽいアーカイブからオブジェクトを継承せず、クエリごとのコスト — 金銭的コストと、第三者へのデータ漏洩 — がセント単位で把握および制御可能なサーバーです。

プロジェクト名は伏せます。それを語るのがこの記事の目的ではなく、調査報道を宣伝に転じさせたくないからです。しかし、前の章でご自身の状況と一致するもの—誤った回答を自信満々に返す企業向けチャットボット、数か月も進展しないRAGプロジェクト、有用性よりも早く増加するクラウドの請求書、そして機密ドキュメントが知らない場所に移動しているのではないかという疑念—に気づいたのであれば、別の道があることを知っておく価値があります。それはイタリアのある人が歩んだ道であり、2023年に期待されていた最初の回答を2026年に出し始めたのです。

良いニュースは、企業向けAIがようやくデモ段階を脱しつつあることです。悪いニュースは、その過程で負った傷跡—肥大化したフレームワーク、プロバイダーへの依存、モノリシックなアーキテクチャ、汚れたデータ、サイレントバグ、そして問題を理解する前にソリューションを販売する業界の傾向—をすべて引きずっていることです。私たちはそれを6つの章で語ってきました。7番目の章—誰かが辛抱強く、イタリア語で、オープンソースで物事を正しく行うとどうなるかの物語—は、すぐに、名前をより慎重に、そして具体的な数字を交えて書くつもりです。

さて、ここまで読み進めてくれたあなたは、すでに、企業向けチャットボットの契約を、これらの章を読んだ際に自問自答した質問を一切せずにサインしている意思決定者の90%以上よりも多くの内省を済ませています。それは彼らがスタートした場所よりも良い出発点です。そして今後数か月で、これらの質問をしたかどうかの差は、請求書上、そしてあなたのAIが顧客に与える回答に、非常に明確に現れるでしょう。

この調査は、2024年末から2026年初頭にかけて、企業向けRAGシステムの設計、構築、最適化の18か月の経験に基づいて、2026年4月に作成されました。