我一直觉得企业做AI落地这件事最怕的不是技术难而是被一堆新概念绕晕。今天聊的“AI铁三角”其实是这几年我跑项目下来发现几乎所有能真正创造业务价值的智能化系统底层都是同一套组合拳大模型做大脑、RAG当家底、Agent当手脚。三个角色各管一摊缺了谁都会出问题。这篇文章适合两类人看一类是还没系统接触AI应用的小白看完能建立完整认知框架另一类是刚被安排做智能化调研的技术负责人可以拿这套框架去评估方案、说服老板。我尽量用大白话讲透原理也会给出可以直接参考的落地路径。1. 先把铁三角认全大模型、RAG、Agent到底各管哪摊1.1 我看过无数项目后最值钱的一个判断框架先回答一个最基础的问题为什么是这三个东西组成“铁三角”而不是别的你可以把一个企业级AI系统想象成一个刚入职的高学历新人。这个新人智商很高、反应很快但对企业业务一无所知而且刚听完培训就敢直接上手干活。听着是不是很危险现实里的AI系统如果不做额外设计就是这个状态。大模型提供的是“智商”。它擅长理解你的问题、组织语言、做逻辑推理但它脑子里装的是互联网上的公开知识训练完就固定了。你问它行业通用问题它头头是道你问它“咱们公司上个季度华东区的退货率为什么涨了”它就只能开始编了——因为它根本没看过你们公司的数据。RAG解决的是“知识”问题全称叫检索增强生成。核心思路很简单不让模型瞎猜而是先到你们公司的知识库里把相关资料搜出来塞进它的上下文里让它“看着材料回答”。这就好比给那个新人配了一整个公司的档案室遇到不懂的先查档案再发言。Agent解决的是“行动”问题。大模型再聪明、知识再全也只是在对话框里吐字。企业要的是它能查数据库、改表格、发消息、调系统。Agent就是让模型学会使用工具把一个复杂任务拆成几步自己决定什么时候调用哪个工具把事真正办成。所以这套组合的逻辑非常顺大模型负责思考RAG负责记忆Agent负责执行。三者互为支撑少了任何一个要么是胡说八道的聊天机器人要么是只会查资料的工具箱要么是疯狂调接口但不知道自己在干什么的“无头苍蝇”。1.2 三个组件是怎么配合的一个客服场景讲明白光说概念还是抽象我拿一个最常见的场景——企业客服知识助手——来拆解三者的协作流程。假设你们公司要做一套客服助手帮一线客服快速回答用户问题比如“订单延迟了怎么补偿”“发票怎么开”。传统做法是做个关键词搜索框体验很差。用AI铁三角来做流程是这样的第一步用户问“我上周买的手机还没发货能赔我吗”。大模型先发挥作用它理解这其实是在问物流延迟的赔偿政策。第二步RAG上场系统把这个问题的语义转成向量去知识库里检索把“物流延迟赔偿标准”“投诉升级流程”等几份文档的相关段落捞出来和原始问题一起打包。第三步Agent根据检索到的资料判断这个问题是否需要额外工具——比如要不要查一下这个用户的订单状态、是否处于特殊时期。如果需要就调用订单查询工具拿真实数据再结合政策文档生成一段有理有据的回复。整个过程用户感受到的只是“秒回”背后其实是三个组件各自干活的接力赛。我见过不少团队一开始只接一个通用大模型API就以为完事了结果一问业务问题就露馅回头才补RAG后来又发现模型只会说不会做再补Agent。与其这么一步步踩坑不如一开始就把铁三角的框架搭起来。2. 拆开看每一角核心原理和小白也能用的选择思路2.1 大模型智商底座怎么选才不踩坑大模型是整个系统的大脑选择它要权衡四件事能力、成本、速度、数据合规。先说能力。不同模型在逻辑推理、长文本理解、中文表达上天差地别。但绝大多数企业场景用不到最强模型客服问答、文档总结、报表解读这类任务中等偏上能力的模型完全够用。我的经验是先把任务清单列出来拿10条最典型的业务问题去“考”几个候选模型看谁的答案更稳而不是单纯看排行榜。排行榜分数相差几分在真实业务里几乎感觉不出来。再说成本。商用API按token计费几万人的企业每天如果有几十万次调用推理成本确实不是小数。如果是强合规行业数据不允许出域就得考虑私有化部署开源模型。这里有个常见的误区一上来就想着部署几百亿参数的大模型其实很多公司最后的归宿是一个十几B到几十B的模型加一套好RAG。模型小反而推理快、部署省配合RAG的知识补充效果一点不差。我在多个项目里验证过一个中等规模的模型加上高质量的知识库可以打败一个超大模型硬答的效果成本和延迟还低一个数量级。还有个容易忽略的点上下文长度。现在新出的模型动不动就宣称支持超长上下文但实际用下来真把几十万字全塞进去模型会“注意力涣散”抓不住重点而且推理速度明显变慢。RAG的意义就在这里它只把最相关的几段资料喂给模型让模型可以在一个轻量、精准的上下文里工作。所以选型别只看“窗口多大”要看“它能不能在小上下文里干好活”。2.2 RAG把企业知识装进模型脑子的正确姿势我一直把RAG比作“给AI配一个随叫随到的资料员”。资料员要干三件事把材料整理好放进档案室离线索引、按需把相关材料抽出来在线检索、把材料整理成模型爱看的格式上下文组装。第一件事的关键是切分。企业文档千奇百怪有PDF、Word、Excel、PPT还有扫出来的图片。你得先把它们解析成干净的文本再切成一段一段的“档案条目”。切多大有讲究切得太小每段的信息不完整检索容易断章取义切得太大一段里混入太多无关内容模型读起来费力。我常用的起点是每段512个token左右同时让相邻段落有64个token的重叠保证话题连贯。更讲究一点的做法是“按结构切”——比如按Markdown的标题层级来切一个二级标题下的内容作为一整段这样语义完整性好很多。第二件事的关键是向量化。切好的文本要转成一组数字向量语义相近的文本在向量空间里离得近。这个转换要用专门的嵌入模型来做。中文场景我建议用针对中文优化的开源向量模型效果比拿通用模型硬扛好很多。检索的时候把用户的问题也转成向量去档案室里找最接近的几十条。第三件事容易被新手忽略检索结果不能直接塞给模型。常见做法是加一道“重排”用一个重排序模型把召回的候选段落重新精排一遍去掉和问题无关但向量上接近的结果只保留最精华的3到5段拼成带来源标注的上下文。这样模型既能拿到足够信息又不至于被噪声干扰。我在实操中反复确认过加不加重排答案准确率可以差10到20个百分点。2.3 Agent让模型从“会说话”变成“会办事”Agent是铁三角里最能体现“智能化”的一环也是最容易失控的一环。它的核心机制叫“工具调用”模型不仅输出回答还能输出“我想调用某个工具参数是什么”的指令系统拿到指令后真正执行再把结果还给模型。要理解Agent先看一个最简单的形态。你给模型注册一个“查订单状态”的工具用户问“我的订单到哪了”模型识别出意图输出一个结构化指令调用这个工具拿到结果后组织成自然语言回复。这一步看起来简单却让模型从“聊天机器”变成了“业务助手”。再复杂一点Agent可以做多步规划。比如用户说“帮我统计这个月各区域销售额并生成周报”模型会自己拆解成三步先查销售数据库再汇总计算最后生成一篇报告。每一步之间模型会观察上一步的结果再决定下一步怎么做。这就是所谓的“思考-行动-观察”循环。企业做Agent最容易踩的两个坑一个是工具描述写得太含糊模型根本不知道这个工具是干什么的、什么时候该用另一个是不设执行上限模型在一个任务上反复循环Token烧了一堆事情还没办完。我后面会详细说怎么处理。核心原则是Agent的能力边界要在设计阶段就划清楚。3. 落地实操从零搭一个企业级AI铁三角的最小可运行系统3.1 先定架构再谈细节光有概念不够我带你走一遍真实落地路径。假设我们要做一个面向企业内部的“制度问答与工单处理助手”数据源是几十份制度文档外加一个可以查询员工信息的接口。整体分为五层模型层选一个商用API模型或私有化模型作为大脑。知识层制度文档经过解析、切分、向量化存进向量数据库。检索层负责query改写、向量召回、重排。执行层Agent编排引擎负责解析意图、调用工具、组装上下文。应用层一个简单的对话页面或者是IM机器人。准备清单也一并列出来向量数据库常见的开源方案如Milvus或Qdrant、嵌入模型、重排模型、Python环境、Agent框架LangChain或LlamaIndex这类也可以自己写不复杂。我第一次做这整套东西从零到跑通大概花了一个周末。绝大多数时间不是花在代码上而是花在数据清洗上——这点你最好有心理准备。3.2 第一步文档预处理与向量化我按真实流程写一段核心逻辑你可以当伪代码看。# 假设你已经把PDF/Word都解析成了干净的文本plain_texts from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size512, # 每段最大字符数中文场景可以按这个来 chunk_overlap64, # 相邻段重叠避免切断语义 separators[\n\n, \n, 。, , , , ] ) chunks [] for doc_name, text in plain_texts.items(): for i, chunk in enumerate(splitter.split_text(text)): chunks.append({ content: chunk, metadata: {source: doc_name, chunk_index: i} })这里有个非常实际的建议在切分前先把文档里的页眉页脚、水印、重复表格清掉否则检索的时候你会经常看到带着“机密文件第几页”这种噪声的片段被召回既浪费上下文又干扰判断。接着做向量化入库from sentence_transformers import SentenceTransformer embed_model SentenceTransformer(bge-large-zh) # 开源中文向量模型 vectors embed_model.encode([c[content] for c in chunks]) for chunk, vec in zip(chunks, vectors): collection.add( ids[f{chunk[metadata][source]}_{chunk[metadata][chunk_index]}], documents[chunk[content]], embeddings[vec.tolist()], metadatas[chunk[metadata]], )入库之后要做一次“抽查”随便拿几个典型问题去检索看召回的段落是不是真的相关。这一步能在早期暴露问题否则等整个系统搭完再调排查成本高得多。3.3 第二步检索链路与答案生成检索不能只看向量。我的推荐是“混合检索重排”。混合检索就是向量检索和关键词检索比如BM25各跑一路取并集然后交给重排模型精排。关键词检索对专有名词、型号、编号特别友好向量检索擅长捕捉语义两者互补。from pymilvus import Collection from sentence_transformers import CrossEncoder # 1. 向量召回 col Collection(company_kb) vec_results col.search( data[embed_model.encode(user_query)], limit30, output_fields[content, metadata], ) # 2. BM25召回伪代码假设你建了倒排索引 keyword_results bm25_search(user_query, top_k30) # 3. 合并去重 candidates deduplicate(vec_results keyword_results) # 4. 重排精排 reranker CrossEncoder(bge-reranker-large) pairs [[user_query, doc.content] for doc in candidates] scores reranker.predict(pairs) top_docs [doc for _, doc in sorted(zip(scores, candidates), reverseTrue)[:5]]召回数量我建议第一步多取一些比如30条重排后再砍到3到5条。如果第一步就取5条一旦某条关键内容因为切分问题没被召回后面重排再准也救不回来。组装上下文的时候要遵守一个原则让模型知道这些材料是“参考答案”而非“标准答案”。我的prompt模板大致是这样你是企业内部制度问答助手。请严格依据以下参考资料回答用户问题。 如果资料中没有相关信息请明确回答“资料库中未找到相关内容”不要自行推测。 参考资料 [1] 来源制定文档A第12页…… [2] 来源制定文档B第3页…… 用户问题……加末位的“不要自行推测”这句话能显著降低模型强行编造答案的概率。同时要求每条回复标注引用来源后续查问题也有据可依。3.4 第三步Agent编排与工具接入Agent这一步如果业务逻辑不复杂可以不用任何框架直接用模型的工具调用能力来实现。tools [ { name: query_employee_info, description: 查询员工的基础信息例如部门、职级、联系方式。参数employee_id员工工号或employee_name员工姓名。, parameters: { type: object, properties: { employee_id: {type: string}, employee_name: {type: string} } } }, { name: create_work_order, description: 创建一条工单记录用户提交的诉求。参数category问题分类、description问题描述、priority优先级高/中/低。, parameters: { type: object, properties: { category: {type: string}, description: {type: string}, priority: {type: string} } } } ]循环调用的骨架是这样的把用户问题和工具列表一起发给模型模型如果判断需要调用某个工具就返回一个带有结构化参数的调用指令系统执行工具后把真实结果作为新的消息追加进对话继续让模型判断下一步。如果模型不再要求调用工具就把最终回答返回给用户。这里最关键的工程细节是轮次限制。我强烈建议把最大循环次数设为5到8轮超过就停止并提示“问题过于复杂请分步咨询”。否则你会看到模型在一个问题上反复横跳一轮轮调工具上下文中途爆炸账单也爆炸。工具描述的质量直接决定Agent好不好用。描述要包含三要素这个工具是什么、在什么场景下用、参数怎么填。比如“查询员工信息”的工具要写明“当用户询问某员工的部门、职级等情况时使用需要提供员工工号或姓名”。写得太泛模型会把所有问题都往这个工具上靠写得太窄真正该用的时候它又不会用。我一般是先写一版拿20个典型问题跑一遍看哪些该触发没触发、哪些不该触发乱触发再回头改描述。4. 实战踩坑记录AI铁三角最常见的6个翻车点4.1 检索结果乱、答非所问问题多半出在切分检索不准是所有RAG系统上线前最让人头秃的问题。我接到过最典型的一个案例某公司把一批包含大量表格的制度文档直接按固定长度切分结果每个表格被拦腰截断字段和值对应不上模型拿着残破的表格信息一本正经地编答案。这种问题切分规则再优化也难根治我当时的处理方案是把表格识别出来单独走结构化抽取转成Markdown格式后再切分才算稳住。另一类常见问题是专有名词召回失败。公司内部的系统缩写、产品代号向量模型没学过语义检索根本召不回。这时候BM25关键词检索的价值就体现出来了。我现在的标准姿势是混合检索打底重排兜底基本能覆盖九成以上的检索问题。还有一招很实用在向量化的时候把高频专有名词作为一个整体词用一个特殊符号包裹比如“#退货退款率#”让它不被切碎。4.2 Agent跑飞了无限循环和Token烧穿Agent项目上线前我最担心的问题永远是“跑飞”。具体表现是模型自己提问自己回答、反复调用同一个工具、一次任务调了十几个工具最后也没出结果。原因无外乎工具描述有歧义、任务被拆得过度、上下文太长导致模型注意力涣散。我在工程上做三件事来兜底第一硬性轮次上限前面说过5到8轮必停第二token预算大致估算每轮消耗设置一个总量阈值超过就自动终断第三结果校验工具执行失败或返回空结果时直接把失败信息喂给模型让它换一种方案而不是傻傻再调一次同样的参数。另外一个容易被忽视的点是给模型提供“终止条件”。在系统提示里明确写如果问题已经得到解决或确认无法解决都必须结束流程并输出最终答复。很多跑飞其实是因为模型不知道该什么时候停。4.3 知识库里有答案模型还是胡说八道这是最气人的情况资料明明在库里检索也召回得很准模型却结合自己的“记忆”强行发挥。根源在于模型原本的知识太强和资料冲突时它会倾向于相信自己熟悉的说法。我们做过对比在prompt里明确强调“只在资料范围内回答”并追加一句“如果资料与你的常识冲突以资料为准”之后幻觉率明显下降。更可靠的手段是让答案“有据可查”。我们要求模型在回答末尾用角标标注引用来源比如“[1][2]”回答结束后附上来源列表。这样即使偶尔出错也能快速定位是哪份资料误导了它。再进一步可以加一层“引用检测”模型回答后程序自动检查回答中的关键数字和结论是否真的出现在引用段落里如果对不上就判定为疑似幻觉重新生成一次。这招还是从质检同学那里得到的启发。4.4 指标好看了业务部门还是不用最后一个坑往往不在技术而在验收方式。有些团队拿十来条测试用例调prompt调到感觉“差不多了”就推向业务结果真实场景一来就崩。我后来养成一个习惯正式上线前必须让业务方提供50到100条真实历史问题把标准答案也标注好做成评测集。每次改动prompt、调整切分参数、更换模型都拿这套评测集跑一遍算准确率还要看badcase的变化。没有评测集的AI项目后续迭代就是开盲盒。评测集建立后你会发现很多之前没注意到的问题。比如某类问题总是答得不对排查下来是文档里根本没有相关内容业务方以为有、库里就是没有。这时候该补文档补文档该走人工兜底走人工兜底。还有响应速度检索太慢、生成太长用户等不了三秒以上。优化思路是流式输出、缓存热点问题、把重排模型换成更轻量的版本。这些细节没有真实流量压一压永远暴露不出来。我在实际项目里还有一个很深的体会AI铁三角的落地过程本质上是一个不断对齐的过程。技术组件之间要对齐业务预期和技术实现之间更要对齐。很多团队只盯着模型选型和算法调优忽视了知识库的质量和评测机制结果就是技术指标再好看业务同事用起来依然觉得“不如我自己翻文档”。如果你正打算启动类似的智能化项目我的建议很简单先把业务问题和现有数据梳理清楚再动手接模型、搭RAG、上Agent。顺序反了后面全是返工。最后分享一个小技巧铁三角不是一次搭完就固定不变的。RAG的文档要跟着业务制度更新Agent的工具要跟着系统接口变化模型本身也会不断升级。把这套系统做成一个能持续迭代的框架比一次性做到“完美”重要得多。我习惯每季度用评测集重新验证一遍全流程更新文档、调整提示词、升级组件版本这样整个系统才能一直保持在可用状态。