很多人学AI的方式是跑demo装个环境、调一个API、把模型的输出打印出来然后就没有然后了。真到要做一个“能用的AI应用”时才发现问题全堆在工程侧——数据怎么处理、检索怎么设计、Agent怎么编排、效果怎么评估、线上出了幻觉怎么兜底。这篇就完全是围绕“AI工程从零开始”这条主线写的是我自己把一个AI应用从想法推到落地的完整记录包括路线怎么规划、工具怎么选、链路怎么搭、坑怎么踩。文里不会出现“换个皮就是产品”的速成套路也不会塞一堆云里雾里的架构名词而是把你从零搭一个AI应用时会遇到的真实环节全部过一遍。不管你是刚入门想找个清晰方向还是做过传统后端想转AI应用开发这篇都能让你少走不少弯路。1. 从零做AI工程先想清楚这三件事1.1 核心需求别急着追大模型先定义要解决什么项目标题里“from scratch”这个说法很有迷惑性很多人会觉得“从零”就是自己从头训练一个大模型。说实话绝大多数场景根本不需要走到那一步你需要的是一套能围绕大模型把数据、工程、交互组织起来的能力。我做这个项目之前首先逼自己回答一个问题这个AI工程到底要替用户解决什么不回答清楚后面所有技术选型都是空中楼阁。我最终把目标锁定在一个非常经典的场景上——搭建一个基于私有知识库的问答助手。数据是企业内部的文档、手册、历史工单用户问一句话系统先检索相关知识再让模型基于检索结果生成回答。之所以选这个场景是因为它能覆盖AI工程的全部关键环节数据清洗、向量化、检索排序、Prompt编排、上下文管理、结果评估、异常兜底。你把这条链路走通了遇到其他AI应用需求基本都能往这个框架里套。1.2 整体路线从单次问答到完整Agent系统分阶段演进很多教程一上来就教你写Agent但Agent本质上是“在单次问答能力稳定之后”叠加的调度层。我的路线分成了四个阶段每个阶段都有明确的验收标准第一阶段是单轮问答也就是最基础的“问题进来、答案出去”这个阶段要把RAG链路跑通回答质量至少要让人愿意读完。第二阶段是多轮对话引入历史会话管理让模型能记住上下文这是从“问答工具”走向“对话助手”的关键一步。第三阶段是Agent化让模型能调用外部工具查数据库、发请求、算数据这个阶段开始涉及规划、工具定义、结果解析这些复杂工程。第四阶段是可观测与持续迭代给AI应用加上评估、日志、反馈闭环让效果能不断变好。这个演进顺序很重要。我见过很多人一上来就奔着Agent去做结果连基础的检索准确率都没解决Agent越复杂越容易暴露底层问题。1.3 为什么是RAG而不是直接微调模型这是技术选型上非常核心的一个决策点。RAG检索增强生成和微调是两种完全不同的路线很多人把两者混为一谈其实它们的适用场景差异很大。RAG的思路是不改变模型本身的权重而是通过“先检索相关信息再让模型基于信息回答”来提升准确性。它的好处是见效快、可解释性强、知识更新成本低。知识库内容变了重新灌一遍向量库就行。微调则是用一批标注数据去调整模型参数让模型本身学会某种风格或某种知识。它的成本高、周期长而且不适合频繁更新的知识场景。我在这个项目里选RAG还有一个重要原因——准确性和可溯源。企业内部的知识问答用户不仅需要一个答案最好还能知道答案的依据来自哪份文档。RAG天然支持这一点因为模型是基于检索回来的片段生成的你可以把来源附在回答后面。这种“可溯源”的特性对落地价值非常大。2. 工具链选型与开发环境搭建2.1 模型选择API调用还是本地部署这是AI工程里第一个要拍板的决策。我当初做了个对比表把关键差异列得清清楚楚维度API调用本地部署上手速度注册即用几乎零门槛需要显卡和推理框架配置成本结构按量付费波动可控前期硬件投入大后期边际成本低数据安全数据出域需要评估合规数据完全在内网模型迭代跟着服务商升级不用管需要自己跟进新版本运维复杂度低服务商兜底高需要处理推理服务稳定性我的建议是个人学习或做原型直接用API调用的方式效率最高企业项目数据敏感度较高、调用量很大的场景本地部署更划算。我自己先用了API方式把链路验证完再把推理部分切到本地这样两边的坑都心里有数。2.2 开发框架与核心组件避免被花哨名词带偏AI工程的组件其实没有想象中复杂核心就四块模型底座、向量数据库、开发框架、调试工具。我实际开发时用的搭配是“通用底座模型开源向量库轻量应用框架”整体从中选了偏主流的开源产品不绑定某家厂商后续切换的余地很大。提到开发框架LangChain确实名气很大组件全、生态丰富但我要提醒一句——它上手成本不低而且抽象层级较多出了问题排查链路很长。对于想真正理解AI工程底层逻辑的朋友我推荐先用最朴素的方式写一遍直接调模型API自己管理Prompt、自己调向量库的接口、自己写检索逻辑。这个过程会逼你把每个环节的输入输出都搞清楚。之后再切换到框架你会觉得框架只是把你自己做的事封装好了而已。2.3 数据准备最不起眼的隐形工作量跑了几个demo之后你会发现最终决定应用效果上限的不是模型而是数据质量。我在这个项目里有一半以上的时间花在数据上。第一步是格式清洗。原始的PDF、Word、HTML转出来的文本非常脏有乱码、有页眉页脚、有表格错位。我写了一套清洗脚本把文档里无效的页面元素去掉统一编码格式再按标题结构拆成段落。第二步是质量控制。很多知识库文本里有大段重复内容、广告性质的内容、已经废旧的流程说明这些直接进向量库会严重污染检索结果。我用了半人工半自动的方式做了一遍内容过滤。第三步是元数据标注。给每一段文本打上来源、标题、更新时间、所属业务线。这些元数据在后面做检索过滤和结果溯源时至关重要。3. 从零搭建核心链路RAG问答助手的完整实操3.1 需求边界定义先限制范围再逐步放开做AI工程最容易犯的错就是一上来想解决所有问题。我的做法是先做一个“窄而深”的MVP只回答技术手册里能查到的问题超出范围的直接告诉用户“这个问题知识库还没有覆盖你可以换个问法或联系人工”。这个边界定义听起来很简单但实际操作中非常关键它决定了你的效果评估标准、数据治理范围、prompt设计策略。我先整理了200个来自真实用户的提问把它们按“知识库是否已有答案”分成三类已有答案的、部分相关的、完全没有相关内容的。这个分类在后面做评估集时很有用——AI应用不仅要会答更要会“承认不知道”。3.2 数据切分粒度太小没上下文粒度太大检索不准文本切分这块是RAG链路里直接影响效果的一环。切得太小比如按一句话切检索回来的片段往往信息不完整模型拿不到足够的上下文切得太粗比如把一整章切成一个块向量化之后的语义容易被稀释检索回来的准确率也不高。我试验了几种切分策略之后最终采用了一种“结构优先”的做法优先按文档的标题层级切块但每块限制在500字左右超出就按句子边界进一步拆分。另外我还保留了一个“子块引用父块”的逻辑——检索命中的是子块但喂给模型时把父块的大标题带上一同作为上下文。这个设计能同时兼顾上下文完整度和检索精准度。3.3 Embedding与向量检索最容易翻车但最容易被忽视Embedding文本向量化是把文字变成数字向量的过程它的质量直接决定了“能不能找到”。我在这个环节踩过的坑有三个第一个坑是用了通用向量模型对领域术语不友好。技术文档里的缩写、型号名、组合词在通用模型下经常被拆得七零八落。解决办法是在向量化之前对文本做一轮术语归一化处理把常见缩写的全称也拼进文本比如“API”改成“APIApplication Programming Interface”检索时再对查询词做同样的处理。第二个坑是只做向量检索忽略了关键词匹配。很多专业术语的检索“精确匹配”比“语义相近”更可靠。我的最终方案是混合检索先做关键词匹配比如BM25再做向量召回然后把两路结果合并、去重、重排。效果比单一检索方式有明显提升。第三个坑是Embedding的批量提交问题。数据量大的时候逐条调用向量模型效率太低我改成批量提交并加了失败重试和进度日志切分完的数据分批灌入向量库每小时能处理上万条文本块。3.4 生成链路让模型学会引用依据数据准备好、检索跑通之后最后一步才是让模型基于检索结果生成回答。这一环我最大的体会是Prompt的设计决定了下限但在Prompt之前检索结果的组织方式同样重要。我最终的结构是先把检索回来的top-K个文本块拼接成“参考资料”在资料前面明确加上时间、来源、标题等元信息然后在Prompt里用非常明确的指令约束模型——“仅基于参考资料回答不要使用参考之外的知识如果参考资料不足以回答问题直接说明无法回答不要编造。”这比简单地说一句“请基于资料回答”效果稳定得多。另外一个容易被忽略的细节是把“不知道”的权利明确交给模型。很多AI应用回答得天花乱坠本质上是模型在硬撑。你给它一条“允许说不知道”的后路它反而不会乱编了。实测下来加了这句之后幻觉问题明显减少。4. Agent工作流从问答到多步任务4.1 为什么问答稳定之后才适合引入Agent我在前面说过Agent是叠加在稳定问答之上的调度层。它的核心价值在于一个复杂任务可以拆成多个步骤每个步骤调用不同的工具步骤之间传递状态。比如“帮我统计过去一个月工单中的高频问题并生成简报”这个问题单纯靠RAG回答不了它需要先查工单数据、再做分类统计、再生成文本。这就是Agent能发挥价值的地方。其实第三步“生成文本”用RAG就能解决但前两步依赖外部数据源而模型本身不具备操作外部系统的能力。Agent刚好把这个问题补上了——它让模型学会“决定调用什么工具、怎么传参、怎么解析工具返回的结果”。我推荐从最基础的单工具Agent做起让模型学会在“调用检索工具”和“直接回答”之间做选择。这一步走稳了再去设计多工具协同的复杂编排。4.2 工具定义与参数解析把“让模型用工具”这件事讲清楚Agent最关键的工程细节是工具的定义方式。模型不是一个固定的程序它对工具的理解完全来源于你给的函数签名和描述文字。所以工具描述一定要写得像说明书这个工具是干什么的、需要哪些参数、参数的格式是什么、什么样的输入会造成调用失败。我实际踩过的一个坑是工具参数设计得太复杂。比如一个“查询工单”的工具我一开始设计了七八个筛选参数模型经常传错或漏传。后来我把参数设计扁平化只保留最核心的必填项其余全部靠默认值兜底。工具调用成功率从不到六成提升到了九成以上。结果解析同样不能忽视。工具返回的原始数据往往是JSON或表格模型直接读取原始结构经常会出现理解偏差。我在工具内部就把返回结果整理成一句通顺的自然语言摘要用“如下”的形式把关键数据点放在摘要里模型就能比较稳定地引用这些信息生成最终回答。4.3 记忆管理多轮对话的结构设计将Agent应用从单轮扩展到多轮最麻烦的是记忆管理。这里有两种记忆短期的会话记忆和长期的用户偏好记忆。短期记忆我用了一个比较简单的滑动窗口方案按时间倒序保留最近10轮对话超出就丢弃。这里有一个细节值得注意——如果直接把全部历史都塞给模型不仅浪费token还会让模型被无关历史带偏。所以我在塞入历史时会做个筛选只把与当前问题相关的历史轮次拼接进去。判断“相关”的方式不需要太复杂我可以透露一个实用的技巧在拼接历史时给每一轮加上时间和主题标签然后把这轮的User Query与历史主题标签做一个向量相似度比对过滤掉相似度低于阈值的轮次。效果远好于无脑全量拼接。5. AI工程的质量评估没有度量就没有迭代5.1 为什么AI应用不能只靠“感觉还行”传统软件的测试有非常明确的断言——输入A输出必须是B。但AI应用输出天然具有随机性同样的Prompt跑两次回答措辞可能不同。这就给测试带来了根本性挑战。我遇到过太多同学说“我这个AI应用效果挺好的”问哪里好答不上来。这是AI工程里很危险的状态——你没有度量就不知道改动是变好还是变坏。比如你改了一个Prompt模板觉得回答更详细了但实际上可能检索召回率下降了、回答里多了幻觉内容。没有度量体系你根本发现不了这些退化。5.2 三类关键指标检索质量、生成质量、链路质量我搭建的评估体系主要覆盖三个维度。检索质量看两点召回率相关知识是否被找回来和准确率找回来的东西是否相关。这个通过构造测试集来验证我在上面的章节提到的200道问题派上了用场。每一道题都预先人工标注了应该命中哪些知识块跑完检索链路之后自动计算命中率。生成质量看忠实度——模型生成的内容是否全部有参考资料支撑。我实现了一种半自动化的检测方式把生成回答按句子拆开每句话去参考资料里做语义匹配匹配度低于阈值的句子标记为“疑似幻觉”抽样人工复核。这个做法比让人逐条读回答高效得多能在早期发现大部分胡编乱造。链路质量看端到端的满足率用户问题进来整个系统的最终回答是否真的解决了问题。我采取的策略是把评价结果分为“完全满足、部分满足、未满足、无法回答”四级通过一个简单的评分助手模型快速打标再按周抽样人工复检。这套体系跑起来之后每一次Prompt调整、检索策略调整都能立刻知道是好是坏。5.3 回归测试与灰度发布别让一次改动毁了全部效果有了评估集之后最关键的习惯就是回归测试。我给自己定了一个铁律任何Prompt改动、检索参数调整、模型版本切换都要先把完整评估集跑一遍对比改动前后的得分。只要核心指标有下降哪怕新方案在某个案例上表现很惊艳也一律不通过。这种做法在实践里救过我很多次。有一次我优化了检索重排算法单看几个热门case感觉非常棒回答质量明显提升。结果一跑完整回归发现长尾问题的召回率掉了12个点原因是新算法过度偏向热门的语义特征导致冷门术语检索失效。没有量化评估这个劣化根本发现不了。6. 高频问题排查与避坑实录6.1 检索不到相关知识先排查数据层面再排查策略层面这是RAG应用最常遇到的问题。我排查这个问题有个固定顺序先确认知识库数据有没有进全很多“检索不到”其实是数据遗漏先检查切分和灌库日志再检查查询文本的向量化质量如果查询里包含大量口语化表达先做查询改写把口语转换成与文档一致的术语风格然后再看召回数量如果top-K太小真实相关的内容可能排在后面没有被取到。实测下来“查询改写”对检索命中率的提升非常显著。我专门写了一个小的LLM调用步骤把用户的原始问题改写成两个版本一个是保持原意但更正式的表述另一个是关键词更丰富的检索式表述。两个版本同时拿去检索召回集合明显变大。6.2 回答幻觉严重问题可能不在模型在上下文结构当模型生成的回答里出现知识库没有的内容时很多人第一反应是换更强的模型。但根据我的经验一半以上的幻觉问题出在Prompt结构或上下文组织上。一个容易被忽略的点是检索回来的文本块如果拼接过密模型会分不清“资料边界”在哪里容易把不同来源的信息串在一起。我后来在拼接参考资料时每块之间明确加了分隔符并标注段落编号Prompt里也强调编号引用规则幻觉率明显下降。另外如果参考资料里混杂了与问题无关的干扰信息模型可能会被带偏。我在送入Prompt前加了一道相关性过滤得分低于阈值的文本块直接丢弃不要让模型“阅读”无关内容去尝试分析。6.3 Token成本飙升上下文管理是一项持续优化工作AI应用上线之后很快会发现Token消耗非常快。这里的主要消耗不是单轮的Prompt而是多轮会话的上下文堆积、以及检索回来的内容块过多。我采取的优化手段有四个方向一是给每轮对话增加相关性过滤不相关的历史轮次不进上下文二是检索回来的文本块先做摘要压缩再送入模型可以只保留与问题相关的句子三是为长时间会话设置token上限超过上限就自动丢弃最老的对话并提醒用户四是把系统指令里的固定文案精简——一些你长期不修改的描述内容其实可以放进缓存层避免重复计算。我算过一笔账做了这四类优化之后同等业务量下Token开销下降了约四成。7. 一些关于AI工程方法的个人心得和实操建议最后再分享一些我在这个项目里沉淀下来的经验。有些是我自己踩过坑之后总结出来的希望能帮大家少走一些弯路。先用最简方式跑通完整链路再做优化。这是我反复强调的原则。很多朋友拿到一个AI项目第一反应是去配置各种框架组件结果花了两周时间还在搭环境。正确的顺序是先做最小的完整闭环——哪怕只用几十条数据也要让“用户提问→检索→生成→回答反馈”全流程跑起来然后再一项一项去优化。建立一个“坏例库”比收藏100篇教程有用。我在项目里维护了一个文档专门记录失败的案例哪个问题回答错了、错在哪里、当时是怎么修好的。每次调优完重新验证的时候先跑这批坏例。这个习惯帮我快速发现回归问题。效果不好的时候打开坏例库看看往往能直接定位到问题原因。不要追求一步到位AI工程的核心是“持续小步优化”。我做AI工程最大的体会是没有一蹴而就的方案每个阶段都有每个阶段的核心矛盾。刚开始是数据问题然后是检索问题然后是生成质量然后是性能和成本最后是长期效果维护。每个阶段都有对应的核心问题不要试图在一个阶段解决所有阶段的问题。如果你也想在AI工程这条路上走远一点我的建议是从建立自己的评估集开始认真记录每一次改动前后的效果差异让数据替你说话。因为AI工程的判断标准不应该来自“我觉得挺好”而应该来自可观察、可量化的真实反馈。这个过程不会特别轻松但当你把这条闭环跑完之后对AI的应用能力会有质的提升——它不再是黑盒调用而是真正属于你自己的工程能力。