【要約】フレームワークなしで最小RAGを書いて、7段のデータ変形を目で見る [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
RAG開発者が、LangChainやLlamaIndexなどの高機能なフレームワークを利用する際に直面する「内部挙動のブラックボックス化」という課題。便利さの代償として、各工程で何が起きているかが隠蔽されてしまう。具体的には以下の問題がある。
- ・各工程（分割、ベクトル化、検索）の内部でデータがどう変形しているか見えない。
- ・挙動が崩れた際、どの工程に原因があるのかの切り分けが困難になる。
- ・「検索の失敗」と「LLMの捏造」という異なるレイヤーの事象を混同しやすい。
// Approach
著者は、RAGを「7段階のデータ変形」として捉え直し、各境界で中間データを可視化する最小構成の実装を行った。抽象化を排除し、数学的・構造的な理解を深めるために以下の手法を採用した。
- ・架空の事実を用いたコーパスを作成し、LLMの事前知識による回答を排除して検証。
- ・コサイン類似度を手書き実装し、検索の数学的本質を露出。
- ・チャンクサイズ（CHUNK_SIZE）を変動させ、検索スコアと文脈保持のトレードオフを定量的に観察。
- ・Voyage AIの
input_typeを使い分け、非対称な埋め込みの重要性を確認。
// Result
本実践を通じて、RAGの各工程における入出力の「形」と、パラメータが及ぼす影響が明確になった。エンジニアが挙動を制御するための具体的な知見が得られている。
- ・チャンクサイズを小さくすると、検索の「キレ（スコアの高さ）」は増すが、文脈は減少する。
- ・捏造（Hallucination）の抑制は、検索の精度ではなく、生成時のSystem Promptによる制御であることを特定。
- ・抽象化を一度剥がすことで、フレームワークの各メソッドの役割を地図として読めるようになった。
Senior Engineer Insight
> 現場の責任者として、この「脱・ブラックボックス」のプロセスを高く評価する。抽象化の裏にあるデータ変形の「形」を理解することは、本番環境でのデバッグ能力に直結する。特に、Groundingの責任分界点（検索 vs プロンプト）の理解は、トラブルシューティングにおいて不可欠だ。ただし、本実装は総当たり検索であるため、大規模トラフィック下ではHNSW等のANN（近似最近傍探索）への移行が必須となる点は留意すべきだ。