RAG技术

“我们的RAG准确率85%"——这个数字什么也说明不了 每个RAG团队都会说"我们的RAG准确率XX%"。但如果你问他们"你是怎么评估的？"，答案通常是"我们手动测了50个问题，感觉还不错”。 这种评估方式有三个问题： 样本量太小：50个问题不能代表真实用户的查询分布 主观性太强：“感觉还不错"不是评估，是自我安慰 没有分维度：准确率是一个模糊的概念——检索准确、生成准确、忠实度，这是三个不同的维度 2026年，RAG评估已经有一套成熟的框架。以下是完整介绍。 RAGAS：RAG评估的事实标准 RAGAS（RAG Assessment）是2026年最主流的RAG评估框架。它把RAG系统的质量拆分为三个维度： 维度一：检索质量（Retrieval Quality） 评估指标： Context Precision：检索到的文档中，有多少是真正相关的？越高越好。 Context Recall：所有相关的文档中，有多少被检索到了？越高越好。 金句：Context Precision是"搜出来的东西对不对”，Context Recall是"该搜的东西搜没搜到"。两者缺一不可。 维度二：生成质量（Generation Quality） 评估指标： Answer Relevance：生成的答案和用户问题有多相关？ Answer Correctness：生成的答案是否事实正确？ 金句：Answer Relevance是"答非所问吗"，Answer Correctness是"答对了吗"。前者是及格线，后者是优秀线。 维度三：忠实度（Faithfulness） 评估指标： Faithfulness：生成的答案是否忠实于检索到的文档？有没有"编造"文档中没有的信息？ 金句：Faithfulness是RAG评估最重要的指标。一个答案可以"相关"、“正确”，但如果它来自LLM的幻觉而不是检索文档，那这个RAG系统就失败了。 用RAGAS评估你的RAG系统 from ragas import evaluate from ragas.metrics import ( context_precision, context_recall, answer_relevancy, answer_correctness, faithfulness ) # 准备测试数据 test_data = { "question": ["什么是RAG？", "RAG和微调有什么区别？"], "answer": ["RAG是检索增强生成...", "RAG和微调的主要区别..."], "contexts": [["文档1", "文档2"], ["文档3", "文档4"]], "ground_truth": ["RAG定义...", "RAG和微调的区别..."] } # 评估 result = evaluate(test_data, metrics=[ context_precision, context_recall, answer_relevancy, answer_correctness, faithfulness ]) print(result) 测试集构建：RAG评估中最难的部分 RAGAS需要"ground truth"（标准答案）来计算评估指标。但构建高质量的测试集是RAG评估中最难的部分。 ...

实现RAG有5种方案，但你的选择可能只需要3分钟 2026年，实现RAG的方案多到让人眼花缭乱。但本质上，所有方案都在做同一件事：文档加载→分块→Embedding→检索→生成。区别只在于"怎么组织这些步骤"。 我用一个标准任务测试了5种方案，以下是完整数据。 测试任务 场景：企业内部知识库问答，2000份技术文档，50万次查询/月。 评估维度：开发时间、代码行数、检索准确率、端到端延迟、可维护性、Token消耗。 方案一：LangChain from langchain.chains import RetrievalQA from langchain_community.vectorstores import Milvus from langchain_openai import OpenAIEmbeddings, ChatOpenAI vectorstore = Milvus(embedding_function=OpenAIEmbeddings()) qa = RetrievalQA.from_chain_type( llm=ChatOpenAI(), chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 5}) ) result = qa.invoke("什么是RAG？") 指标 评分 开发时间 2天 代码行数 ~100行 准确率 87.3% 延迟 2.5秒 可维护性 中（版本升级频繁） 优点：生态完整，LangSmith可观测性好 缺点：版本升级频繁，Chain调试困难，框架开销大 方案二：LlamaIndex from llama_index.core import VectorStoreIndex, SimpleDirectoryReader documents = SimpleDirectoryReader("docs/").load_data() index = VectorStoreIndex.from_documents(documents) query_engine = index.as_query_engine(similarity_top_k=5) result = query_engine.query("什么是RAG？") 指标 评分 开发时间 1天 代码行数 ~50行 准确率 89.8% 延迟 2.1秒 可维护性 中高（API相对稳定） 优点：代码最少，文档解析强，索引管理好 缺点：定制化较难，高级功能文档不全 ...

