セマンティックキャッシュの落とし穴

Transcript

1. 初心者にもやさしい セマンティックキャッシュの 落とし穴 DynamoDBで作るセマンティックキャッシュ 山ちゃん ／ X: @nekorobi_aws セマンティックキャッシュの落とし穴 01 / 20
2. 先日のアップデートで。 DynamoDBが、ベクトル検索に 対応しました ベクトル検索ができるということは、意味の近さで探せるということ。 それはつまり、セマンティックキャッシュが作れるということ。作ってみました。 セマンティックキャッシュの落とし穴 02 / 20
3. 先に、前提をひとつ。 AIチャットボットは、こう動いている 質問が来たら、まず関係する資料を探す。見つけた資料をもとに、LLMが答えを書く。 この「探して、書く」仕組みを、RAG（検索してから答える仕組み）と呼びます。 探すときは、キーワードの一致ではなく意味の近さで探します。さっきのベクトル検索です。 今日は、この「探す→書く」にひと工夫します。 セマンティックキャッシュの落とし穴 03 / 20
4. ここが、困る。 聞かれ方が違うだけの質問に、 毎回数秒かけて回答を1から作っている 返品したい、商品を送り返したい。人間には同じでも、文字列としては別物です。 FAQやサポート窓口だと、同じ処理を何度もやり直し、そのぶん料金がふくらみます。 セマンティックキャッシュの落とし穴 04 / 20
5. 今日の主役です。 セマンティックキャッシュとは？ 似た意味の質問には、 前に作った答えをそのまま返す仕組みです。 作り直さないので速くて安い。 文字が違っても意味が近ければ使えます。 資料を意味で探すのがRAG。 過去の答えを意味で探すのが、セマンティックキャッシュ。 セマンティックキャッシュの落とし穴 05 / 20
6. RAGで遅いのは、検索ではなく生成 質問 → ベクトル化 → 近い文書を取得 → LLMが回答を生成 約2.26秒 検索は数十ミリ秒で終わります。時間を使っているのは最後のLLMです。 生成だけで約2.26秒。ここが全体の待ち時間をほぼ決めています。 毎回ここを通す必要、ありますか。 ※ 生成に使ったLLMは Claude Haiku 4.5。数値はいずれも実測値です。 セマンティックキャッシュの落とし穴 06 / 20
7. ヒットなら即返し、ミスなら作って書き戻す ヒット ミス 質問 → 埋め込み → キャッシュ検索 → 保存済みの回答 キャッシュ検索 → ナレッジをRAG検索 → LLMが生成 → 書き戻して返す ミス時に書き戻すので、同じ意図の質問が2回目から速くなります。 線引きをするのは、意味の近さを数値にした「距離」。 セマンティックキャッシュの落とし穴 07 / 20
8. サーバーレスで組んだ、全体の構成 Lambdaが中心。DynamoDB（ベクトル検索）とBedrockだけで完結します。 AWS Cloud 埋め込み・生成 質問 顧客 Amazon Bedrock Titan V2 ／ Claude Haiku 4.5 回答＋出典 API Gateway AWS Lambda オーケストレーション 検索・書き戻し キャッシュ層 cs-semantic-cache ナレッジ層 cs-support-manual Amazon DynamoDB ① 質問を埋め込み（Titan V2） → ② キャッシュ層を類似検索（TopK=1） → ③ ヒットで即返却 ／ ミスは → ④ ナレッジ層をRAG（TopK=3） → ⑤ Claude Haiku 4.5 で生成 → ⑥ キャッシュへ書き戻し セマンティックキャッシュの落とし穴 08 / 20
9. ヒットすると、爆速になる ミス（LLMを呼ぶ） ヒット（LLMを呼ばない） 約2.5秒 186ms 実測のp50で、13倍以上の差が出ました。 セマンティックキャッシュの落とし穴 09 / 20
10. 消えているのは、LLMの生成時間 ミス 約2.5秒 LLM生成 約2.26秒 186ms ヒット 0 1秒 差を作っているのは、ほぼLLMの生成時間です。 セマンティックキャッシュの落とし穴 10 / 20 2秒
11. 速くて、費用も減る。ここまでの話は、ぜんぶ本当です。 そのうえで、 落とし穴が2つあります セマンティックキャッシュの落とし穴 11 / 20
12. 罠その1。 速すぎると、 ユーザーは逆に不安になる 即答されると、ちゃんと読んでいない、使い回された、と受け取られます。 速くしたのに、信用されない。これが一番やっかいな落とし穴です。 ※ ト ン イ ポ の 今日 特にLLMの推論は、数秒待つのが当たり前。そこに検索結果だけ一瞬で返ってくると、ギャップが大きくてユーザーは戸惑いやすい。 セマンティックキャッシュの落とし穴 12 / 20
13. 待ち時間が、 考えている証拠になっていた 2.5秒は、 信頼の材料でもあった この「待つほど、ちゃんとやってくれた感」は、 労働の錯覚（Labor Illusion）として研究されています。 ※ Buell & Norton, 2011（Harvard / Management Science）ほか。 セマンティックキャッシュの落とし穴 13 / 20
14. 思考を演出する 1 最小待機を1秒。その間ローディングのくるくるを表示して、推論を演出する 2 回答文は全部あるけど、あえてストリーミングで少しずつ出してライブ感を演出する 3 注釈に、セマンティックキャッシュを使っていることを記載する セマンティックキャッシュの落とし穴 14 / 20
15. みんなもやってるでしょ？ 営業 エンジニア 値下げ交渉されて「検討してきます」とか言って、 バックヤードでコーヒータイム 全部終わってるけど、小出しに完了報告 セマンティックキャッシュの落とし穴 15 / 20
16. 罠その2。 どこまで似ていれば使うか。 この線引きで事故が起きる 1 緩いと、別の質問の回答を返す事故が起きる 2 厳しいと、ほぼヒットせず入れた意味がない だからこの線引きは、勘や借り物の数字で決めてはいけません。 セマンティックキャッシュの落とし穴 16 / 20
17. 閾値は、実データの空白帯に置く 同じ意図の言い換え 閾値 0.7 0.404 〜 0.645 意図が違う質問 0.757 〜 0.980 空白帯 約0.11 COSINE距離は0が完全一致で、小さいほど似ています。閾値以下ならヒットです。 同じ意図の最大と、違う意図の最小のあいだにできる空白帯に閾値を置きます。 セマンティックキャッシュの落とし穴 17 / 20
18. 線引きは、本番データを見ながら詰めていく 1 言い換えと無関係の質問セットを先に用意する 2 埋め込みモデルや距離関数を変えたら、閾値を引き直す 3 ヒットとミスと距離をログに残し、運用しながら動かす 誤ヒットのコストが高いほど、詳しい人と一緒に本番データで詰めるのが安全です。 セマンティックキャッシュの落とし穴 18 / 20
19. 今日伝えたいこと。 早ければ、 いいってもんじゃない。 速さの先の、ユーザー体験まで設計することが大切。 セマンティックキャッシュの落とし穴 19 / 20
20. ご清聴ありがとうございました 山ちゃん ／ X: @nekorobi_aws セマンティックキャッシュの落とし穴 20 / 20