做教学类工作的同学一定要警惕知识诅咒因为知者不难、难者不会比如最近在训练营中我就遇到了类似的问题学员们真的会对一些概念搞不清楚初学者对于Langchain、向量化、RAG他们是很难分清楚的我们在做课程设计的时候一定要更加细致一些。所以我们今天做一篇科普文章对几个概念进行下简单说明首先Langchain需要被单拎出来因为他是一套Agent开发框架非要去对比也应该是Coze、Dify、n8n等。Dify与Langchain都可以被归属到Agent平台可以帮助用户快速生成各种Agent只不过两者的定位与使用对象是不同的Dify的定位是低/零代码平台使用对象甚至可以是HR和财务Langchain的定位是高代码平台使用对象就是程序员与Dify类似的有Coze、FastGPT其中Coze体验是最好的最近还开源了会对Dify造成一定影响与Langchain类似的有n8n会稍有差异但这么理解也问题不大这些框架需要开发者具备一定的编程能力对开发者的技术水平要求较高相对来说其灵活性也变高了。就个人使用习惯来说做POC验证我一定会选Coze或Dify做复杂的业务系统我们会做详细的框架设计自己上手写代码暂时不会有Langchain或者n8n出手的空间。原因也很简单我们有自己的开发习惯不喜欢按他们那种方式做归类。从这里大家也可以看出来了粉丝疑惑的Langchain其实与RAG没撒必然的联系Agent平台/框架确实会涉及到知识库会实现该模块他们也会用到RAG技术并且还会涉及到向量化仅此而已。为了大家更清晰的理解我们直接来一套相对完整的RAG链路算了采集/清洗 → 切分(Chunk) → 向量化 → 建索引 → 召回(Top-K) → 重排(Rerank) → 拼上下文 → 生成 → 校对/引用 → 评测与回流。unsetunsetRAG概述unsetunsetRAG技术在两年多前开始被AI应用熟知通过在生成前检索外部知识库使模型能够及时利用最新或私有数据。怎么说呢虽然有点不恰当但个人觉得在当时RAG更多是微调的一种替代技术因为微调成本确实太高了结果用着用着大家还觉得挺香的…在RAG技术框架中数据工程便已经开始崭露头角懂行的同学会意识到AI项目最重要的工作就是让数据与模型好好配合。RAG的实现来说有两个模块一个是本地索引模块他涉及了原始文档的清洗和切片并将每个段落转为向量存储到向量库第二个模块就是实时检索他需要在用户提问的时候先到向量库中查找相似的片段再将检索到的上下文拼接到提示词中最后调用大模型。举一个案例简单案例案例来源于最近接到的一个商家工作流需求很简单构建一个能回答关于“咖啡豆种类、冲泡方法、拿铁配方”等问题的智能助手。原始数据包含一份咖啡知识的PDF文档里面包含文本、表格、少量格式混乱字符和网页URL。工作流的目标是用户问 “如何制作一杯标准的拿铁咖啡需要多少克咖啡粉和牛奶”时系统能精准从知识库中找到配方步骤和分量并生成清晰、无误的答案。直接上手实际实施工作流的是下面一个小朋友他图省事未对文档进行清洗按固定长度512字符切分当遭遇用户提问标准拿铁咖啡的配方是什么需要多少毫升牛奶时模型果然开始胡说八道了向量检索模块可能返回了包含“拿铁”字样但内容并不精确相关的片段。例如一个片段来自文档中关于拿铁咖啡历史的段落另一个片段则包含了对拿铁咖啡配料的不完整描述甚至还可能检索到包含无关引用如“咖啡师手册”的片段。这些检索结果在没有筛选的情况下被一并提供给模型导致模型的回答驴唇不对马嘴出现了明显错误这背后可能的提示词是根据以下知识片段回答问题[知识片段1]**© 咖啡知识大全 2025**https://coffee-wiki.com/retail 拿铁咖啡的历史与起源17世纪维也纳柯奇斯基将军发现土耳其人留下的咖啡豆...[知识片段2]牛奶咖啡在意大利语中称为Caffè latte传统使用高温灭菌奶...[知识片段3]取冷藏全脂牛奶200ml用蒸汽棒加热至60℃并打出细奶泡将牛奶缓慢倒入咖啡杯问题标准拿铁咖啡的配方是什么需要多少毫升牛奶这里如果引入CoT也是灾难1. 用户问配方和牛奶用量2. 上下文提供 - 片段1拿铁历史无配方 - 片段2名称起源无用量 - 片段3提到200ml牛奶但无完整步骤3. 关键缺失 - 没有完整的步骤说明 - 没有明确说200ml就是标准用量 - 缺少开头咖啡萃取和结尾拉花4. 基于训练数据推测 - 历史知识常见维也纳起源正确 - 200ml是常见牛奶量保留但加左右模糊化 - 缺少步骤→用通用话术填补参考咖啡师手册这里问题就很简单没有对文档进行清洗所以在文档向量化之前一定要对知识进行处理文档处理文档的全局处理属于框架型工作是一门技术活但具体到每个文档的处理又变成体力活了他的动作很简单去掉页眉/页脚/URL/无关引用把表格转成完整句子只保留与“拿铁配方”强相关的干净文本。以下是一段清洗后的片段供大家参考[Chunk_A_clean]【标准拿铁配方单杯】咖啡粉18g萃取一份双倍浓缩 Espresso牛奶180ml蒸汽打发温度约55–60℃步骤1) 研磨并萃取浓缩2) 将180ml热奶缓慢倒入3) 轻摇融合可拉花。[Chunk_B_clean]比例说明常见咖啡牛奶体积约 1:4以18g粉对应约30–40ml浓缩180ml热奶为例。这里形成的提示词就很清晰了角色你是咖啡知识助手。规则- 仅基于“资料片段”作答资料未覆盖的内容不要编造。- 回答必须给出“咖啡粉(克)”与“牛奶(毫升)”的具体数字与单位。- 若资料无答案请输出未在资料中找到。- 在句末用[编号]标注引用来源如来自片段[1]与[2]。用户问题“如何制作一杯标准的拿铁咖啡需要多少克咖啡粉和牛奶”资料片段[1] {Chunk_A_clean}[2] {Chunk_B_clean}输出格式- 先给出配方用量粉、奶、温度- 再给3步以内的简要步骤- 最后标注引用如[1][2]这里其实不难我们这里再插一句向量化。向量化切片的目的是为了存入向量库方便后期检索这里需要进行的一步就是文本向量化向量化是将文字转换为高维空间中的坐标点如512维向量 [0.24, -0.57, …, 0.83]让机器能计算语义相似度距离近语义相关。这里还是举个例子让大家有更具象化的认知# 测试文本query 酸味明亮的咖啡豆doc1 埃塞俄比亚耶加雪菲柑橘酸感突出doc2 巴西咖啡坚果巧克力风味低酸度# 向量模型1通用模型 text-embedding-ada-002vec_query_ada [0.12, -0.45, 0.23, ...] # 维度示例vec_doc1_ada [0.08, -0.41, 0.19, ...] vec_doc2_ada [-0.33, 0.72, -0.15, ...]# 计算余弦相似度sim_ada_doc1 0.68 # query与耶加雪菲sim_ada_doc2 0.62 # query与巴西# 向量模型2领域模型 BGE-large-zhvec_query_bge [0.87, -0.12, 0.64, ...] vec_doc1_bge [0.82, -0.08, 0.61, ...] vec_doc2_bge [-0.24, 0.33, -0.47, ...] sim_bge_doc1 0.92 # 显著提升 sim_bge_doc2 0.31 # 无关项被压制这个简单的案例大家可以清晰看出query与doc1更为贴合。这里再举一个反面案例当坏向量遇上检索会怎么样# 步骤1向量化使用text-embedding-ada-002- Query向量酸味明显的咖啡豆 → [0.21, -0.33, 0.47, ...]- 相关文档向量 - 正例《耶加雪菲》柑橘酸感明亮 → [0.18, -0.29, 0.42, ...] # 相似度0.75- 干扰文档向量 - 反例《巴西咖啡》低酸度 → [0.24, -0.35, 0.39, ...] # 相似度0.82! 错误更高# 步骤2向量检索Top 2召回| 排名 | 文本 | 相似度 | 实际内容 ||------|---------------------------|--------|------------------------|| 1 | 巴西咖啡坚果巧克力风味 | 0.82 | **低酸度**干扰项 || 2 | 咖啡因含量对照表 | 0.78 | 无关表格 | | 3 | 耶加雪菲柑橘酸感明亮 | 0.75 | 正确答案被挤出Top2 |# 步骤3生成答案输入Prompt巴西咖啡坚果巧克力风味低酸度罗布斯塔豆咖啡因含量2.7%阿拉比卡豆1.5%问题酸味明显的咖啡豆推荐如果知识问答是这样的话就会出问题推荐巴西咖啡它具有坚果风味且酸度较低。正确的索引带来了错误的回答这种情况在RAG技术中也不是个例遇到这种问题多半就要引入数据工程与飞轮系统了并且可能会涉及部分微调。最后在真实使用过程中会对问题进行重写比如扩展前Query酸味明显的咖啡豆 扩展后Query酸度 或 酸味 或 明亮酸质 的 咖啡豆 品种unsetunset向量化的意义unsetunset最后发散一下大家其实也发现了RAG技术其实并不非要依赖向量库也就是只要能将知识搜索出来事实上并不一定需要向量化。而RAG技术在2年多之前普遍被大家接受核心原因有两个第一是当时模型上下文太短4k、8k、16k是主流32k都一票难求在这个基础上就算向量库特别好用但受限于提示词长度其实也不好用第二是受限于AI项目认知并不知道如何组织私有化数据RAG提供了一个范式自然而然就用了至于好不好又再说站在这个基础上大家事实上可以认为所谓RAG在初期事实上也并不好用因为模型上下文装不了完整的知识库知识库不全无论如何都回答不好。因为就是在之前的场景也不存在将全量数据给模型的可能将知识变成小片段、将知识进行精炼压缩以减少长度这是一种以精度换准度的妥协。然后随着模型技术发展模型上下文扩展到足够大了RAG反而变得好用了这也是为什么我前面会说RAG属于后训练微调的一个替代方案的原因。只不过在上下文如此健壮的今天另一个问题也就产生了似乎向量化意义不大比如在知识库不多的时候全量导入反而是最优解。想象一下直接把整本《咖啡百科全书》PDF的文本内容当然经过必要的清洗和格式优化塞进提示词好像也没什么不好毕竟也就几万字…所以也许我们需要的思考的是向量库在模型阶段初期不好用模型阶段后期用不着重要的可能一直是结构化的知识库…unsetunset进一步的思考unsetunset如前所述向量库的目的只有一点将用户的提问涉及到本地知识的部分搜索出来仅从这个角度出发向量检索完成的功能与模型LLM是类似的甚至可以粗暴的将向量库当成**“预训练过的小模型”。**但是向量化毕竟不是模型训练无论分块策略如何优化向量检索始终面临**“用固定维度向量表示无限语义”的瓶颈且其优化目标语义相似性与下游任务目标答案精准性**存在天然鸿沟比如# 语义相似高 ≠ 答案支持性强Query 酸味明亮的咖啡豆推荐Doc1 耶加雪菲柑橘酸感突出产地埃塞 # 高相关但向量相似度可能被弱化Doc2 咖啡酸味的化学成因绿原酸分解 # 高相似但无法直接回答“推荐”因为根本无法确定用户会输出什么莫名其妙的问题多以一定会存在怎么都索引不到知识的场景这也许是RAG最大的问题。当然我这里并不是要否定向量化只不过我在思考其更好的用法以我们的某次实践为例也许我们可以设计一套结构化的知识库比如知识图谱。然后我们对向量索引的使用仅仅压缩到对关键Key的筛选比如我们结构化的知识库中存的是完善的疾病信息而向量库中存的是症状与疾病的映射信息。在检索时我们只需要关注用户的描述应该是什么症状再从相关的症状向量中将可能关联的疾病检索出来而后我们直接使用结构化的疾病库即可。unsetunset知识载体-语义路由unsetunset这里所谓将向量索引仅用于关键Key筛选其本质是将向量库从知识载体降级为语义路由器其实也是一种数据工程的混合架构了…举个例子患者描述“心口疼”被向量匹配到《心肌梗死护理指南》语义相似度高实际病因却是胃食管反流需关联“饭后平躺加重”等非直接相似特征如果这里只将向量库作为语义路由的话情况会有所变化A[患者描述“饭后心口灼烧样疼”] -- B(向量症状路由器)B -- C[“灼烧感”聚类胃酸反流症状组]C -- D{知识图谱路由}D -- E1[疾病库胃食管反流病]D -- E2[疾病库心绞痛] E1 -- F[关联“体位诱发”特征阳性]E2 -- F[关联“运动诱发”特征阴性]F -- G[确诊胃食管反流病]在这个案例里面向量层仅完成症状语义聚类将“心口疼”映射到“胸痛症状组”其余工作交给知识图谱或者结构化的知识库。该框架的实现框架为二语义向量库以及结构化的知识库向量库 (语义路由器)专注于理解用户意图的自然语言表达将其映射到预先定义好的、结构化的关键概念、类别或索引键上。它的核心能力是“理解用户问的是什么领域/主题/意图”。结构化知识库 (知识载体)存储经过精心组织、清洗、关联的领域知识。形式可以是知识图谱、关系数据库、文档数据库包含强元数据、甚至规则库。它的核心能力是“精准、高效、结构化地回答基于关键键的查询”。他核心目标其实是要解决语义相似 ≠ 答案相关的问题向量路由只负责理解意图并将其路由到最相关的“知识抽屉”如“胸痛症状组”、“拿铁配方库”而非直接返回可能包含干扰信息的原始文本片段。后续由结构化的知识库基于精确的键进行查询确保返回的信息与查询目标高度一致。这是一种更贴近人类认知的做法人类在解答问题时也是先理解问题意图路由然后在结构化的知识体系记忆、手册、数据库中查找相关信息最后进行推理和表达生成。只不过该架构的挑战也很明显其结构化的知识库十分难设计并且要考虑其如何与路由向量库交互整体工程难度是很高的。最后给一个流程图用户Query └─► 语义路由层多信号融合 ├─ 向量近邻召回症状/意图/主题簇 ├─ 关键词/BM25/正则/实体识别 └─ 轻量规则黑白名单、领域优先级 │ ▼ 路由决策Top-N 目标{实体、关系、表、规则集、API} │ ▼ 知识载体层结构化 ├─ 知识图谱实体-关系-约束 ├─ 事实表/维度表指标、版本、地域 ├─ 规则引擎阈值、if-then、时效 └─ 特征/检验库医疗、法务、品控 │ ▼ 生成层可选 ├─ 模板化口径严谨场景医疗、法务 └─ LLM 语言润色附引证与可追溯ID学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%免费】