“RAG还是微调？"——这是2026年AI应用开发最常被问到的错误问题 很多人把RAG和微调对立起来：要么用RAG，要么微调，只能选一个。但这是错误的二分法。RAG和微调解决的是完全不同的问题： RAG：解决"知识"问题——让LLM知道它不知道的事情 微调：解决"能力"问题——让LLM学会它不会的技能 当你理解了这点，你就知道大多数场景下两者都需要。 RAG vs 微调：全方位对比 维度 RAG 微调 解决的问题 “不知道” “不会做” 知识更新 实时（更新数据库） 需要重新训练 成本 低（API调用+向量库） 高（GPU训练+数据标注） 幻觉控制 强（有文档锚定） 弱（可能学会"编造”） 风格控制 弱（依赖Prompt） 强（训练数据决定风格） 可解释性 高（可引用来源） 低（黑盒） 延迟 中（检索+生成） 低（直接生成） 适用场景 知识库问答、动态信息 特定格式输出、领域风格 金句：RAG是"给LLM装一个外部硬盘"，微调是"给LLM做一次脑部手术"。前者可逆、低成本、快速见效；后者不可逆、高成本、长期回报。 什么时候只用RAG？ 知识频繁更新：新闻、股票、天气等实时信息 知识库庞大：企业所有文档、产品手册、技术规范 需要可解释性：法律、医疗等需要引用来源的场景 预算有限：不想花钱做数据标注和GPU训练 什么时候只用微调？ 特定输出格式：如JSON Schema、固定的报告格式 领域风格：如"用律师的口吻写"、“用幼稚园老师的语气说” 任务固化：如情感分析、实体识别、代码生成 延迟敏感：不能接受RAG的检索延迟 什么时候两者都要？ RA-FT（RAG + Fine-tuning）混合方案： 微调做"风格内化"：用微调教会LLM特定的输出格式和领域风格 RAG做"知识外挂"：用RAG提供最新、最准确的知识 实战案例：某律所的合同生成系统 微调：用1000份合同训练LLM学会"合同的语言风格和格式" RAG：检索最新的法律法规和判例，确保合同内容合法合规 效果：合同生成时间从2小时降到10分钟，法律风险点覆盖率从85%提升到97% 金句：RA-FT是2026年AI应用的"黄金组合"——微调让LLM"学会怎么说"，RAG让LLM"知道说什么"。**

