TL;DR

前回チャレンジした「【Go/ChromaDB/Ollama Vol.1】RAG型同人誌サークル検索の構築をベクトルDBを使用して行ってみた」の続きとなります

前回の問題点は以下の通りです

• もととなるデータは自然言語に即したデータにする
• エイリアスを充実させる(ブルアカ、ブルーアーカイブなど)
• ユーザーからの入力をLLMで拡張、整形した後にベクトルDBに検索を行う

今回の主な改良点は

• CSVファイルフォーマットの変更。サークルの補足説明、アピールポイント、配置番号などを追加し、ユーザーが検索したときにより多くの情報にヒットするよう対策した
• LLM要約生成機能を追加し、より多くの情報をベクトルDBに登録することであいまい検索にヒットしやすくした
• 入力されたチャットについてもベクトル化し、検索を行うように修正(前回作成時はチャット入力のベクトル化が行われておらず、結果が取得できなかった可能性があるため)

となります

ただ、このような対策を行っても利用に耐えられるような検索精度を出すことが出来ませんでした

考えられる原因は

• 検証マシンのスペック不足、十分な性能を持つLLMを動作させることが出来なかった
• ノウハウ不足、RAG検索への理解はエンベディングのノウハウが足りなかった
• エイリアス実装の見送り、エイリアスを実装するための良い方法が見つからず、採用を見送った

となります

以下に今回の問題点を記載します

システム的な限界

RAG検索を動作させる環境が「MacBookPro 2019」という、AIシステムを動作させることを考えるとものすごく非力なマシンで動かそうとしました

このPC上でDockerを使ってGo、Python、Redis、ollama、chromaDBなどが動作するため、一つ一つのシステムに割り当てられるリソースが限定されます
特にメモリ16GBではパラメータ数の多いモデルは利用できないため、結果的に精度の良くない小型モデルを利用し、エンベッティング、検索ともに十分な変換ができないという問題がありました

ノウハウ不足

RAG検索は「検索した結果をLLMに渡し、回答を生成する技術」なので、核になるのは「ユーザーが望んだ検索結果を、データストアから取得する」部分になると考えています

今回、データストアにchromaDBを使用し、ユーザーの検索結果をベクトルに変換、chromaDBに対して検索を行うことで(意味的な)距離が近い回答を取得し、LLMにて最終的な回答を作成するというアーキテクチャにしました

ただ、最初の「chromaDBから意味的に近い回答を取得する」部分がうまく言っておらず、テストデータの距離がすべて近いものとして出力されていました

これは「エンベッティング」「chromaDBに対しての検索手法」の知識が無く、なんとなくで作成してしまったことで、結果的に意味のない検索システムが出来上がってしまいました
当然、意味のないデータをLLMに渡したところで、意味のない回答が生成されるだけなので、結果使えないシステムとなりました

エイリアスの実装を見送った

前回の問題点と考えていたエイリアスの充実について、よい方法が浮かばず実装を見送りました
これはマシンスペックが足りないことにも関連してきますが、利用しているLLMの規模が小さく、アニメ（同人）特有のエイリアスを生成することが難しいと判断したためです
特に最近の作品のエイリアスを生成しようとした場合、当然学習データには含まれていないためLLM単体での生成はできません
人の手によって手動で生成するか、都度ウェブ検索を行うような仕組みを入れて対応する必要がありました

その他、ローカルLLMの有用性と限界

今回はローカルLLMとして以下のモデルを利用しています
HauhauCS/Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive

このモデルはRTX5070Ti VRAM16GBの環境で60tokens / secの速度が出るため、かなり実用的に利用できるLLMだと思っています
VSCodeにOpenCodeを設定し、プロバイダとして上記モデルを読み込んだllama.cppサーバーを指定してコーディングさせました

フロントサイド、サーバーサイドともに「動作するもの」はできましたが、やはり一発成功となならず、完成報告を受けて実際に動かしてみたら「Docker buildに失敗」「チャットを送るとエラー」「回答が出力されない」など、多くの問題が発生しました

そのため、動かしつつ問題点は随時修正させることで、一旦動くものはできました
ただ、使えるか？というと、残念ながら使えないものができてしまいました

ローカルLLMはしばらく運用していましたが、やはり大手企業が展開するサブスクモデルレベルのクオリティを求めた場合、現状は困難と判断し、先日GeminiのAI Proプランを契約しました(お試しで3か月720円で利用できるため)

次回に向けて

根本的にRAG検索の理解を深めていきたいと思います
ここの知識が不足していると、そもそも最適なデータ設計や検索仕様が決められないためです
RAGの知識を固めたうえで、改めてデータ設計、検索仕様を固めて、次こそは「使えるRAG検索」を作りたいと思います

以上です

ということで、RAG検索を作成したお話でした
結果失敗に終わりましたが、今まで「なんかいい感じに検索してくれる仕組み」となんとなく思っていましたが、実際に作ってみるとデータ設計、データ検索手法が最も大事だということがわかりました

投稿 【Go/ChromaDB/Ollama Vol.2】RAG検索の改良：チャンク設計と検索ロジックの見直しによるRAG精度検証と更なる改良 は Sheltie Garage Tech に最初に表示されました。

https://github.com/sheltie-fusafusa/dojin-rag

はじめに

無職期間を利用してリスキリングを行っています
AIエージェント時代の開発手法ということで「仕様駆動開発(SDD)」に興味があり、ここ最近取り組んでいました
せっかくなので、なにか面白そうなものを作りたい、ということで、コミケ参加サークルさんを自然言語で検索できる「同人サークル検索RAG」を作ってみようと思い、作成を行いました

TL;DR

