“好”的知识库 = RAGAS 三维度(检索相关性 + 生成忠实度 + 答案相关性)全面达标 + 8 步构建流程(Load/Split/Embed/Store + Query/Retrieve/Rerank/Generate)每环节可调 + AutoRAG 等自动化优化解决模块组合爆炸;RAG vs Long Context 不是二选一而是”RAG 粗筛 + Long Context 精读”的混合方案。
RAG 的本质是”参数化记忆 + 非参数化记忆”双引擎 —— 不是替代 LLM,而是补 LLM 的非参数记忆空白(2020 Facebook 论文框架至今未变)
“好”的判断必须先有标准 —— RAGAS 框架提供三维度评估,三者必须分别评估才能定位根因(失败往往由检索 + 生成共同造成)
语义相似 ≠ 对 LLM 有用 —— 传统 IR 指标(Precision/Recall/F1)已不够,需要 ICLERB 端到端评估”检索 → 注入 → 评估 → 反推”
构建流程标准化为 8 步 —— 离线 4 步(Load/Split/Embed/Store)+ 在线 4 步(Query/Retrieve/Rerank/Generate),每步都有明确可配置参数
RAG vs Long Context 不是二选一 —— 数据量 < 50K tokens + 低更新频率用 Long Context;数据量大 + 更新频繁 + 需要精确召回用 RAG;混合方案 = RAG 粗筛 + Long Context 精读
| 维度 | 核心问题 | 计算要点 | reference-free |
|---|---|---|---|
| Context Precision | 相关文档是否排在前面 | 排序质量 | ✅ |
| Context Recall | 应被召回内容是否都召回了 | claims 归因 | ❌ 需参考答案 |
| Faithfulness | 答案是否忠于上下文 | LLM 拆 claims → 验证 → 占比 | ✅ |
| Answer Relevance | 答案是否回应了问题 | 反向生成问题比对相似度 | ✅ |
1
2
离线索引:Load → Split → Embed → Store
在线查询:Query → Retrieve → Rerank → Generate
| 阶段 | 步骤 | 关键参数 / 选型 |
|---|---|---|
| 离线 | Load | 数据源:odps / 语雀 / 钉钉 / 本地 |
| 离线 | Split | chunk_size 256-1024 tokens;chunk_overlap 10%-20% |
| 离线 | Embed | Embedding 模型选型(多模型可选) |
| 离线 | Store | 向量数据库(ANN 索引 + 元数据) |
| 在线 | Query | 预处理 + 增强(HyDE / Late Chunking / 意图驱动) |
| 在线 | Retrieve | 稠密 / 稀疏 / 混合 |
| 在线 | Rerank | Cross-Encoder 精排 |
| 在线 | Generate | 上下文 + 用户问题 → LLM → 答案 |
| 案例 | 核心思路 | 适用场景 |
|---|---|---|
| AutoRAG | 自动化 RAG Pipeline 优化 | 特定领域数据集优化 + 缺乏调优经验 |
| QuIM-RAG | 问题倒排索引匹配 | (原文未展开) |
| OpenViking | 文件系统范式 | (原文摘要提及但正文未展开) |
“知识库的核心接口,就是上传和召回。不同版本和理论,就是召回的内容和排序的区别。”
“RAG 系统的失败往往是检索和生成环节共同造成的,因此必须分别评估,才能定位问题根因。”
“传统 IR 指标基于语义相似度评估检索质量,但在 RAG 场景下存在一个核心问题:语义相似 ≠ 对 LLM 有用。”
“对用户原始查询进行预处理和增强……最为简单的方式就是交给大模型自己来。充分信任基模的能力。”
(对 RAG vs Long Context 的混合方案)”RAG 粗筛 + Long Context 精读”