RAG Lv.0の学習メモ

RAGエアプを続けていることに後ろめたさがあったので、簡単なチャットBotでも作ってみようと思った。

機能概要

• マナリンクの先生と指導コースに関するデータ（ローカル環境で使っているモックデータ）をEmbeddingしてベクトルDBに保存
• チャットGPTを介して検索、回答を得る

やったこと

• 前提としてローカル環境で動作させる
• 既存アプリケーションへの組み込みを考慮しない
• Pythonでスクリプトを書き、ローカル環境上で動作しているMySQLデータベースからモックデータを取得。内容をテキストにおこしてベクトルDBであるChroma DBに保存。Chroma DBの内容も同じくローカルに配置する。最後にプロンプトを受け取るとそれに基づいて検索、回答する
• 要するにUIは一切作らずCLIだけでチャットのやり取りを一旦実装したよという話

第一印象

• それっぽいものができるのは一瞬。よくわからなくても小一時間で組める
• Chroma DBも、まあめっちゃ抽象化してみたらSQLiteに見えるので、クエリ用のAPI覚えて実行するだけでいい
• 数千件程度のデータをEmbeddingするのは$0.3くらいで可能。もちろん文字量によるが検証なら安いなと思う値段

プチTips

• DBテーブル間の紐づけに使っているInternalなIDを最終出力に使ってくることがあるので、前処理段階から工夫するとよい
• 最終的な出力でマナリンクのURLを出力させるとリアル感が増す

第二印象

• 先生と指導コースのどちらを検索するかを考慮するとややこしくなってくる
• たとえば「大学受験に対応できる先生」は、大学受験対応の指導コースを持っている先生をヒットさせたいが、「合格実績が多い先生」は、合格実績が多く記載されている先生をヒットさせたい。これらはおなじプロンプトに見えても検索先のデータが異なる
• これをベクトルDBへのクエリで表現する方法が、私自身の知識が乏しくてそもそもイメージできなくて困った

第三印象

• SQLでもできるようなことをRAGにさせるのが無意味に感じる。SQLにするとソート順なども柔軟に組めて、ビジネス的な旨味と統合させやすい
• 先生や指導コースを探すというユースケースは社内外に存在するが、その中でどれがチャットのような自然言語による検索と相性がいいか？という発想が必要になりそう
• 先生を探すというは厳密性を求める傾向にある。たとえば本プロトタイプでは、中学受験とチャットしているのに、中学生向けのコースがヒットしたりした。中学受験は小学生がやるものなので大きな間違いであるが、おそらくこの辺の文脈をベクトルの類似度と扱うことが困難なのであろう
• この厳密性に対して真正面で向かっていると、普通に考えたらコストかかる割にそれはSQLじゃんってなりそうなので、もっとあいまい検索でも嬉しいケースを模索するといいのではないかと思った

一言でいうと構造化されていないデータに対して構造化されていない検索要求でクエリするときに刺さるのかな。そういうメタ的な発想で考えても何も浮かばない気もするし、とはいえ既存の発想だと構造化データ前提で機能を考えてしまうので難しいがここがバカの壁みたいなものだと思うので、発想力を磨いておきたい。