同人誌即売会のサークル情報を対象に、Go言語でのデータ取り込み、FastAPI ＋ ChromaDB ＋ Ollama（ローカルLLM）によるRAG（Retrieval-Augmented Generation）検索システムを試作・検証しました

セマンティック検索（ベクトル検索）の利用方法やRAG検索の仕組みのほか、コーディングエージェントを利用した開発を実践し、まとめた内容となります

まとめ

失敗プロジェクトなので色々語るのは後にして、今回のプロジェクトは失敗しました
「絶対にあるはずの条件で検索を行っても、対象なしと表示される、または、関連したサークルが検索されない」という結果になってしまい、結論として「使い物にならない」となりました

大きな敗因は「自分自身がRAG検索を誤解していた」というところにあります
RAG検索は「LLMが自分にない知識を外部からかき集めて回答を生成してくれる」と思っていましたが、違いました

RAG検索は「ユーザーが入力した検索条件から関連性のあるデータをデータソース(ベクトルDBなど)から取得し、LLMを用いて回答を作成する」方法でした
LLMはあくまで回答の組み立て役であって、肝となるのはユーザーの入力した質問の意図を汲み取り、関連するデータをデータソースから取得できるか、と言うところにあります

ただ、自分がRAGを誤解していたこともあり、データソースやデータ構造の設計が全くできてなくて、結果関連した情報が取れず、LLMも回答を生成できなかったという流れになっていました

とはいえ、RAGは面白そうな技術ではあるので、今度はデータ設計や、ユーザーの質問内容から関連情報を取得する部分の改善など、次回作成時に改善すべきところがわかったことが、今回の一番の収穫でした

改めて、技術スタックや開発手法など

開発はspeckit + OpenCodeを利用した完全AIエージェント開発

GeFOrceRTX 5070Ti 16GBマシンでllama.cppを動かし、MacBookProでOpenCodeを操作させ、OpenCodeがWindowsマシンのLLMを利用して開発する環境を整えました

OpenCodeとは対話を通してアプリの仕様や技術スタックを決め、実装、テストまで行ってもらいました
自分はコーディングは一切行っておらず、あくまで仕様策定、使用技術選定、動作確認、修正指示に徹しました

「動くもの」はすぐできた

AIエージェントに開発をおまかせして2日目
プログラムが完成し、実際にdocker compose upで環境を立ち上げれば、localhost:3000でアクセスできるチャットウィンドウが表示されました

最初はAIエージェントから「終わりました」の連絡があってもdocker compose upで起動できなかったりなど色々トラブルは有りましたが、すべて「〇〇でXXのエラーが出るから修正して」とお願いすればAIエージェントが自律的にエラーを修正し、起動できるとこまで作り込むことができました

早速チャットを行ってみましたが、望んだ結果が全然返ってきません
ここから使えるようになるために色々修正指示や動作確認を行ってみましたが、結論としては「使い物になるまで」持っていくことはできませんでした

「使えるもの」にはなかなかできない

チャットを行っても望んだ結果が全然返ってきませんでした
例えばテストデータ内には「ブルーアーカイブ」のデータが入っていても、「ブルアカを取り扱っているサークルを教えて」とチャットを行っても「取り扱いサークルはありません」と返ってきてしまい、望んだ結果が返却されません

そのため、主に以下のような対策を行いました
・登録するCSV項目を増やした(Tag、Genreなど)
・検索対象の項目を増やした(検索対象にTag、Genreなどを含めるようにした)
・特定のタグ(ケモミミなど)を含む場合、フィルター単体検索を使用する

ただ、これらのような改善を行っても、検索結果は改善されずされませんでした

その後もAIエージェントに「〇〇と検索したらXXの結果が返ってくるはず」と何度も相談し、結構色々直してもらいましたが結果として十分な精度が出せず、今回は根本的なデータ設計、ベクトルDBに対しての知識不足のためこれ以上の改善は行えないと判断しました

敗因

今回の一番の敗因は「自分自身がRAGを誤解していた」ことにあります
自分はRAGを「LLMがいい感じに外部ソースにアクセスして情報を取得し、回答を組み立てること」だと思っていました
ただ、実際のRAGは「データソースより取得した情報をLLMが組み立てて回答する」ことでした

そのため、RAGの核心は「データ設計」にあり、
・ユーザーがどのようなプロンプトで質問を行うのか
・その入力に対して、関連する情報が正しく返答されるよう、どのようにベクトルDBにデータを登録する必要があるのか
をきちんと設計、検証する必要がありました

今回のケースではデータ設計は全く行っておらず、結果としてユーザーの入力結果に対して正しい関連情報が取得できず、使い物にならないアプリができてしまいました

次に向けて

今回の敗因を踏まえて、次回は「データ設計」に重点を置いて開発してみたいと思います
・もととなるデータは自然言語に即したデータにする
・エイリアスを充実させる(ブルアカ、ブルーアーカイブなど)
・ユーザーからの入力をLLMで拡張、整形した後にベクトルDBに検索を行う
と言った対策を行ってみようと思います

終わりに

今回はRAGを作成しようとして失敗したお話でした
AIエージェントの登場でコーディングを行う機会はグンと減りました
確かに、プログラム作成や修正はAIエージェントの方が何倍も早く、ミスも無く仕上げてくると思います

ただ、人が使ったときの「使い心地」や「使い勝手」と言った部分には、まだまだ人がきちんと設計する必要があるとも感じました
AIに任せたほうが良いところ、人が行ったほうが良いところ
適材適所、人とAIの強みを活かして、使い心地の良いシステムが作っていけるようになりたいですね

投稿 【Go/ChromaDB/Ollama Vol.1】RAG型同人誌サークル検索の構築をベクトルDBを使用して行ってみた は Sheltie Garage Tech に最初に表示されました。