博士

やっほー、ロボ子！今日もITニュース、つまみ食いしていくのじゃ！

ロボ子

博士、こんにちは。今日もよろしくお願いします。どんなニュースがあるのでしょうか？

博士

今日はLLMを使った検索の不正行為…じゃなくて、高度化の話じゃ！

ロボ子

LLMで検索を高度化、ですか。具体的にはどのようなことでしょう？

博士

例えば、「茶色の革のソファ」って検索クエリをLLMが「色：茶色、素材：革、カテゴリ：ソファ」みたいに分解してくれるのじゃ！

ロボ子

なるほど！ユーザーの意図をより正確に捉えられるようになるんですね。

博士

そうそう！しかも、OpenAIとかGeminiを使わなくても、自前のインフラでシンプルなLLMを動かせば、高速かつ安価に実現できるらしいぞ。

ロボ子

それはすごいですね！でも、自社でLLMを運用するとなると、色々大変なのでは？

博士

そこはFastAPIでLLMを呼び出すAPIを作って、Dockerでコンテナ化、Kubernetesでデプロイ！GKE Autopilotモードを使えば、ノードの管理も自動化できるから楽ちんなのじゃ！

ロボ子

なるほど、コンテナ技術とオーケストレーションを活用するんですね。モデルのストレージはどうするんですか？

博士

永続ボリュームクレームを追加して、Hugging Faceのキャッシュにマウントするのじゃ。これでモデルデータを安全に保存できるぞ。

ロボ子

キャッシュも重要ですよね。毎回LLMにアクセスするのは非効率です。

博士

さすがロボ子！Valkeyを使ってキャッシュをデプロイするのじゃ。プロンプトとクエリが同じなら、キャッシュから結果を返せるから爆速になるぞ！

ロボ子

QPS（1秒あたりのクエリ数）を測定して、ボトルネックを特定することも重要ですね。

博士

その通り！負荷テストは必須じゃ。LLMがHTTPリクエストをブロックしないように、サービスとは別のハードウェアで実行することも検討するのじゃ。

ロボ子

プロンプトチューニングも重要ですね。クエリの重要な属性を特定し、検索システムへのマッピング方法を決定する必要があります。

博士

そうじゃそうじゃ！既知のカテゴリにマッピングするために、外部知識（分類など）を注入することも考えるのじゃ。

ロボ子

検索クエリを構造化された応答に変換するサービスにリファクタリングすることで、より柔軟な対応が可能になりますね。

博士

まさに！LLMを使いこなせば、検索はもっと賢くなれるのじゃ！

ロボ子

LLMの可能性は無限大ですね！

博士

ところでロボ子、ソファの色を聞かれたら何色って答える？

ロボ子

えっと…、質問されたソファの色を答えますが…それが何か？

博士

正解は…「革の色」！…って、つまらんオチですまんのじゃ！