AI901-Concept#55-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある企業が社内 FAQ 約 5 万件を対象に、ユーザーの質問に最も関連する FAQ を自動取得する検索システムを Microsoft Foundry SDK と Azure OpenAI で構築しています。キーワード一致では言い換えや概念検索が拾えないため、意味検索が必要です。
解決策
FAQ 検索のたびに毎回 5 万件すべてを Azure OpenAI の embedding API で都度ベクトル化し、結果を一切保存せず、毎リクエストで全件と比較します。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
毎リクエストで全 FAQ を再 embedding 化する設計は実用に耐えません。レイテンシが膨大 (数十秒〜分単位)、API コストが過剰、レート制限への抵触、可用性低下のすべてを引き起こします。embedding は静的コンテンツに対しては事前計算 (offline indexing) しておくのが鉄則で、Azure AI Search 等の vector store にインデックス化して保存、クエリ側のみリアルタイム embedding するのが標準パターンです。本提案はコスト効率・性能・スケーラビリティのすべての観点で誤った設計と言えます。
【「はい」が違う理由】
機能的には類似検索は動くかもしれませんが、本番品質の検索体験と運用コストを満たせず、設計として致命的です。技術的妥当性も運用適合性も欠いた構成のため、「目的を満たす」と判定するのは適切ではありません。
毎リクエストで全 FAQ を再 embedding 化する設計は実用に耐えません。レイテンシが膨大 (数十秒〜分単位)、API コストが過剰、レート制限への抵触、可用性低下のすべてを引き起こします。embedding は静的コンテンツに対しては事前計算 (offline indexing) しておくのが鉄則で、Azure AI Search 等の vector store にインデックス化して保存、クエリ側のみリアルタイム embedding するのが標準パターンです。本提案はコスト効率・性能・スケーラビリティのすべての観点で誤った設計と言えます。
【「はい」が違う理由】
機能的には類似検索は動くかもしれませんが、本番品質の検索体験と運用コストを満たせず、設計として致命的です。技術的妥当性も運用適合性も欠いた構成のため、「目的を満たす」と判定するのは適切ではありません。
コメント