你以为RAG是"一套方案打天下"？不同行业的RAG架构差了一个宇宙 2026年，RAG已经成为企业AI应用的标配。但如果你以为RAG就是"文档分块→Embedding→检索→生成"这一套通用方案，那你就错了。不同行业的RAG架构差异之大，超乎你的想象。 以下是5个行业的RAG实战案例，每个都有独特的架构选择。 案例一：法律行业——合同审查RAG 场景：某律所的合同审查系统，自动分析合同条款，识别风险点。 数据特点： 合同文档结构严格（条款编号、层级关系） 术语精确，同义词少 需要精确引用（“第3条第2款”） 架构选择： Chunking：文档结构切分（按条款号），而非按字符数 检索：Hybrid Search（关键词+向量），因为条款编号必须精确匹配 元数据：每条chunk标注合同名称、条款号、风险等级 生成：必须引用具体条款号，不可"大概" 关键数值： 合同审查效率提升：1小时→3分钟（20倍） 风险识别准确率：91.2% 客户满意度：NPS从45提升到72 金句：法律RAG的核心不是"检索"，而是"精确"。一个条款号的引用错误，可能导致数千万的损失。 案例二：医疗行业——诊疗指南RAG 场景：某三甲医院的诊疗辅助系统，医生输入症状和检查结果，RAG检索相关诊疗指南，辅助诊断。 数据特点： 诊疗指南、医学论文、药品说明书 医学实体（疾病、症状、药品、检查）之间的复杂关系 安全性要求极高（错误答案可能导致医疗事故） 架构选择： 知识图谱：Graph RAG，理解疾病-症状-药品-检查之间的关系 多级检索：先检索相关指南，再检索具体章节 安全机制：所有答案标注"仅供参考"，并引用来源 人工审核：高风险建议（如药物剂量）需要医生确认 关键数值： 诊断建议与专家一致性：87.3% 查询到答案时间：<5秒（vs 手动查阅30分钟） 零医疗事故（上线12个月） 金句：医疗RAG的核心不是"智能"，而是"安全"。宁可少答，不能错答。 案例三：金融行业——投研RAG 场景：某基金公司的投研助手，自动分析财报、研报、新闻，生成投资摘要。 数据特点： 多源数据：PDF财报、HTML研报、新闻API、数据库 数据新鲜度要求高：今天的新闻今天就要能用 数值敏感：财务数据必须精确，不能"大概" 架构选择： 多模态RAG：文本+表格+图表统一处理 实时索引：增量更新，新数据5分钟内可检索 数值验证：LLM生成的财务数据必须与原文对比验证 Agentic RAG：Agent自动决定查询哪些数据源 关键数值： 研报摘要生成时间：从4小时→15分钟（16倍） 财务数据准确率：96.5% 投资建议采纳率：58%（从AI建议到实际投资的比例） 金句：金融RAG的核心不是"快"，而是"准"。一个财务数字的偏差，可能导致数亿的投资决策错误。 案例四：电商行业——客服RAG 场景：某电商平台的智能客服，回答用户关于商品、订单、物流、售后的问题。 数据特点： 结构化数据（订单、物流）+ 非结构化数据（商品描述、FAQ） 高频查询（“我的订单到哪了"是最高频的查询） 多轮对话（退换货流程通常需要3-5轮对话） 架构选择： 分层路由：高频查询走SQL/API，低频查询走RAG Hybrid Search：商品名用关键词，商品描述用向量 多轮对话管理：Agent管理对话状态，记住用户之前的查询 缓存高频查询：Top-100高频查询直接缓存结果 关键数值： 客服自动化率：从35%提升到78% 人工客服日均处理量：从200通降到60通 用户满意度：从3.8提升到4.3（5分制） 金句：电商RAG的核心不是"全面”，而是"分层"。高频查询走快车道，低频查询走慢车道。 ...

你的RAG能理解"这张图表说明了什么"吗？ 某券商的分析师每天要阅读200份研报，其中70%的信息在图表中——柱状图、趋势线、饼图、表格。纯文本RAG只能处理文字，面对图表完全无能为力。 多模态RAG就是为解决这个问题而生的。但实现多模态RAG的难度，是纯文本RAG的3倍以上。 多模态RAG的三种技术路线 路线一：文本描述替代（最简单） 用视觉模型（GPT-4V、Claude Vision）把图片转成文字描述，然后存入纯文本RAG。 优点：实现简单，复用现有RAG基础设施 缺点：描述可能丢失细节，图表数据在转换中失真 实测：1000张研报图表 转文字描述后检索 Recall@10：72.3% 图表数据失真的比例：28% 金句：文本描述替代是"最偷懒"的多模态方案。能跑，但不够好。** 路线二：双向量空间（中等复杂度） 图片用CLIP生成视觉向量，文本用BGE生成文本向量，存在两个向量空间中。查询时分别检索，合并结果。 优点：保留视觉信息，检索精度高 缺点：需要两个向量数据库，架构复杂 实测：1000张研报图表+5000段文本 纯文本RAG Recall@10：65.2% 双向量空间 Recall@10：85.8% 提升：+20.6个百分点 路线三：统一向量空间（最先进） 用多模态Embedding模型（如ColPali、UniVL）将图文统一Embedding到同一个向量空间。 优点：图文在同一个空间中，自然支持跨模态检索 缺点：多模态Embedding模型还不够成熟，2026年仍处于早期 实测：ColPali统一向量空间 Recall@10：92.1% 跨模态检索（文字搜图片、图片搜文字）：88.5% 金句：统一向量空间是多模态RAG的终局，但2026年还在路上。** 实战：金融研报多模态RAG 我们为某券商构建了一个多模态RAG系统，处理研报中的文本+图表+表格。 架构： 文档解析：LlamaParse解析PDF，提取文本、表格、图片位置 图片处理：CLIP生成图片Embedding，GPT-4V生成图片文字描述 表格处理：大模型提取表格数据，转为结构化JSON 统一索引：文本存在Milvus（BGE-M3向量），图片存在Milvus（CLIP向量），表格存在PostgreSQL 多模态检索：查询时同时检索文本、图片、表格，合并结果 多模态生成：GPT-4V理解检索到的文本+图片+表格，生成综合答案 关键数据： 多模态Recall@10：92.1%（vs 纯文本65.2%） 分析师研报阅读时间：从4小时/天降到1.5小时/天 图表理解准确率：88.3% 金句：多模态RAG的核心不是"把图片存进去"，而是"让图片和文本在同一个语义空间中对齐"。**

