llm-rag-pipelines.md
lab: rag-lab / retrieval / evals
lab: rag-lab / retrieval / evals
文脈: LLMは確信してはいけない場面でも、きれいに答えてしまいます。だから私にとってRAGはインデックスから始まるのではなく、「どの回答を検証できるか」「どのソースをユーザーに見せるべきか」から始まります。
問題: ドキュメントをただ分割してtop-kをモデルに渡すだけでは、品質はすぐに偶然になります。悪いchunking、ノイズの多い一致、eval casesの不足、説明できない回答はシステムをブラックボックスにします。
アプローチ: ingestion、retrieval、rerank、answer synthesisを分けます。各層にはログが必要です。どの文書が文脈に入ったか、なぜ選ばれたか、回答のどの部分を支えているか、どこでモデルがソースの境界を越えたかを追います。
結論: RAGは小さくても生きているeval setがあって初めてproduction toolになります。モデル、プロンプト、chunking、embedding providerを変えた後の回帰を見つけられます。
次のステップ: quality dashboardを作る。hit rate、citation coverage、hallucination flags、議論が必要な回答の手動レビュー。