搭了个 RAG文档灌进去问题丢过来回答出来了——看起来能用了。但问它RAG 四代架构是什么它编了个第一代 RTG——这个术语根本不存在。问它嵌入模型中文怎么选它说建议根据几点来选择——正确的废话。模型不是在回答你的问题它在表演回答。没有参考资料它就编有参考资料但检索不准它就糊弄。RAG 的坑不在能不能跑起来而在每一层都可能出问题而你不知道是哪一层。分块切多大向量检索够不够要不要加重排序这些问题看原理文章是看不懂的——你得亲手跑一遍看到每一层的输入输出才知道问题出在哪。一、技术栈组件选型原因嵌入模型BAAI/bge-m3中文首选开源支持稠密稀疏重排序bge-reranker-v2-m3投入产出比最高生成模型Qwen2.5-32B中文能力强向量库ChromaDB本地零配置demo 首选APISiliconFlowOpenAI 兼容国产模型前置要求pip3 install chromadb openai python-dotenv设置SILICONFLOW_API_KEY。二、分块 — RAG 的地基分块是 RAG 的第一步也是最容易出错的一步。选错分块策略后面怎么调都没用。1. 递归字符分块我们首先选择的是递归字符分块Recursive Character Splitting。原理很简单先用最粗的分隔符\n\n段落切如果某块还是太大用下一级分隔符\n换行切一直递归到最细的分隔符空格这样能尽量保持语义完整性——先按段落切段落太大再按句子切而不是暴力按字符数切。核心代码\n\n\n。 300# 字符数中文约150-200 token60# 10-20% 重叠defrecursive_chunktext, chunk_size, overlap, separators递归字符分块 — 先按段落切太大再按句子切def_splittext, sep_idxiflenreturn# 用当前层级分隔符切# 合并小块直到超过 chunk_sizeforinifelseiflenelseififlen# 递归用更细的分隔符1elseifreturn0# 加重叠每块前后各加 overlap/2 字符forinenumerateif0and01iflenelsereturn2. 为什么是 300 字试了三个值块大小块数检索精度上下文完整性150 字920高但碎片化差经常只有半句话300 字485适中好大部分块语义完整500 字290低块太粗好但检索噪声大300 字是中文场景的甜区——大约 150-200 token够一个完整段落又不会把不相关的内容混在一起。3. 重叠的作用每个块前后各加 30 字的重叠。这 30 字看起来浪费但它解决了一个真实问题跨块信息丢失。比如一句话重排序的投入产出比最高Top-5 准确率提升 15-30%“如果正好被切在提升后面前半块说投入产出比最高”后半块说15-30%——两块都丢失了完整语义。重叠让两块都包含完整句子。4. 实际结果✅ 加载了 33 篇文章 ✅ 分块完成: 485 个块 平均块大小: 295 字符三、嵌入 — 把文字变成向量嵌入是 RAG 的翻译层——把人类读的文字变成机器算距离的数字。1. 为什么选 BGE-M3 而不是 OpenAI两个原因中文能力BGE-M3 在中文 MTEB 排行榜上长期 Top-3OpenAI 的 text-embedding-3-small 在中文场景表现一般成本SiliconFlow 上 BGE-M3 的价格是 OpenAI 的 1/10核心代码fromimport# SiliconFlow OpenAI 兼容接口https://api.siliconflow.cn/v1SILICONFLOW_API_KEYBAAI/bge-m3# 1024 维向量defembed_textsclient, texts, batch_size20调用嵌入 API把文本变成向量forinrange0leninputfloatsortedlambdaforin0.5# 避免限流return存入 ChromaDBimport./data/chroma_dbrag_demo_articlesembed_modelBAAI/bge-m3# 批量插入idforintextforinmetadataforin2. 嵌入过程485 个块每批 20 条调用 SiliconFlow API嵌入批次 1/25 (20 条)... 嵌入批次 2/25 (20 条)... ... ✅ 嵌入完成: 485 个向量 向量维度: 1024整个过程大约 30 秒。嵌入结果存入 ChromaDB——一个零配置的本地向量数据库。3. 向量库选型为什么 demo 用 ChromaDB生产用 Qdrant选向量库是 RAG 的第一个架构决策。我们先把主流选项摆出来向量库类型混合检索中文场景适合阶段ChromaDB本地嵌入式❌ 不支持一般Demo / 原型验证Qdrant自托管/云✅ 稀疏稠密RRF好生产首选Milvus自托管/云(Zilliz)✅ 支持好大规模/国产合规Pinecone纯托管✅ 支持一般快速上线/海外Weaviate自托管/云✅ 支持一般GraphQL 场景我们 demo 选 ChromaDB 的理由零配置、本地运行、Python 嵌入式——5 分钟跑起来不需要装任何服务。但 ChromaDB 有一个硬伤不支持稀疏向量不支持混合检索。这意味着我们的 demo 只能做纯向量语义检索不能做向量关键词的混合检索。原理文章里说中文场景混合搜索几乎是必须的——我们的 demo 在这一步是简化了的。生产环境应该选Qdrant原生支持稠密向量稀疏向量RRF 融合BGE-M3 一个模型同时输出两种向量不需要额外跑 BM25。4. 向量到底是什么1024 维向量就是 1024 个浮点数。两个向量越近余弦相似度高说明文本语义越相似。比如RAG 四代架构和朴素RAG、高级RAG、模块化RAG的向量距离会很近而RAG 四代架构和OPC一人公司的向量距离会远。这就是语义搜索的核心——不需要关键词完全匹配只要意思接近就能找到。四、检索 重排序 — RAG 的命脉90% 的 RAG 问题出在检索阶段。这一步我们做了对比实验。完整调用链——从连接数据库到拿到重排序结果# 1. 连接 ChromaDBStep 2 已经把向量存好了./data/chroma_dbrag_demo_articles# 2. 把用户的问题变成向量和 Step 2 用的同一个模型BAAI/bge-m3input嵌入模型中文场景怎么选float0# 3. 向量检索 — 从知识库找最相似的文档块10# 先捞 10 条documentsmetadatasdistances# results 包含文档内容、来源标题、向量距离# 4. 重排序 — 把 10 条结果精排成 5 条documents0forinrange10importhttps://api.siliconflow.cn/v1/rerankAuthorizationfBearer {API_KEY}modelBAAI/bge-reranker-v2-m3query嵌入模型中文场景怎么选documentstop_n5return_documentsTrueresults# reranked 包含重排序分数、文档内容、原始索引4 步串起来就是完整的检索流程问题 → 向量 → 检索 → 重排序 → 精选上下文。但这是纯向量检索——只靠语义相似度找文档。中文场景下这一步有致命缺陷。1. 混合检索中文场景的必选项纯向量检索有个硬伤精确术语匹配极差。问微信支付怎么接入向量检索可能找到支付系统架构——意思接近但不是你要的。问BGE-M3 嵌入模型向量检索可能找到嵌入模型选型指南——也是意思接近但漏掉了BGE-M3这个精确关键词。混合检索 语义检索 关键词检索两条路的结果合并。原理很简单用户提问 BGE-M3 嵌入模型中文怎么选 │ ├── 语义检索稠密向量──→ 找到嵌入模型选型指南意思接近 │ ├── 关键词检索稀疏向量──→ 找到BGE-M3 支持稠密稀疏检索精确匹配 │ └── RRF 融合 ───→ 两条路的排名合并取最优三条核心技术稠密向量Dense VectorBGE-M3 输出的 1024 维向量捕捉语义——意思接近就能找到稀疏向量Sparse VectorBGE-M3 同时输出的 BM25 稀疏向量捕捉关键词——精确匹配就能找到RRF 融合Reciprocal Rank Fusion把两条路的排名合并——不是简单取交集而是按排名倒数加权融合BGE-M3 的关键优势一个模型同时输出稠密稀疏两种向量。不需要额外跑 BM25不需要两个模型一次 API 调用搞定两条路。生产环境用 Qdrant 实现混合检索的核心代码fromimportfromimport# 1. BGE-M3 同时输出稠密稀疏向量BAAI/bge-m3True嵌入模型中文场景怎么选dense_vecs0# 1024 维稠密向量lexical_weights0# 稀疏向量BM25风格# 2. 存入 Qdrant同时存两种向量:memory:rag_demodense1024sparseFalse# 3. 混合检索 — 稠密稀疏两条路并行RRF 融合rag_demo# 语义检索路径用稠密向量找意思接近的dense20# 关键词检索路用稀疏向量找精确匹配的listlistsparse20# RRF 融合两条路的排名倒数加权合并10# 最终返回 10 条融合结果对比一下效果差异检索方式问BGE-M3问微信支付问RAG架构纯向量找到嵌入选型意思接近找到支付架构意思接近找到RAG全景意思接近混合检索精确命中BGE-M3相关段落精确命中微信支付接入语义关键词双保障我们的 demo 为什么没做混合检索ChromaDB 不支持稀疏向量无法实现混合检索。这是选 ChromaDB 做 demo 的代价——5 分钟跑起来但牺牲了检索质量。生产环境换 Qdrant 就能补上这一层。2. 测试问题我们设计了 5 个不同类型的问题具体事实“RAG 的四代架构分别是什么”解决方案“怎么解决 RAG 检索召回率低的问题”跨文章“OPC一人公司的核心公式是什么”模糊查询“Agent 安全有哪些风险”技术选型“嵌入模型中文场景怎么选”3. 纯向量检索 vs 重排序以嵌入模型中文场景怎么选为例纯向量检索 Top-5#1 [距离0.9427] RAG从原理到实战 #2 [距离0.8968] RAG从原理到实战 #3 [距离0.8703] RAG从原理到实战 #4 [距离0.8443] RAG从原理到实战 #5 [距离0.7457] RAG已死-Pinecone-Nexus注意看距离值——0.74 到 0.94区分度很弱。你很难说 0.94 的那条一定比 0.74 的更相关。重排序后 Top-5#0 [分数0.996] 最相关的那条 #1 [分数0.990] 第二相关 #2 [分数0.950] 第三相关 #3 [分数0.120] 弱相关 #4 [分数0.046] 不相关区分度从 0.2 提升到 0.95——提升了近 5 倍。4. 为什么重排序这么有效向量检索是双编码器Bi-Encoder问题和文档分别编码再算相似度。快但粗——它只看大概像不像。重排序是交叉编码器Cross-Encoder问题和文档一起编码。慢但准——它能理解这个问题和这段文档到底有没有因果关系。实际操作先用向量检索捞 Top-10快再用重排序精选 Top-5准。这就是文章里说的先粗后精策略。五、生成 — 有 RAG vs 无 RAG这一步是最直观的。同一个问题对比有 RAG和无 RAG的回答。完整调用链——把 Step 3 的重排序结果喂给模型Qwen/Qwen2.5-32B-Instruct# 无 RAG — 直接问模型纯靠训练数据rolesystemcontent你是一个技术顾问请简洁准确地回答问题。roleusercontentRAG的四代架构分别是什么0.35000# 有 RAG — 把重排序结果拼成上下文喂给模型\n\nf[{i1}] 来源: {reranked[i][document][text][:200]}forinrange5# 重排序后的 Top-5rolesystemcontent基于参考资料回答问题。roleusercontentf基于以下参考资料回答问题。如果参考资料中没有相关信息请明确说明。参考资料:{context}问题: RAG的四代架构分别是什么回答要求:1. 优先使用参考资料中的信息2. 标注信息来源如根据[1]...3. 简洁准确0.38000关键区别无 RAG 的 prompt 只有问题有 RAG 的 prompt 包含检索到的上下文。模型从猜答案变成读答案。1. 问题RAG 的四代架构分别是什么无 RAGRAG检索增强生成技术经历了四代演进第一代 RTG检索-生成第二代 RAG检索增强生成第三代 Advanced RAG第四代 Modular RAG…编造了第一代 RTG这个不存在的术语。这就是幻觉——模型没有参考资料靠训练数据编。有 RAG根据[1]RAG从原理到实战RAG经历了四代演进1. 朴素RAGNaive RAG— 索引→检索→生成三步走…2. 高级RAGAdvanced RAG— 加了前后处理…3. 模块化RAGModular RAG— 可插拔组件…4. 智能体RAGAgentic RAG— 让模型自己决定何时检索…基于真实文档可溯源没有幻觉。2. 问题嵌入模型中文场景怎么选无 RAG建议根据以下几点来选择1. 模型大小和性能…2. 多语言支持…3. 领域适配…正确的废话。没有任何具体推荐。有 RAG根据[1]中文场景首选 BGE-M3理由1. 中文 MTEB 排行榜 Top-3…2. 支持稠密稀疏多向量三种检索模式…直接给出了具体推荐和理由。3. 问题OPC一人公司的核心思路是什么无 RAGOPC一人公司利用AI Agent实现自动化运营…泛泛而谈。有 RAG根据[1]OPC一人公司篇零核心公式是你做决策Agent做执行。具体来说…引用了原文的精确表述。六、关键收获跑完这个 demo我们理解了三件事1. 分块是地基选错全盘皆输300 字不是魔法数字但中文场景下它是一个好的起点。太小会碎片化太大会引入噪声。关键是递归分块 重叠而不是暴力切割。2. 重排序投入产出比最高一行 API 调用区分度提升 5 倍。如果你只优化一个环节优化这里。3. 有 RAG 和无 RAG 是两个世界无 RAG 的回答看起来也对但经不起对照——它编造术语、给废话、泛泛而谈。有 RAG 的回答精确、可溯源、没有幻觉。这个差异在技术问答里可能只是不够精确在医疗、法律场景里就是可能致命。七、你可以自己跑所有代码在demos/rag-demo/目录下# 1. 安装依赖# 2. 设置 API Keyexportyour-key# 3. 分步运行推荐# 分块# 嵌入# 检索重排序# 生成# 4. 交互式问答八、从 Demo 到生产这个 demo 跑通了但离生产还有几步环节Demo生产分块固定 300 字语义分块 父子块检索嵌入BGE-M3 单模型多模型混合稠密稀疏检索Top-10混合检索 查询改写重排序bge-reranker-v2-m3同但加业务规则过滤生成单轮多轮对话 引用溯源评估人工看RAGAS 自动评估向量库ChromaDB 本地Qdrant/Milvus 集群但核心 pipeline 是一样的分块 → 嵌入 → 检索 → 重排序 → 生成。先把这条线跑通再逐环节优化。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
RAG知识库全流程实操：从分块→检索→生成，逐步拆解
发布时间：2026/5/20 2:52:27
搭了个 RAG文档灌进去问题丢过来回答出来了——看起来能用了。但问它RAG 四代架构是什么它编了个第一代 RTG——这个术语根本不存在。问它嵌入模型中文怎么选它说建议根据几点来选择——正确的废话。模型不是在回答你的问题它在表演回答。没有参考资料它就编有参考资料但检索不准它就糊弄。RAG 的坑不在能不能跑起来而在每一层都可能出问题而你不知道是哪一层。分块切多大向量检索够不够要不要加重排序这些问题看原理文章是看不懂的——你得亲手跑一遍看到每一层的输入输出才知道问题出在哪。一、技术栈组件选型原因嵌入模型BAAI/bge-m3中文首选开源支持稠密稀疏重排序bge-reranker-v2-m3投入产出比最高生成模型Qwen2.5-32B中文能力强向量库ChromaDB本地零配置demo 首选APISiliconFlowOpenAI 兼容国产模型前置要求pip3 install chromadb openai python-dotenv设置SILICONFLOW_API_KEY。二、分块 — RAG 的地基分块是 RAG 的第一步也是最容易出错的一步。选错分块策略后面怎么调都没用。1. 递归字符分块我们首先选择的是递归字符分块Recursive Character Splitting。原理很简单先用最粗的分隔符\n\n段落切如果某块还是太大用下一级分隔符\n换行切一直递归到最细的分隔符空格这样能尽量保持语义完整性——先按段落切段落太大再按句子切而不是暴力按字符数切。核心代码\n\n\n。 300# 字符数中文约150-200 token60# 10-20% 重叠defrecursive_chunktext, chunk_size, overlap, separators递归字符分块 — 先按段落切太大再按句子切def_splittext, sep_idxiflenreturn# 用当前层级分隔符切# 合并小块直到超过 chunk_sizeforinifelseiflenelseififlen# 递归用更细的分隔符1elseifreturn0# 加重叠每块前后各加 overlap/2 字符forinenumerateif0and01iflenelsereturn2. 为什么是 300 字试了三个值块大小块数检索精度上下文完整性150 字920高但碎片化差经常只有半句话300 字485适中好大部分块语义完整500 字290低块太粗好但检索噪声大300 字是中文场景的甜区——大约 150-200 token够一个完整段落又不会把不相关的内容混在一起。3. 重叠的作用每个块前后各加 30 字的重叠。这 30 字看起来浪费但它解决了一个真实问题跨块信息丢失。比如一句话重排序的投入产出比最高Top-5 准确率提升 15-30%“如果正好被切在提升后面前半块说投入产出比最高”后半块说15-30%——两块都丢失了完整语义。重叠让两块都包含完整句子。4. 实际结果✅ 加载了 33 篇文章 ✅ 分块完成: 485 个块 平均块大小: 295 字符三、嵌入 — 把文字变成向量嵌入是 RAG 的翻译层——把人类读的文字变成机器算距离的数字。1. 为什么选 BGE-M3 而不是 OpenAI两个原因中文能力BGE-M3 在中文 MTEB 排行榜上长期 Top-3OpenAI 的 text-embedding-3-small 在中文场景表现一般成本SiliconFlow 上 BGE-M3 的价格是 OpenAI 的 1/10核心代码fromimport# SiliconFlow OpenAI 兼容接口https://api.siliconflow.cn/v1SILICONFLOW_API_KEYBAAI/bge-m3# 1024 维向量defembed_textsclient, texts, batch_size20调用嵌入 API把文本变成向量forinrange0leninputfloatsortedlambdaforin0.5# 避免限流return存入 ChromaDBimport./data/chroma_dbrag_demo_articlesembed_modelBAAI/bge-m3# 批量插入idforintextforinmetadataforin2. 嵌入过程485 个块每批 20 条调用 SiliconFlow API嵌入批次 1/25 (20 条)... 嵌入批次 2/25 (20 条)... ... ✅ 嵌入完成: 485 个向量 向量维度: 1024整个过程大约 30 秒。嵌入结果存入 ChromaDB——一个零配置的本地向量数据库。3. 向量库选型为什么 demo 用 ChromaDB生产用 Qdrant选向量库是 RAG 的第一个架构决策。我们先把主流选项摆出来向量库类型混合检索中文场景适合阶段ChromaDB本地嵌入式❌ 不支持一般Demo / 原型验证Qdrant自托管/云✅ 稀疏稠密RRF好生产首选Milvus自托管/云(Zilliz)✅ 支持好大规模/国产合规Pinecone纯托管✅ 支持一般快速上线/海外Weaviate自托管/云✅ 支持一般GraphQL 场景我们 demo 选 ChromaDB 的理由零配置、本地运行、Python 嵌入式——5 分钟跑起来不需要装任何服务。但 ChromaDB 有一个硬伤不支持稀疏向量不支持混合检索。这意味着我们的 demo 只能做纯向量语义检索不能做向量关键词的混合检索。原理文章里说中文场景混合搜索几乎是必须的——我们的 demo 在这一步是简化了的。生产环境应该选Qdrant原生支持稠密向量稀疏向量RRF 融合BGE-M3 一个模型同时输出两种向量不需要额外跑 BM25。4. 向量到底是什么1024 维向量就是 1024 个浮点数。两个向量越近余弦相似度高说明文本语义越相似。比如RAG 四代架构和朴素RAG、高级RAG、模块化RAG的向量距离会很近而RAG 四代架构和OPC一人公司的向量距离会远。这就是语义搜索的核心——不需要关键词完全匹配只要意思接近就能找到。四、检索 重排序 — RAG 的命脉90% 的 RAG 问题出在检索阶段。这一步我们做了对比实验。完整调用链——从连接数据库到拿到重排序结果# 1. 连接 ChromaDBStep 2 已经把向量存好了./data/chroma_dbrag_demo_articles# 2. 把用户的问题变成向量和 Step 2 用的同一个模型BAAI/bge-m3input嵌入模型中文场景怎么选float0# 3. 向量检索 — 从知识库找最相似的文档块10# 先捞 10 条documentsmetadatasdistances# results 包含文档内容、来源标题、向量距离# 4. 重排序 — 把 10 条结果精排成 5 条documents0forinrange10importhttps://api.siliconflow.cn/v1/rerankAuthorizationfBearer {API_KEY}modelBAAI/bge-reranker-v2-m3query嵌入模型中文场景怎么选documentstop_n5return_documentsTrueresults# reranked 包含重排序分数、文档内容、原始索引4 步串起来就是完整的检索流程问题 → 向量 → 检索 → 重排序 → 精选上下文。但这是纯向量检索——只靠语义相似度找文档。中文场景下这一步有致命缺陷。1. 混合检索中文场景的必选项纯向量检索有个硬伤精确术语匹配极差。问微信支付怎么接入向量检索可能找到支付系统架构——意思接近但不是你要的。问BGE-M3 嵌入模型向量检索可能找到嵌入模型选型指南——也是意思接近但漏掉了BGE-M3这个精确关键词。混合检索 语义检索 关键词检索两条路的结果合并。原理很简单用户提问 BGE-M3 嵌入模型中文怎么选 │ ├── 语义检索稠密向量──→ 找到嵌入模型选型指南意思接近 │ ├── 关键词检索稀疏向量──→ 找到BGE-M3 支持稠密稀疏检索精确匹配 │ └── RRF 融合 ───→ 两条路的排名合并取最优三条核心技术稠密向量Dense VectorBGE-M3 输出的 1024 维向量捕捉语义——意思接近就能找到稀疏向量Sparse VectorBGE-M3 同时输出的 BM25 稀疏向量捕捉关键词——精确匹配就能找到RRF 融合Reciprocal Rank Fusion把两条路的排名合并——不是简单取交集而是按排名倒数加权融合BGE-M3 的关键优势一个模型同时输出稠密稀疏两种向量。不需要额外跑 BM25不需要两个模型一次 API 调用搞定两条路。生产环境用 Qdrant 实现混合检索的核心代码fromimportfromimport# 1. BGE-M3 同时输出稠密稀疏向量BAAI/bge-m3True嵌入模型中文场景怎么选dense_vecs0# 1024 维稠密向量lexical_weights0# 稀疏向量BM25风格# 2. 存入 Qdrant同时存两种向量:memory:rag_demodense1024sparseFalse# 3. 混合检索 — 稠密稀疏两条路并行RRF 融合rag_demo# 语义检索路径用稠密向量找意思接近的dense20# 关键词检索路用稀疏向量找精确匹配的listlistsparse20# RRF 融合两条路的排名倒数加权合并10# 最终返回 10 条融合结果对比一下效果差异检索方式问BGE-M3问微信支付问RAG架构纯向量找到嵌入选型意思接近找到支付架构意思接近找到RAG全景意思接近混合检索精确命中BGE-M3相关段落精确命中微信支付接入语义关键词双保障我们的 demo 为什么没做混合检索ChromaDB 不支持稀疏向量无法实现混合检索。这是选 ChromaDB 做 demo 的代价——5 分钟跑起来但牺牲了检索质量。生产环境换 Qdrant 就能补上这一层。2. 测试问题我们设计了 5 个不同类型的问题具体事实“RAG 的四代架构分别是什么”解决方案“怎么解决 RAG 检索召回率低的问题”跨文章“OPC一人公司的核心公式是什么”模糊查询“Agent 安全有哪些风险”技术选型“嵌入模型中文场景怎么选”3. 纯向量检索 vs 重排序以嵌入模型中文场景怎么选为例纯向量检索 Top-5#1 [距离0.9427] RAG从原理到实战 #2 [距离0.8968] RAG从原理到实战 #3 [距离0.8703] RAG从原理到实战 #4 [距离0.8443] RAG从原理到实战 #5 [距离0.7457] RAG已死-Pinecone-Nexus注意看距离值——0.74 到 0.94区分度很弱。你很难说 0.94 的那条一定比 0.74 的更相关。重排序后 Top-5#0 [分数0.996] 最相关的那条 #1 [分数0.990] 第二相关 #2 [分数0.950] 第三相关 #3 [分数0.120] 弱相关 #4 [分数0.046] 不相关区分度从 0.2 提升到 0.95——提升了近 5 倍。4. 为什么重排序这么有效向量检索是双编码器Bi-Encoder问题和文档分别编码再算相似度。快但粗——它只看大概像不像。重排序是交叉编码器Cross-Encoder问题和文档一起编码。慢但准——它能理解这个问题和这段文档到底有没有因果关系。实际操作先用向量检索捞 Top-10快再用重排序精选 Top-5准。这就是文章里说的先粗后精策略。五、生成 — 有 RAG vs 无 RAG这一步是最直观的。同一个问题对比有 RAG和无 RAG的回答。完整调用链——把 Step 3 的重排序结果喂给模型Qwen/Qwen2.5-32B-Instruct# 无 RAG — 直接问模型纯靠训练数据rolesystemcontent你是一个技术顾问请简洁准确地回答问题。roleusercontentRAG的四代架构分别是什么0.35000# 有 RAG — 把重排序结果拼成上下文喂给模型\n\nf[{i1}] 来源: {reranked[i][document][text][:200]}forinrange5# 重排序后的 Top-5rolesystemcontent基于参考资料回答问题。roleusercontentf基于以下参考资料回答问题。如果参考资料中没有相关信息请明确说明。参考资料:{context}问题: RAG的四代架构分别是什么回答要求:1. 优先使用参考资料中的信息2. 标注信息来源如根据[1]...3. 简洁准确0.38000关键区别无 RAG 的 prompt 只有问题有 RAG 的 prompt 包含检索到的上下文。模型从猜答案变成读答案。1. 问题RAG 的四代架构分别是什么无 RAGRAG检索增强生成技术经历了四代演进第一代 RTG检索-生成第二代 RAG检索增强生成第三代 Advanced RAG第四代 Modular RAG…编造了第一代 RTG这个不存在的术语。这就是幻觉——模型没有参考资料靠训练数据编。有 RAG根据[1]RAG从原理到实战RAG经历了四代演进1. 朴素RAGNaive RAG— 索引→检索→生成三步走…2. 高级RAGAdvanced RAG— 加了前后处理…3. 模块化RAGModular RAG— 可插拔组件…4. 智能体RAGAgentic RAG— 让模型自己决定何时检索…基于真实文档可溯源没有幻觉。2. 问题嵌入模型中文场景怎么选无 RAG建议根据以下几点来选择1. 模型大小和性能…2. 多语言支持…3. 领域适配…正确的废话。没有任何具体推荐。有 RAG根据[1]中文场景首选 BGE-M3理由1. 中文 MTEB 排行榜 Top-3…2. 支持稠密稀疏多向量三种检索模式…直接给出了具体推荐和理由。3. 问题OPC一人公司的核心思路是什么无 RAGOPC一人公司利用AI Agent实现自动化运营…泛泛而谈。有 RAG根据[1]OPC一人公司篇零核心公式是你做决策Agent做执行。具体来说…引用了原文的精确表述。六、关键收获跑完这个 demo我们理解了三件事1. 分块是地基选错全盘皆输300 字不是魔法数字但中文场景下它是一个好的起点。太小会碎片化太大会引入噪声。关键是递归分块 重叠而不是暴力切割。2. 重排序投入产出比最高一行 API 调用区分度提升 5 倍。如果你只优化一个环节优化这里。3. 有 RAG 和无 RAG 是两个世界无 RAG 的回答看起来也对但经不起对照——它编造术语、给废话、泛泛而谈。有 RAG 的回答精确、可溯源、没有幻觉。这个差异在技术问答里可能只是不够精确在医疗、法律场景里就是可能致命。七、你可以自己跑所有代码在demos/rag-demo/目录下# 1. 安装依赖# 2. 设置 API Keyexportyour-key# 3. 分步运行推荐# 分块# 嵌入# 检索重排序# 生成# 4. 交互式问答八、从 Demo 到生产这个 demo 跑通了但离生产还有几步环节Demo生产分块固定 300 字语义分块 父子块检索嵌入BGE-M3 单模型多模型混合稠密稀疏检索Top-10混合检索 查询改写重排序bge-reranker-v2-m3同但加业务规则过滤生成单轮多轮对话 引用溯源评估人工看RAGAS 自动评估向量库ChromaDB 本地Qdrant/Milvus 集群但核心 pipeline 是一样的分块 → 嵌入 → 检索 → 重排序 → 生成。先把这条线跑通再逐环节优化。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
