★ FEATURED ARTICLE 直接说结论现在大家讨论的AI工程早就不是“写个Python脚本调一下API”这么简单了。我看到“ai-engineering-from-scratch”这个标题的第一反应是这哥们想做的不是又一个demo而是一整套能跑、能维护、能评估、能迭代的AI应用落地方法论。这个方向太对了太多人卡在“模型能跑通”到“系统能稳定工作”之间的那段路上。这篇文章我不打算讲什么高深理论就是拆解一个从零开始的AI工程到底该怎么搭核心模块有哪些每步怎么选型、怎么避坑。不管你是技术负责人、后端开发还是刚转行做AI应用的只要想把手里的LLM应用做成真正能扛业务的系统这篇内容应该能帮你把整个链路梳理清楚。1. 内容整体设计与思路拆解1.1 到底什么才算“AI工程”先说个我观察到的普遍现象。很多人觉得用LangChain写了几个chain或者用Dify拖了个工作流就算“做AI”了。这离工程化还差得远。真正的AI工程至少得包含数据管线、上下文工程、模型调度、评估体系、可观测性、成本和风险控制这几块缺一不可。从零开始做AI工程脑子里要有一张完整的地图。我自己的习惯是把整个系统分成四层来看数据层文档解析、清洗、切片、向量化、索引构建这是RAG的底座也是幻觉的主要来源之一。推理层模型调用、Prompt模板管理、结构化输出、函数调用、多模型路由。这一层决定了AI的下限。应用层Agent编排、业务流程注入、工具调用、状态管理、人工审核机制。评估与运维层离线评测集、线上日志、质量监控、回归测试、成本统计。这套分层不是学术定义是从实际踩坑里总结出来的。你拿着这套分层去对照自己的项目会发现自己缺的往往不是模型能力而是数据层和评估层根本没建起来。1.2 为什么很多AI项目死在“demo完成之后”我做过的AI项目里失败率最高的阶段不是技术验证而是demo到生产的过渡期。demo阶段你只需要证明“模型能回答对几个问题”生产阶段你需要证明“系统在数据变化、模型升级、用户乱问的情况下仍然能保持可接受的准确率”。这里有个非常反直觉的点如果你从零开始设计AI工程应该先把评估体系做出来再回头优化Prompt和RAG链路。因为只有评估体系立住了你才能知道每次改动是变好了还是变坏了。没有评估体系的AI项目优化全靠感觉上线全靠运气。我还发现很多开发者的第一反应是“先选个大模型”。这个思维在工程化视角下是错的。正确的顺序应该是先定义场景和指标再决定用哪种模型方案。比如客服问答场景你需要的是可插拔的kbknowledge base管理能力还是模型本身的通用知识就够这决定了你是走RAG、走微调还是直接裸模型加细Prompt。2. 核心细节解析与实操要点2.1 数据管线的关键环节与参数选择数据管线是整个AI工程里最枯燥但最决定成败的部分。我见过太多项目模型烂得离谱根因其实是喂进去的数据烂。做AI工程的数据管线要重点解决两件事怎么把非结构化数据变成可检索的片段怎么让检索结果真正匹配用户意图。文档切片是第一道坎。切得太碎了上下文碎片化模型抓不住重点切得太粗混入大量噪声检索精度和召回的效率都会下降。我常用的策略是“语义段落切分semantic chunking重叠窗口overlap”。不是按字符数硬切的而是按标题、段落、句子边界来切再把过短的片段和相邻片段合并。这里给一组我实测比较稳的初始参数具体还要根据文档情况调整chunk_size按场景分FAQ类切200~400字符长文档切800~1200字符。chunk_overlap80~200字符目的是避免句子被拦腰截断导致语义缺失。切片单位优先考虑用Markdown标题、段落、甚至代码结构作为边界。索引方式先用BM25做稀疏检索再用向量检索做语义召回最后用Rerank模块做精排。很多人会忽略“标题锚点”的作用。切片时把文档的层级标题作为上下文拼进每个chunk会让检索命中率明显提升。比如一个产品手册里提到“温度范围”如果chunk里只写着“工作温度0~40℃”没有“环境要求”这个标题前缀检索时关键词匹配会非常吃亏。所以在切片阶段把父级标题带进文本内容是一个性价比极高的预处理手段。向量化的关键选择在于Embedding模型。如果你的文档是中文为主直接套用通用英文Embedding模型效果会差不少。建议优先用中文语料训练或做过多语言适配的模型。另一个实操技巧是Embedding模型尽量和Rerank模型分开选型别指望一个模型既做召回又做精排还能都做得很好。2.2 上下文工程RAG和Prompt的实际操作边界RAG不是简单地把检索结果塞进Prompt就完事了。我做了这么多项目之后最大的感悟是RAG的精度上限取决于你对检索结果的“信任度”。而信任度要靠一套完整的上下文工程来解决。在你把检索片段交给模型之前需要回答三个问题第一这个片段到底和用户问题有多相关相关性阈值设置多少才不会误召回第二多个片段之间会不会自相矛盾如果有矛盾怎么裁决优先级第三片段里有没有冗余信息冗余信息会不会把模型带偏我常用的做法是引入两层过滤。第一层是粗滤用一个比较宽松的相似度阈值把明显不相关的片段过滤掉比如阈值为0.5~0.6具体取决于Embedding模型分布。第二层是精排把Top 20的候选片段交给Rerank模型重新打分取Top 3~5进入上下文窗口。这里要注意Rerank之后别只看分数要关注片段间的相对差距如果第一名和第二名分数差距很小建议同时保留这两个片段让模型自行判断也能避免一次“极端排序”带来的上下文误伤。Prompt本身的工程也容易犯傲慢的错误。别一股脑把所有东西都塞进System Prompt里。System Prompt的最佳状态是“稳定、简洁、可复用”把变化的内容放到每轮请求的动态上下文里。我习惯把“任务指令”“输出格式约束”“上下文材料”“历史对话”这四个部分拆成独立的模板变量而不是混在一个字符串里反复拼接。这里分享一个我自己一直在用的小技巧在Prompt里显式地给模型“拒绝回答”的出口。很多AI系统给用户的体验差不是因为答错而是因为不懂装懂。在Prompt里加一句“如果依据上下文无法确认答案必须明确回复‘目前知识库中未找到相关信息’”能大幅减少幻觉。但注意不要只给一句话还需要配一个“可回答性的评分预判”环节让模型在正式回答前先自查有没有足够的上下文依据。2.3 Agent编排的注意点Agent是AI工程里最容易让人产生“技术兴奋感”的模块但它也是失控重灾区。做Agent编排我的建议是能不用Agent就不用Agent如果非用不可务必给它加牢笼。这句话不是反对Agent而是告诉你工程化场景里稳定性和预期性比炫技重要得多。大部分业务场景本质上是有固定流程的比如“查天气、再查机票、最后推荐酒店”这一套编排用确定性流程就能写死。用Agent自由调用工具确实能应对更复杂的场景但代价是推理链路不可控、Token成本翻倍、错误路径难以追踪。如果业务确实需要Agent至少要做好三件事第一工具白名单。Agent只能调用预先注册好的函数绝对不能让它自由拼接系统指令。第二最大步数限制。单轮任务最多执行N次工具调用超过就强制收敛并进入兜底回复。第三人在环Human-in-the-loop设计。涉及高危操作或金额操作必须插入人工确认节点。我在生产环境还会额外加一层“意图分流”。用户在输入的时候先判断是闲聊、知识问答还是复杂任务。只有复杂任务才进入Agent编排链路其他场景直接走对应的轻量模块。这样做的好处是大部分高并发请求落在简单的RAG或固定流程上成本和延迟都能压下来。3. 实操过程与核心环节实现3.1 目标场景拆解以“企业知识库智能助手”为例为了把上面的方法落到可执行层面我拿一个我非常熟悉的场景来讲企业知识库智能助手。做这个场景的AI工程要解决的核心痛点是员工每天花大量时间在内部文档里翻找信息。而AI助手要做的就是把这些文档变成可交互的接口。先做需求拆解。企业知识库助手分三个层级第一级精准问答。“报销流程是什么”“年假制度怎么规定的”这类问题需要精准命中对应文档片段。第二级归纳总结。“给我汇总这份项目的风险点”需要跨多个文档做内容聚合。第三级操作引导。“帮我创建一个项目立项申请”需要理解业务流程并调用对应工具完成操作。不同层级的复杂度差异很大。第一级用传统RAG就能解决第三级必须引入Agent。我的建议是先做扎实第一级再往上叠加第二级和第三级。很多项目一上来就想做“全自动智能体”结果连文档检索的准确率都没优化好最后体验一团糟。3.2 从零搭建RAG链路的实操步骤我先说清楚这部分的操作路径再给每个环节的关键参数和意图。第一步数据准备。把企业内部文档统一转成Markdown或纯文本格式。这一步是为了去掉PDF、Word里的复杂排版问题让后续切片的稳定性能达到工程标准。第二步切片。按文档结构优先切分再结合长度限制做二次切分。比如一个chapter太长就在二级标题处断开。每个chunk以“父标题内容”的格式存储同时保留来源、页数、文档名作为元数据。切片完成率要做到100%任何解析失败的文件都要在日志里单独标注不静默丢弃。第三步向量化。调用Embedding模型把每个chunk转成向量。这里要记录模型版本和向量维度因为后续升级模型会导致整个库需要重建索引。没有做版本管理的向量库以后每次模型升级都等于技术债爆发。第四步构建双路检索。BM25索引负责字面匹配向量索引负责语义召回。双路结果做融合排序。我常用的策略是分别取两边Top 20做RRFReciprocal Rank Fusion融合再交给Rerank模型精排最终取Top 3~5作为上下文。第五步接入Prompt。在Prompt里明确告诉模型你有两份信息来源第一份是检索到的知识库片段第二份是你的通用知识。当片段信息不足时优先用片段片段无法回答时直接承认不知道。整个过程里有四个参数需要特别关注top_k进入Rerank阶段之前保留多少候选一般是20~30。top_n最终进Prompt的片段数一般3~5具体看模型上下文窗口。rerank_score阈值不同Rerank模型分数分布差异很大建议在真实数据上跑一遍分布再设阈值。temperature知识问答类场景通常设0.1~0.3避免模型自由发挥。3.3 Agent编排的轻量实现再演示一下轻量Agent怎么搭。我用的是“状态机工具注册中心”模式而不是让Agent完全自主规划。工具注册中心是一个列表每项包含工具名、参数协议、权限等级、超时时间。Agent在推理时只能从注册中心里选择工具不能绕过注册中心去调用其他函数。状态机则定义了整个业务流程的节点流转。比如“获取报销流程”这个任务状态流转是意图识别 → 关联政策检索 → 生成步骤说明 → 可选操作打开报销系统。每一步都是可控的模型只负责填参数不负责决定流程走向。这种半自主模式的好处是你可以清晰地知道用户卡在哪一步以及Agent在哪一步执行错误。全自主Agent的推理过程是黑盒出了问题你也很难从日志里定位只能看到模型在反复调用同一个工具空转这种体验我实在不想再来一次。3.4 评估体系的从零构建评估是AI工程里我投入精力最多、也是回报最明显的一块。没有评估体系前面所有的优化工作都像在黑夜里开车。我构建评估体系分三个步骤。第一建评测集。从真实用户日志里挑选200~500条典型问题覆盖常见场景、边界场景、问题变体和已知的失败案。失败案尤其重要每次线上出了badcase都要收敛到评测集里确保后续优化不会让同样的错误复发。第二定评测维度。我常用四个维度准确率、完整度、可读性和安全性。准确率看核心事实是否正确完整度看必要信息是否遗漏可读性看表达是否清晰安全性看是否触发了不当内容或幻觉风险。每个维度按1~5分打分也可以用大模型当裁判做自动打分但一定要抽样人工复核。第三做回归测试。每次修改Prompt、更新切片策略、更换Embedding模型之后都要在评测集上跑一遍全量回归。我的标准是准确率下降超过1个百分点就不能上线。还有一个容易被忽略的指标叫“拒绝率”。系统在无法判断时是否敢于拒绝回答。很多AI系统为了追求“有求必应”硬编答案结果幻觉率飙升。我把拒绝率当成一个独立的健康指标在监控太高说明知识库覆盖度不够太低说明系统在胡编。4. 常见问题与排查技巧实录4.1 检索质量差的典型原因AI工程落地过程中最省时间的投入就是学会快速排查检索质量问题。我整理了四个最常见的病根。第一是切片不合理。明明有相关内容但切片的时候把关键信息拦腰截断导致两个片段各有一半信息检索时两段都命中但都不完整。排查方法是人工挑几个badcase看看返回的chunk内容是否完整涵盖答案。解决方法是调大overlap或者改成“以段落边界为主、长度限制兜底”的切分策略。第二是Query与文档用词不一致。用户问“工资什么时候发”文档里写的是“薪酬发放日期”。字面上匹配不上向量召回也弱。解决方法是做同义词扩展或建立领域词表在检索时对Query做轻度改写。第三是Embedding模型和业务领域不匹配。通用模型在垂直领域医疗、法律、金融的效果往往很有限。解决办法是用领域语料微调Embedding模型或者换一个在目标领域有优势的商用Embedding。第四是上下文窗口塞了太多低相关片段。前3个相关后5个全是模糊相关的。模型在大量噪声干扰下更倾向回答通用知识而非片段信息。解决方法是降低top_n并设置一个更严格的Rerank阈值。4.2 幻觉问题的排查思路幻觉是AI应用里最致命的问题但我发现很多人遇到幻觉就直接甩锅给模型完全不去排查其他环节。其实工程层面能做的预防非常多。我的排查路径是什么先查Prompt里有没有强制要求“只能根据上下文回答”再查检索片段里是否存在信息冲突然后查系统里有没有给模型足够的“说不知道”的空间最后才是考虑换一个更强的模型。前面三步没做好换再大的模型也白搭。还有个小经验分享不要在System Prompt里写太长太复杂的自我认知。比如你让模型扮演“企业智能助手”就要给它定“人设边界”——能干什么、不能干什么、不知道的时候怎么说。人设写得模糊模型就会倾向于用“通用人工智能”的默认行为模式来回答也就是自由发挥幻觉率直线上升。4.3 成本与性能调优记录最后聊一个几乎所有从零做AI工程的人都会遇到的问题成本失控。我做过的案例里成本最大的来源不是模型推理本身而是把太多不必要的内容塞进上下文。很多方案的Prompt动辄3000~5000个token其中一大半是重复的历史对话和无关知识片段。我的优化习惯是首先控制上下文长度把知识片段之外的内容压到500 token以内。其次做问题分类复杂问题走大模型简单问题走短Prompt的轻量模型。再采用缓存策略对固定知识片段的Embedding结果做长期缓存不重复计算。最后控制历史对话轮数超过5轮就做摘要压缩而不是原样拼接。性能上工程化的关键是横向扩展。如果你的链路是“BM25 向量检索 Rerank LLM”那这四个组件的资源消耗完全不一样。建议单独部署重计算放GPU做Embedding和Rerank检索实例用纯CPU撑高并发LLM推理走单独的模型服务。这样任意一个环节出现瓶颈都可以独立扩容不会互相拖累。成本监控也要做细不是看月底账单而是要按业务线、按功能模块拆分数Token消耗。哪条链路消耗最高一目了然。我发现很多团队连基本的Token消耗统计都没有月底账单爆炸却找不到源头。5. 从零到一给新手的落地建议写到这里其实整体链路已经梳理得差不多了。但我还想再给那些刚准备入手的读者多添几句自己的切身感受。做AI工程最大的误区是一开始就想做一个“全能系统”。全能系统做成之前你可能已经耗尽了团队的耐心。我的经验是从零开始一定要划出一条“最小可用边界”。比如企业知识库助手最小可用边界就是能精准回答10个高频问题检索命中率超过90%且拒绝率在合理范围内。先把这10个问题做到极致再逐步扩展知识库范围和增加Agent能力。另外AI工程的代码质量要求不比传统后端低。别因为它是AI应用就把代码质量放松了。Prompt模板要纳入版本管理Embedding模型的版本要记录在向量库的元数据里评测集要像测试用例一样维护。每一行配置的变化都要能追溯到“为什么改”“改了什么”“效果如何”。很多人以为AI工程的难点在于模型实际做下来你会发现难点在于整个系统的可维护性。模型被替代是很正常的事今天你用GPT-4o明天可能就换成开源模型或自研模型。只有当你的数据管线、评估体系、Prompt模板都独立于模型存在时换模型才是一件低成本的事。这个领域变化太快今天的最佳实践明天可能就过时。但工程化的思维不会过时先定义可衡量的指标再建立可信的评估然后用结构化的方式把不确定性拆解成确定性模块。把这套思维刻在脑子里无论底层模型怎么变你都能快速跟上节奏。最后再分享一个小习惯这也是我最近一直在坚持的每天从线上日志里挑一个badcase放到评测集里然后让技术团队归档。不需要当天修复但必须记录。坚持一个月你会看到你的系统在真实数据上的表现有一个看得见的跃升。这个习惯投入极低回报却远超任何一次模型升级。
阅读完成 · 觉得有帮助？
