2026年8月26日に取り上げられた技術エッセーは、検索拡張生成システムを構築するチームは従来型検索から始め、明確な必要性を測定して初めて、より複雑な構成要素を導入すべきだと論じた。Lighthouse AIニュースレターが掲載したこの記事は、検索設計を、データの鮮度、コーパスの挙動、クエリの形式、トラフィック、スタッフの専門知識によって決まる選択肢として位置付けている。

著者の出発点は、BM25、Elasticsearch、PostgreSQL検索など、実績のあるツールとランキング手法を用いた全文検索だ。この手法は、特にキーワード中心の要求、正確な識別子、独自用語を含むコレクションに適しているとされる。また、モデル利用料、文書のチャンク分割に関する判断、モデル変更によってインデックス全体の再構築が必要になるリスクも回避できる。その限界も同様に明確だ。字面どおりの検索では、同義語、意図、会話形式の質問を捉え損なうことがある。

利用者が文書とは異なる表現で要求を記述する場合、エッセーは、言語モデルを使って質問をより明確な検索語に書き換えることを提案している。この処理では、会話的な余分な表現を取り除く、同義語を加える、くだけた表現を専門分野の用語に変換する、複合的な要求を複数の検索に分割するといったことが可能だ。記事によると、書き換え用プロンプトの変更は、チャンク分割戦略を変更してコーパスを再び埋め込み化するよりも、短時間でテストできる場合もある。

提案される次の段階はハイブリッド型パイプラインだ。まず全文検索で候補集合（上位50～100件となる可能性がある）を生成し、その後、埋め込みを使って、より少数の候補を再順位付けする。著者は、より単純な検索と書き換えでは不十分であることを証拠が示し、かつ約100～500ミリ秒の遅延が許容できる場合にのみ、これを検討するよう勧めている。

エッセーは、各リクエストで約500トークンの文書50件を埋め込み化すると、2万5,000トークンを処理することになると見積もっている。OpenAIのtext-embedding-3-smallについて、100万トークン当たり0.02ドルという記載価格を用いると、リクエスト1件当たりの費用は約0.0005ドル、1日1,000件の検索では月額約15ドルになると計算している。著者の評価では、より大きなトレードオフは、さらに200～500ミリ秒の遅延が加わることだ。

更新が頻繁な場合、計算は変わり得る。記事は、コレクション内の文書の10％超が毎日変わる場合、全体を事前に埋め込み化しないよう助言する一方、安定した資料には事前埋め込みがより適しているとしている。また、頻繁に要求される文書は事前に埋め込み化し、ほとんどアクセスされない資料は照会時に処理する階層型設計も提案している。

より広い提言は、セマンティック検索を否定するのではなく、観測された需要に適合させることだ。キーワードの比重が大きいクエリなら全文検索だけで足りる可能性があり、混在した利用傾向ならハイブリッドシステムが適し、1日1万件を超える継続的なトラフィックなら、より踏み込んだ最適化が正当化される可能性がある。エッセーによれば、機械学習の専門知識がないチームには、その範囲のうち、より単純な側が適している可能性がある。