内容としては、Formatterのマニュアルに検索を実装した話題*から続きます。
検索機能の実装は「今、検索機能を用意するということ」について改めて考える機会となりました。
社の見解ではなく個人の見解となりますので、ご承知おきください。
検索機能は実装の必要があるのか
「資料はAIに読ませればよいので、検索機能をサイトに載せる意味はあるのか」という問いを立ててみます。
実際、
今回実装に際し資料を用意したときも「このURLの文書を参照して」とか、「必要な情報を別文書に書き出して」といった指示を挟んだりしています。
「指定された文書を読み込んで、必要と思われる事項を選別する」という機能は、
多くのコーディングエージェントに用意されているようです。
とはいえ、その「必要な箇所」の選別に大量の文書をそのまま読ませるというのは、コストとパフォーマンスの両面であまり望ましくありません。
コストの面では分かりやすく、AIクラウドサービスでは読ませた量や書かせた量、すなわちトークン消費を単位とした従量課金や使用量のリミットという縛りが固定化しつつあります。
フロンティア、より精度の高い思考ができるとされる上位のモデルはトークンあたりの価格もより高く設定されています。
パフォーマンスの面では、比較的長い記憶を扱えるようになったといっても、1から100まで資料を読ませているのでは記憶容量は早く枯渇します。
作業を重ねるうちに読ませた資料が適切に反映されなくなってくるといった話題もかなり浸透してきましたね。
よって、そのような選別をより安いコストで行う手段があればそれに越したことはありません。
とはいえ、この点ではAI用の検索手段を各々が用意すればよいといえます。
製品側が提供する検索
では、製品側が検索機能を提供することでどのような価値があるのか。
端的には「結果を保証する」ことにあります。
これはマニュアルを提供すること自体にもいえます。
AIであれ人間であれ、自前の検索機能を用意した上で
ある検索の結果が0件であったとき、
「検索した内容は文書内に存在しない」と判断を下すことになるでしょう。
実際には文書内に存在するのに、
検索によって「この機能がないようなので、この製品は使えない」と判断が下されるのは損失です。
この話を広げるとベクトル検索の提供などにまで話題が広がりますが、
少なくとも「明確に文書内に存在する」事柄の検索については、公式のマニュアルとして提供する意義があるといえます。
逆に「存在しない機能を公式の検索が提供する」というのはかなりよろしくないため、
LLMブーム初期のRAGや自動応答チャットインタフェースが試みで終わってしまう事例が多くあったのもむべなるかな。
まとめ 大量の文書は読み切れない
LLM以前、2010年代には既に情報爆発、情報氾濫の時代と言われていました。
これは主にインターネット上の情報を指してのものでした。
現在はAIによって、ここにローカル、自分のPC内の情報もまた読み切れない量で増加しつつあります。
AIに自動で作業を進めさせると、もはや人間がチェックできないスピードと量でコードが生成されていきます。
「必要なときに、必要な情報を読ませる」という点において、DITAのようなトピック単位で情報完結するようなアーキテクチャは依然有効、むしろより重要になりつつあります。
AI時代の新しい形式として耳目を集めたGoogleのOpen Knowledge Format(OKF)なども、
メタデータや簡易的な説明、内容の単位、参照の記述、配置の構成など収斂進化や再発明ともいうべき構造を持ちます。
言い換えれば、
AIが読むにしろ人間が読むにしろ「必要な情報か端的に判断できる機構があること」「必要な情報がまとまっていること」「処理しやすい形で記述されていること」が大事であるということです。
今回検索機能を実装するにあたっても「文書がこういう構造だったらなあ」と思うことが何度もありました。その詳細はまた別の記事に譲りたいと思います。