你刚发布的新闻，5分钟后才能搜到——这就是传统RAG的"实时"水平 某新闻聚合平台的RAG系统，用户经常抱怨"刚发布的新闻搜不到"。排查发现：新文档从发布到可检索，延迟是5-15分钟。因为传统RAG是"批量处理"的——每15分钟拉取一批新文档，然后批量Embedding，批量导入向量数据库。 2026年，实时RAG正在成为越来越多场景的刚需：新闻、股票、舆情、客服、IoT数据。以下是一个完整的实时RAG架构。 实时RAG的技术挑战 流式Embedding：数据到达即Embedding，而不是等待批量 增量索引更新：新向量插入后立即可检索，而不是等待索引重建 一致性保证：新数据和旧数据的一致性，不能有"空窗期" 性能平衡：实时写入和实时查询的并发竞争 实时RAG架构 数据源（新闻API、数据库CDC、Kafka） ↓ 消息队列（Kafka/Pulsar） ↓ 流式处理（Flink/Spark Streaming） ↓ Embedding服务（批量API调用/自部署模型） ↓ 向量数据库（增量写入+实时索引） ↓ RAG查询服务 关键组件 消息队列：Kafka 选择Kafka而不是批处理，是因为Kafka提供了"事件驱动"的架构。新数据到达后，立即作为事件推送到下游。 from kafka import KafkaConsumer consumer = KafkaConsumer( 'new_documents', bootstrap_servers=['localhost:9092'], auto_offset_reset='latest', enable_auto_commit=True, ) for message in consumer: document = json.loads(message.value) # 实时处理：Embedding → 写入向量数据库 process_document(document) 流式Embedding 批量Embedding API（如OpenAI）的延迟是200ms/条。实时场景下，需要优化： 微批处理：不是逐条Embedding，而是攒够16条再批量调用API（减少网络往返） 自部署Embedding模型：用BGE-M3自部署，延迟降到10ms/条 异步处理：Embedding和写入异步进行，不阻塞消息消费 实测：自部署BGE-M3，微批处理16条，单条Embedding延迟从200ms降到15ms。 增量索引 Milvus的增量写入：新数据写入后，在segment被flush（默认1秒）后即可检索。但索引构建需要时间——HNSW索引构建约1-5秒（取决于数据量）。 优化：使用Milvus的"streaming"模式。新数据先写入一个"streaming segment"，使用暴力搜索（无索引），查询延迟约100ms。同时后台构建HNSW索引，构建完成后切换到索引搜索。 金句：实时RAG的"实时"是分阶段的。1秒内可检索（暴力搜索），5秒内可检索（索引搜索），30秒后性能最优（索引优化完成）。 实测效果 指标 传统RAG 实时RAG 新数据可检索延迟 5-15分钟 1-5秒 查询延迟 1.5秒 1.5秒（索引后）/ 100ms（暴力搜索） 写入吞吐 1000条/秒（批量） 500条/秒（流式） 成本增加 基准 +30%（Kafka+Flink基础设施） 金句：实时RAG不是"更快"，而是"另一种架构"。它需要Kafka、流式处理、增量索引——这些基础设施的成本不低，但带来的"实时性"价值远超成本。** ...