1. 用工程师的方式学AI为什么我建议你从零开始搭一套系统做AI工程这两年我最大的感受是真正稀缺的不是会用某个模型的人而是能把模型做成稳定系统的人。市面上的教程大多教你两件事——调一个API接口或者训练一个模型。但真实的AI落地场景里最棘手的问题往往是模型之外的那部分数据怎么管、评估怎么做、效果怎么迭代、延迟怎么压、成本怎么控。这些东西拼在一起才是完整的AI工程能力。“ai-engineering-from-scratch”这个命题本质上是说不依赖现成的平台套件从一个相对原始的起点开始亲手搭建一套AI应用的最小系统。这不是为了造轮子而是为了弄清楚每个环节的痛点和瓶颈到底出在哪里。我见过太多团队用了很贵的模型、很炫的框架最后死在了数据质量或者评估标准这种基本功上。所以这篇文章我想把过去一年从零搭建AI服务的完整经验拆开讲讲整体架构怎么设计、技术选型怎么取舍、数据与评估这两个“隐形支柱”怎么从第一天就打好基础以及那些只有在实操中才会撞上的坑。这篇文章适合三类人一是准备在公司里从零搭建AI能力的团队技术负责人二是已经在调API但总觉得在“盲人摸象”的开发者三是对AI工程感兴趣但不知道从哪开始的转行者。我会用大量实操细节来还原整个过程尽量做到即便你现在只有一台笔记本也可以按着步骤复现一版属于自己的AI系统。2. AI工程的整体设计与思路拆解2.1 先想清楚你的系统边界在哪很多人做AI系统第一个错误就是把“AI”想得太大。实际上一个可交付的AI应用通常只做一件非常具体的事情。比如“从非结构化文档中抽取关键信息”或者“基于内部知识库做问答”这种边界清晰的场景远比“做一个通用智能助手”容易落地十倍。我在动手之前通常会用一张白纸把系统的边界画出来。左边是输入侧数据从哪里来格式是什么实时还是批量。右边是输出侧结果给谁用以什么形式产出是否需要人工审核。中间只有一条主线数据预处理、模型调用、结果后处理。这张图决定了后面所有工程投入的方向。如果你的输入只有几百条结构化数据那根本不需要搭建一套复杂的数据管道如果你的输出要给客户直接生成合同文本那后处理层就要额外加入格式校验和风险提示。边界意识之所以重要是因为它直接决定了你的成本结构。我见过一个团队想做一个“全自动”的文档系统结果花了三周做各种边缘情况处理但其实他们的真实使用场景里90%的文档是同一类格式。定好边界之后我们会把处理策略收敛成两层通用能力层处理主流情况规则兜底层处理关键边缘情况绝不追求“万能”。2.2 为什么“从零搭建”在现在依然是正确的起点现在AI平台和框架多如牛毛LangChain、LlamaIndex、各种低代码平台看起来完全不需要从头造轮子。但我的实际体会是如果你是一个新人或者一个刚开始探索AI工程化的小团队从零搭建反而更靠谱。原因很简单——框架是别人对你需求的抽象而这层抽象在设计时考虑的是通用场景不是你的场景。我最早用LangChain搭过一版原型跑通确实快但进入生产环境后就发现调试链路非常痛苦编排逻辑藏得太深出了问题不好定位而且版本升级频繁很多接口说变就变。后来我花了一周时间用最基础的Python代码重写了主链路核心部分只有不到两百行但每行代码我都清楚它在干什么。从零搭建不等于不用工具而是说你的核心链路要足够透明。我看到很多团队一出问题就加抽象层最后系统复杂到没人敢动。正确的做法是核心链路用最朴素的代码写清楚外围再选择合适的工具加速。这样你的业务逻辑和技术幻觉是完全分离的后续不管是换模型、调参数还是加功能都是在一个可控的范围内做变更而不是在别人封装的黑盒里碰运气。2.3 系统架构的分层逻辑从零搭建AI系统我的习惯是严格分层。每一层只做一件事层与层之间只通过定义好的接口通信。这个设计思路让我在后面加功能、换模型的时候改动非常小。整个架构我分成五层第一层是数据接入层。这层负责把各种格式的数据变成统一的内部表示。不管是PDF、Word、网页还是数据库查询结果进来之后都转成统一的文本块格式带上元信息比如来源、时间、类型。这一层需要处理的问题包括格式解析、乱码清理、敏感信息识别。第二层是数据准备层。这层做的是清洗、切分、结构化和向量化。如果把AI系统比作一个人第一层是眼睛和耳朵第二层就是短期记忆的形成过程。这一层的工作质量直接影响后面检索和生成的效果。很多性能问题根源都出在这里。第三层是认知层。这是模型真正发挥作用的地方。我在这一层设计了一个统一的模型网关不管是调用闭源API还是部署开源模型都通过这个网关进出。网关后面是具体的模型实例可以随时切换和灰度。这层还负责设置温度、截止符这类采样参数以及做输入输出的基础校验。第四层是业务逻辑层。这层不再关心模型相关的细节只关心业务规则。比如“当用户询问公司政策时优先引用最新版本”、“当识别到敏感词时转入人工流程”。这层是系统里的确定性部分用传统代码写成保证所有核心逻辑是可测试的。第五层是服务与交互层。这层对外提供API接口、日志、监控和错误追踪。它决定系统的可运维性。没有这层AI系统就是一堆只能在本地跑的脚本没法成为真正的产品。这套分层的价值我在后续的实际操作中体会更深。有一次模型供应商更新了接口我只是在认知层的网关里改了配置业务层完全不需要动还有一次业务方要求新增一个审核环节我也只是在业务逻辑层加了几行规则模型和数据都没碰。分层让系统迭代的“代价单元”变小了这比任何性能优化都重要。3. 核心细节解析与实操要点3.1 数据是实现“能用”还是“好用”的分水岭做AI项目久了我有一个非常明确的感觉大部分“模型效果不好”的问题根源都不在模型本身而在数据。我复盘过自己好几个项目凡是效果不达预期的几乎都是数据层面出了纰漏——要么是数据量不够要么是标签质量太差要么是切分方式不合理。数据准备里最容易被忽视也最关键的是切分策略。文本切分决定了后续检索的“粒度”太短的块会导致上下文不足太长的块会导致检索噪音。我用了很长时间才找到一个相对靠谱的平衡点——普通技术文档切分成256到512个token左右比较合适具体参考你的模型上下文长度和文本自身结构。如果文本本身有清晰的章节结构最好先按结构切再在大块内部按段落细分。盲目的定长切分最省事但会把很多语义割裂开检索时经常出现“答非所问”的现象。清洗环节里我吃过大亏的是格式残留。从PDF抽取的文本经常带有不规则的换行、编号、页眉页脚如果不清理干净模型会把“第3页 共40页”这种噪音当正文。我现在的做法是准备一套正则规则库先做一轮粗清洗再用小模型做一轮精标注最后人工抽检。这套流程虽然多花点时间但长期回报非常划得来。3.2 向量化不是“插上即用”它有自己的一套学问把文本变成向量是现在做语义检索的基础操作。但向量化和Embedding模型的选择、维度设置还有索引方式的关系非常紧密光“调用一个向量化接口”离可用还差得很远。我的经验是Embedding模型一定要贴合你的内容领域。通用模型处理通用文本没问题但如果是专业领域的内容比如法律条款、医疗文献、机械参数通用向量往往是“认识字但不理解意思”。我在做垂直领域项目时至少会做一轮领域适配测试拿一批典型问题用候选模型分别检索人工看召回结果的相关性排序选最稳的那个而不只是看公开榜单的分数。向量维度也不是越高越好虽然高维度能承载更多语义信息但存储和检索的成本会显著上升。如果你还在用近万维的加持型Embedding而你的数据量不超过百万级实际上大部分场景里512或者768维已经够用。检索方式上暴力遍历在十万级数据量下完全可行用不着迷信专门的向量数据库。3.3 拆解Prompt工程原则比花活重要说到Prompt我觉得现在互联网上把这个词神化了。真正落到工程里Prompt不是灵光一现的魔法句而是一套有结构的模板系统。我在生产环境里维护的Prompt从来不是一行写在代码里的字符串而是一个独立的文本文件带版本号和变更记录。好的Prompt工程需要遵循几个原则。第一是明确角色的边界模型是助手不是决策者它在你的系统里有固定的职能不要让它“自由发挥”。第二是给出示例小小两三个示例往往比一大段描述更管用。第三是把输出格式锁死要求模型输出JSON就往死里写“只输出合法的JSON结构不要任何额外文字”这样下游解析才稳定。第四是对“不知道”要显式声明很多幻觉都源于模型在硬编所以在Prompt里要写清楚“如果信息不足直接回答无法判断不要推理”。我做了一个比较有效的升级是把用户的上下文信息与Prompt模板分开维护。每次请求时动态拼接这样既能追踪模板的版本变化也能清楚地看到某次回答是受到哪些上下文影响的。排查问题时这能省掉大量“我说不清楚是模型变笨了还是输入有问题”的情况。4. 实操过程与核心环节实现4.1 搭建第一步从一条能跑通的主链路开始有了前期的思路沉淀接下来就是动手。我不建议一开始就追求完美架构先做一条“最小可用主链路”一个输入进来经过预处理、向量化、检索、调用模型、返回结果的完整流程。哪怕这一步很简陋也要先跑通因为跑通之后你才能有真实的输入输出再根据问题反馈一步步迭代。我当时的最小主链路用了不到150行Python代码。数据端就两个文件一个是原始文档的目录一个是已经切分好的文本块清单。检索我用的是向量直接暴力比对几万块以内性能完全够。模型端我直接接了一个通用对话模型Prompt用最简单的方式拼接。这版跑通之后我拿着一批代表性测试问题去试把所有明显不对的地方记录下来——记录这一步非常重要后面建评估集就靠这些记录。最小主链路的价值在于给你一个“可讨论的对象”。我发现很多团队卡在起步阶段是因为一直在开会讨论方案没有一个能跑的东西。哪怕是个玩具也能让讨论从“我觉得”变成“你看这里不对”。这就是工程的第一步让事情变得可以被观察。4.2 检索增强生成RAG的完整实现路线现在做知识库问答绕不开RAG也就是检索增强生成。前面说的最小链路启用之后第二件事就是把RAG的各个环节做扎实。我的经验是RAG的效果靠四个环节共同决定任何一个掉了链子都会拖垮整体。先看索引构建。切分策略刚才提过这边再说一个细节切分时要记录每个块的结构上下文。比如某个文本块是“第三章”下面的“3.2节”那么在块里嵌入“章节路径”这样的前缀字段检索时能显著提高命中相关位置的准确率。拥有段落锚点就不怕召回位置跑偏。再看检索环节。我通常还会用“多路召回”的套路一路向量相似度一路BM25关键词再把结果做权重重排。纯粹靠向量有些精确的条款或者型号编码反而找不准BM25这种稀疏检索做互补非常管用。重排环节最好再接一个重排序模型把候选集从几十条压到五六条质量会有肉眼可见的提升。接下来是生成策略。模板里要有清晰的指令部分和引用部分。凡是回答里涉及引用知识点的地方我都要求模型标明来源编号并让下游模块核对来源是否存在。这样做的好处是一旦出现幻觉回溯定位的成本非常低。很多API模型本身不带自动引用能力但通过Prompt约束可以实现大部分效果具体约束方式为只允许使用给定片段中的信息作答并必须附上片段编号。最后是缓存策略。这里未必很多人会想到但到了生产阶段高频重复问题如果每次都走全链路成本压力和心理压力都很大。我在检索之前加了一层“问题级别的Embedding缓存”同样的问题直接命中缓存返回历史答案实测可以降掉将近40%的重复流量。4.3 模型服务的选型与部署按场景上开源不要人云亦云在处理生成模型的服务部署时我的取舍标准很明确如果数据必须留在内部或者每次请求的量非常大导致API成本兜不住就上开源模型自托管如果项目在快速验证期或者需要模型具备很强的通用理解能力闭源API更方便。这两者不矛盾完全可以在同一个系统里共存按路由规则切分。自托管开源模型我调试过的经验是第一批优先看显存和吞吐别一上来就上最大号模型。比如设备上部署7B参数量的模型也就是量化版回答质量已经能和上一代API模型的水平做有效对比而且延迟快很多。真正跑生产之后我发现瓶颈往往在并发控制多个请求同时进来时如果不对推理做队列化处理显存会突然暴涨严重的直接把服务干崩。我的方案是给推理服务套一层“令牌桶”限制并发数宁可让单次请求排队也不要让服务整体雪崩。这里想多说一句模型量化。4bit量化可以大幅降低显存占用但有些模型量化后回答质量会有折扣。我在实际测试中建议拿一组验证集跑一遍比较量化前后的输出差异再决定能不能接受。这种控制变量思路放在工程里永远说得通。4.4 评估与可观测性AI系统的“眼睛”从哪来评估大概是AI工程里最容易被轻视但实际价值最高的一环。没有评估你就不知道改模型、调Prompt到底是变好了还是变坏了。我在项目第2周就建立了评估集——就是前面提到的把所有手动测试发现的问题整理成“问题-期望答案-参考答案”的三元组然后每周往里面加新的边角案例。评估方式我分两层。第一层是自动化评估用一组客观指标来跑回归检索阶段看命中率、看TopK准确率生成阶段用ROUGE这类传统指标加上LLM打分器对答案的相关性、完整性、友好度做综合评分。第二层是人工抽检每周抽几十条新会话按我自己的体验标准打分。这两个层面的指标不是替代关系自动化指标用来抓回归人工抽检用来感知细节。你会发现有些自动化指标很好看的版本实际体验却一般这时就要人工层介入重调。可观测性上我给系统的每一次请求都打上了trace_id涵盖请求参数、检索结果、Prompt快照、模型输出、耗时和Token用量六个维度全部落到日志系统里。这样一旦用户反馈有问题我能一次性还原当时的完整链路而不是靠猜。这些都是老工程习惯但在AI时代很多人因为“模型太魔幻”就放弃了可观测这是大大的误区。5. 常见问题与排查技巧实录5.1 模型“答非所问”的排查路径这是最让人头疼的问题没有之一。我的排查顺序很固定先看Prompt和后处理再看检索质量然后换模型对照最后才怀疑参数。有一次线上反馈说模型经常答非所问我重新看了日志发现问题是检索结果里有大量空块切分时没处理好留下了只有几行字的碎片模型把它们当作有效上下文自然就带偏了。修复方案是切分后过滤掉长度低于阈值的空块问题立刻消除。可以这么说这类问题的根源80%都在“上游脏数据”而不是“模型笨”。另一个高频原因是Prompt里的角色指令被长上下文稀释。模型对初始指令的遵从度会随上下文长度增加而下降这时可以在生成阶段不重发全套指令改用更短的任务描述同时把历史对话尽量缩到必要的几条。实践证明这比盲目调温度参数有效得多。5.2 检索质量差别急着换向量模型检索不到相关信息很多人第一反应是“要不要换个Embedding模型”。但我的经验是先做这几件事再说换一是检查切分粒度是不是块太小或太大二是检查查询改写用户问题太长时直接拿去检索效果很差先压缩成几个关键词或一句话三是检查重排逻辑用轻量重排模型可以对Top20内的结果大幅提效四是检查过滤条件是不是某些元数据过滤误伤了部分正确结果。我做过一次对照实验正式改这些流程细节比单换向量模型带来的整体准确率提升更明显而且几乎没增加成本。检索是系统工程单点优化解决不了全局。可以先给检索结果按相关性字段标分人工看失败案例归类原因制定对应策略很快就会发现大部分问题根本不用动模型。5.3 延迟与成本的双重优化实测数据说话把延迟和成本放在一起说是因为它们的优化手段高度重叠。我的实测数据是加检索缓存单次请求成本平均降四成把模型回答切片长度限制到输出刚够用Token消耗能降两成并发推理队列化之后整机吞吐提升了接近一倍单请求延迟基本不变。在成本优化上还有一招容易忽略模型降级。大部分对话场景70%以上的问题不需要调用最大、最强的模型设一个“两阶段路由”——先让一个小模型判断问题复杂度简单问题直接由小模型生成难问题再转发大模型。这个方法实施后我月度API账单下降了将近一半而用户可感知的质量变化很小因为大部分问题本身就不复杂。延迟优化里最容易忽视的是首Token延迟而不是总的响应时长。如果用户需要等两三秒才看到第一个字体验会非常差。解决办法是开启流式输出边生成边返回同时在Prompt里把“先说结论再解释”写进去模型输出结构也更利于快速给出关键信息。5.4 关于幻觉的工程级克制幻觉问题没法根除但可以做工程级克制。核心思路不是让模型“不胡思乱想”而是让系统在生成前就把可供使用的“事实范围”锁死生成后对关键事实做验证。我在系统里用了三道关卡。生成前Prompt中限定只能使用检索片段中的信息避免模型动用训练时的记忆生成后用一个规则模块检查引用编号是否都存在再让一个轻量校验模型把回答里的关键实体与原文逐一比对最后若检测到不确定的高风险关键词比如“我不确定”“模糊”“大概”就自动把回答标记为“低置信度”引导用户查看引用原文。这三道把关下来我线上服务的幻觉投诉率降到可接受范围内。哪怕这样也不能说高枕无忧。我始终建议在一些关键业务场景保留“确认机制”——AI系统给出建议人类负责最终决策这既是负责任的做法也是工程兜底的最稳手段。6. 实战心得与成长路线建议技术性的内容聊完了最后说几句掏心窝的话。我从零搭建这套AI系统最大的收获不是“会调用模型了”而是建立起一套“工程方法论”。你会慢慢发现AI工程的成功率并不取决于你用了多前沿的模型而是取决于你对数据、评估、反馈循环这些基本功的敬畏程度。模型每年都会换代但数据分层怎么设计、评估集怎么维护、线上日志怎么完善这些能力是可以沉淀下来、长期复用的。在成长路线上我建议所有想深耕AI工程的人花一段时间刻意练习“最小化系统复现”从数据清洗开始到向量检索到模型调用到评估与观察完整地做上两三遍。第一遍照猫画虎第二遍带着问题做第三遍尝试优化某个环节。经过这个过程你对整个系统的理解深度会远超那种直接套平台组件的人。最后再分享一个小技巧把每一次“踩坑”都记录下来形成自己的问题速查手册。不管是切分策略的教训还是并发控制的心得整理得多了你会发现这些都是未来设计新系统时的底层资产。AI领域变化快但工程经验从不贬值——只要你能持续学习、持续动手这条路会越走越宽。 
长河君 · 2026/9/28 14:59:16 · 阅读 1.2k 从零搭建AI系统：架构设计、数据与评估实战要点
1. 用工程师的方式学AI为什么我建议你从零开始搭一套系统做AI工程这两年我最大的感受是真正稀缺的不是会用某个模型的人而是能把模型做成稳定系统的人。市面上的教程大多教你两件事——调一个API接口或者训练一个模型。但真实的AI落地场景里最棘手的问题往往是模型之外的那部分数据怎么管、评估怎么做、效果怎么迭代、延迟怎么压、成本怎么控。这些东西拼在一起才是完整的AI工程能力。“ai-engineering-from-scratch”这个命题本质上是说不依赖现成的平台套件从一个相对原始的起点开始亲手搭建一套AI应用的最小系统。这不是为了造轮子而是为了弄清楚每个环节的痛点和瓶颈到底出在哪里。我见过太多团队用了很贵的模型、很炫的框架最后死在了数据质量或者评估标准这种基本功上。所以这篇文章我想把过去一年从零搭建AI服务的完整经验拆开讲讲整体架构怎么设计、技术选型怎么取舍、数据与评估这两个“隐形支柱”怎么从第一天就打好基础以及那些只有在实操中才会撞上的坑。这篇文章适合三类人一是准备在公司里从零搭建AI能力的团队技术负责人二是已经在调API但总觉得在“盲人摸象”的开发者三是对AI工程感兴趣但不知道从哪开始的转行者。我会用大量实操细节来还原整个过程尽量做到即便你现在只有一台笔记本也可以按着步骤复现一版属于自己的AI系统。2. AI工程的整体设计与思路拆解2.1 先想清楚你的系统边界在哪很多人做AI系统第一个错误就是把“AI”想得太大。实际上一个可交付的AI应用通常只做一件非常具体的事情。比如“从非结构化文档中抽取关键信息”或者“基于内部知识库做问答”这种边界清晰的场景远比“做一个通用智能助手”容易落地十倍。我在动手之前通常会用一张白纸把系统的边界画出来。左边是输入侧数据从哪里来格式是什么实时还是批量。右边是输出侧结果给谁用以什么形式产出是否需要人工审核。中间只有一条主线数据预处理、模型调用、结果后处理。这张图决定了后面所有工程投入的方向。如果你的输入只有几百条结构化数据那根本不需要搭建一套复杂的数据管道如果你的输出要给客户直接生成合同文本那后处理层就要额外加入格式校验和风险提示。边界意识之所以重要是因为它直接决定了你的成本结构。我见过一个团队想做一个“全自动”的文档系统结果花了三周做各种边缘情况处理但其实他们的真实使用场景里90%的文档是同一类格式。定好边界之后我们会把处理策略收敛成两层通用能力层处理主流情况规则兜底层处理关键边缘情况绝不追求“万能”。2.2 为什么“从零搭建”在现在依然是正确的起点现在AI平台和框架多如牛毛LangChain、LlamaIndex、各种低代码平台看起来完全不需要从头造轮子。但我的实际体会是如果你是一个新人或者一个刚开始探索AI工程化的小团队从零搭建反而更靠谱。原因很简单——框架是别人对你需求的抽象而这层抽象在设计时考虑的是通用场景不是你的场景。我最早用LangChain搭过一版原型跑通确实快但进入生产环境后就发现调试链路非常痛苦编排逻辑藏得太深出了问题不好定位而且版本升级频繁很多接口说变就变。后来我花了一周时间用最基础的Python代码重写了主链路核心部分只有不到两百行但每行代码我都清楚它在干什么。从零搭建不等于不用工具而是说你的核心链路要足够透明。我看到很多团队一出问题就加抽象层最后系统复杂到没人敢动。正确的做法是核心链路用最朴素的代码写清楚外围再选择合适的工具加速。这样你的业务逻辑和技术幻觉是完全分离的后续不管是换模型、调参数还是加功能都是在一个可控的范围内做变更而不是在别人封装的黑盒里碰运气。2.3 系统架构的分层逻辑从零搭建AI系统我的习惯是严格分层。每一层只做一件事层与层之间只通过定义好的接口通信。这个设计思路让我在后面加功能、换模型的时候改动非常小。整个架构我分成五层第一层是数据接入层。这层负责把各种格式的数据变成统一的内部表示。不管是PDF、Word、网页还是数据库查询结果进来之后都转成统一的文本块格式带上元信息比如来源、时间、类型。这一层需要处理的问题包括格式解析、乱码清理、敏感信息识别。第二层是数据准备层。这层做的是清洗、切分、结构化和向量化。如果把AI系统比作一个人第一层是眼睛和耳朵第二层就是短期记忆的形成过程。这一层的工作质量直接影响后面检索和生成的效果。很多性能问题根源都出在这里。第三层是认知层。这是模型真正发挥作用的地方。我在这一层设计了一个统一的模型网关不管是调用闭源API还是部署开源模型都通过这个网关进出。网关后面是具体的模型实例可以随时切换和灰度。这层还负责设置温度、截止符这类采样参数以及做输入输出的基础校验。第四层是业务逻辑层。这层不再关心模型相关的细节只关心业务规则。比如“当用户询问公司政策时优先引用最新版本”、“当识别到敏感词时转入人工流程”。这层是系统里的确定性部分用传统代码写成保证所有核心逻辑是可测试的。第五层是服务与交互层。这层对外提供API接口、日志、监控和错误追踪。它决定系统的可运维性。没有这层AI系统就是一堆只能在本地跑的脚本没法成为真正的产品。这套分层的价值我在后续的实际操作中体会更深。有一次模型供应商更新了接口我只是在认知层的网关里改了配置业务层完全不需要动还有一次业务方要求新增一个审核环节我也只是在业务逻辑层加了几行规则模型和数据都没碰。分层让系统迭代的“代价单元”变小了这比任何性能优化都重要。3. 核心细节解析与实操要点3.1 数据是实现“能用”还是“好用”的分水岭做AI项目久了我有一个非常明确的感觉大部分“模型效果不好”的问题根源都不在模型本身而在数据。我复盘过自己好几个项目凡是效果不达预期的几乎都是数据层面出了纰漏——要么是数据量不够要么是标签质量太差要么是切分方式不合理。数据准备里最容易被忽视也最关键的是切分策略。文本切分决定了后续检索的“粒度”太短的块会导致上下文不足太长的块会导致检索噪音。我用了很长时间才找到一个相对靠谱的平衡点——普通技术文档切分成256到512个token左右比较合适具体参考你的模型上下文长度和文本自身结构。如果文本本身有清晰的章节结构最好先按结构切再在大块内部按段落细分。盲目的定长切分最省事但会把很多语义割裂开检索时经常出现“答非所问”的现象。清洗环节里我吃过大亏的是格式残留。从PDF抽取的文本经常带有不规则的换行、编号、页眉页脚如果不清理干净模型会把“第3页 共40页”这种噪音当正文。我现在的做法是准备一套正则规则库先做一轮粗清洗再用小模型做一轮精标注最后人工抽检。这套流程虽然多花点时间但长期回报非常划得来。3.2 向量化不是“插上即用”它有自己的一套学问把文本变成向量是现在做语义检索的基础操作。但向量化和Embedding模型的选择、维度设置还有索引方式的关系非常紧密光“调用一个向量化接口”离可用还差得很远。我的经验是Embedding模型一定要贴合你的内容领域。通用模型处理通用文本没问题但如果是专业领域的内容比如法律条款、医疗文献、机械参数通用向量往往是“认识字但不理解意思”。我在做垂直领域项目时至少会做一轮领域适配测试拿一批典型问题用候选模型分别检索人工看召回结果的相关性排序选最稳的那个而不只是看公开榜单的分数。向量维度也不是越高越好虽然高维度能承载更多语义信息但存储和检索的成本会显著上升。如果你还在用近万维的加持型Embedding而你的数据量不超过百万级实际上大部分场景里512或者768维已经够用。检索方式上暴力遍历在十万级数据量下完全可行用不着迷信专门的向量数据库。3.3 拆解Prompt工程原则比花活重要说到Prompt我觉得现在互联网上把这个词神化了。真正落到工程里Prompt不是灵光一现的魔法句而是一套有结构的模板系统。我在生产环境里维护的Prompt从来不是一行写在代码里的字符串而是一个独立的文本文件带版本号和变更记录。好的Prompt工程需要遵循几个原则。第一是明确角色的边界模型是助手不是决策者它在你的系统里有固定的职能不要让它“自由发挥”。第二是给出示例小小两三个示例往往比一大段描述更管用。第三是把输出格式锁死要求模型输出JSON就往死里写“只输出合法的JSON结构不要任何额外文字”这样下游解析才稳定。第四是对“不知道”要显式声明很多幻觉都源于模型在硬编所以在Prompt里要写清楚“如果信息不足直接回答无法判断不要推理”。我做了一个比较有效的升级是把用户的上下文信息与Prompt模板分开维护。每次请求时动态拼接这样既能追踪模板的版本变化也能清楚地看到某次回答是受到哪些上下文影响的。排查问题时这能省掉大量“我说不清楚是模型变笨了还是输入有问题”的情况。4. 实操过程与核心环节实现4.1 搭建第一步从一条能跑通的主链路开始有了前期的思路沉淀接下来就是动手。我不建议一开始就追求完美架构先做一条“最小可用主链路”一个输入进来经过预处理、向量化、检索、调用模型、返回结果的完整流程。哪怕这一步很简陋也要先跑通因为跑通之后你才能有真实的输入输出再根据问题反馈一步步迭代。我当时的最小主链路用了不到150行Python代码。数据端就两个文件一个是原始文档的目录一个是已经切分好的文本块清单。检索我用的是向量直接暴力比对几万块以内性能完全够。模型端我直接接了一个通用对话模型Prompt用最简单的方式拼接。这版跑通之后我拿着一批代表性测试问题去试把所有明显不对的地方记录下来——记录这一步非常重要后面建评估集就靠这些记录。最小主链路的价值在于给你一个“可讨论的对象”。我发现很多团队卡在起步阶段是因为一直在开会讨论方案没有一个能跑的东西。哪怕是个玩具也能让讨论从“我觉得”变成“你看这里不对”。这就是工程的第一步让事情变得可以被观察。4.2 检索增强生成RAG的完整实现路线现在做知识库问答绕不开RAG也就是检索增强生成。前面说的最小链路启用之后第二件事就是把RAG的各个环节做扎实。我的经验是RAG的效果靠四个环节共同决定任何一个掉了链子都会拖垮整体。先看索引构建。切分策略刚才提过这边再说一个细节切分时要记录每个块的结构上下文。比如某个文本块是“第三章”下面的“3.2节”那么在块里嵌入“章节路径”这样的前缀字段检索时能显著提高命中相关位置的准确率。拥有段落锚点就不怕召回位置跑偏。再看检索环节。我通常还会用“多路召回”的套路一路向量相似度一路BM25关键词再把结果做权重重排。纯粹靠向量有些精确的条款或者型号编码反而找不准BM25这种稀疏检索做互补非常管用。重排环节最好再接一个重排序模型把候选集从几十条压到五六条质量会有肉眼可见的提升。接下来是生成策略。模板里要有清晰的指令部分和引用部分。凡是回答里涉及引用知识点的地方我都要求模型标明来源编号并让下游模块核对来源是否存在。这样做的好处是一旦出现幻觉回溯定位的成本非常低。很多API模型本身不带自动引用能力但通过Prompt约束可以实现大部分效果具体约束方式为只允许使用给定片段中的信息作答并必须附上片段编号。最后是缓存策略。这里未必很多人会想到但到了生产阶段高频重复问题如果每次都走全链路成本压力和心理压力都很大。我在检索之前加了一层“问题级别的Embedding缓存”同样的问题直接命中缓存返回历史答案实测可以降掉将近40%的重复流量。4.3 模型服务的选型与部署按场景上开源不要人云亦云在处理生成模型的服务部署时我的取舍标准很明确如果数据必须留在内部或者每次请求的量非常大导致API成本兜不住就上开源模型自托管如果项目在快速验证期或者需要模型具备很强的通用理解能力闭源API更方便。这两者不矛盾完全可以在同一个系统里共存按路由规则切分。自托管开源模型我调试过的经验是第一批优先看显存和吞吐别一上来就上最大号模型。比如设备上部署7B参数量的模型也就是量化版回答质量已经能和上一代API模型的水平做有效对比而且延迟快很多。真正跑生产之后我发现瓶颈往往在并发控制多个请求同时进来时如果不对推理做队列化处理显存会突然暴涨严重的直接把服务干崩。我的方案是给推理服务套一层“令牌桶”限制并发数宁可让单次请求排队也不要让服务整体雪崩。这里想多说一句模型量化。4bit量化可以大幅降低显存占用但有些模型量化后回答质量会有折扣。我在实际测试中建议拿一组验证集跑一遍比较量化前后的输出差异再决定能不能接受。这种控制变量思路放在工程里永远说得通。4.4 评估与可观测性AI系统的“眼睛”从哪来评估大概是AI工程里最容易被轻视但实际价值最高的一环。没有评估你就不知道改模型、调Prompt到底是变好了还是变坏了。我在项目第2周就建立了评估集——就是前面提到的把所有手动测试发现的问题整理成“问题-期望答案-参考答案”的三元组然后每周往里面加新的边角案例。评估方式我分两层。第一层是自动化评估用一组客观指标来跑回归检索阶段看命中率、看TopK准确率生成阶段用ROUGE这类传统指标加上LLM打分器对答案的相关性、完整性、友好度做综合评分。第二层是人工抽检每周抽几十条新会话按我自己的体验标准打分。这两个层面的指标不是替代关系自动化指标用来抓回归人工抽检用来感知细节。你会发现有些自动化指标很好看的版本实际体验却一般这时就要人工层介入重调。可观测性上我给系统的每一次请求都打上了trace_id涵盖请求参数、检索结果、Prompt快照、模型输出、耗时和Token用量六个维度全部落到日志系统里。这样一旦用户反馈有问题我能一次性还原当时的完整链路而不是靠猜。这些都是老工程习惯但在AI时代很多人因为“模型太魔幻”就放弃了可观测这是大大的误区。5. 常见问题与排查技巧实录5.1 模型“答非所问”的排查路径这是最让人头疼的问题没有之一。我的排查顺序很固定先看Prompt和后处理再看检索质量然后换模型对照最后才怀疑参数。有一次线上反馈说模型经常答非所问我重新看了日志发现问题是检索结果里有大量空块切分时没处理好留下了只有几行字的碎片模型把它们当作有效上下文自然就带偏了。修复方案是切分后过滤掉长度低于阈值的空块问题立刻消除。可以这么说这类问题的根源80%都在“上游脏数据”而不是“模型笨”。另一个高频原因是Prompt里的角色指令被长上下文稀释。模型对初始指令的遵从度会随上下文长度增加而下降这时可以在生成阶段不重发全套指令改用更短的任务描述同时把历史对话尽量缩到必要的几条。实践证明这比盲目调温度参数有效得多。5.2 检索质量差别急着换向量模型检索不到相关信息很多人第一反应是“要不要换个Embedding模型”。但我的经验是先做这几件事再说换一是检查切分粒度是不是块太小或太大二是检查查询改写用户问题太长时直接拿去检索效果很差先压缩成几个关键词或一句话三是检查重排逻辑用轻量重排模型可以对Top20内的结果大幅提效四是检查过滤条件是不是某些元数据过滤误伤了部分正确结果。我做过一次对照实验正式改这些流程细节比单换向量模型带来的整体准确率提升更明显而且几乎没增加成本。检索是系统工程单点优化解决不了全局。可以先给检索结果按相关性字段标分人工看失败案例归类原因制定对应策略很快就会发现大部分问题根本不用动模型。5.3 延迟与成本的双重优化实测数据说话把延迟和成本放在一起说是因为它们的优化手段高度重叠。我的实测数据是加检索缓存单次请求成本平均降四成把模型回答切片长度限制到输出刚够用Token消耗能降两成并发推理队列化之后整机吞吐提升了接近一倍单请求延迟基本不变。在成本优化上还有一招容易忽略模型降级。大部分对话场景70%以上的问题不需要调用最大、最强的模型设一个“两阶段路由”——先让一个小模型判断问题复杂度简单问题直接由小模型生成难问题再转发大模型。这个方法实施后我月度API账单下降了将近一半而用户可感知的质量变化很小因为大部分问题本身就不复杂。延迟优化里最容易忽视的是首Token延迟而不是总的响应时长。如果用户需要等两三秒才看到第一个字体验会非常差。解决办法是开启流式输出边生成边返回同时在Prompt里把“先说结论再解释”写进去模型输出结构也更利于快速给出关键信息。5.4 关于幻觉的工程级克制幻觉问题没法根除但可以做工程级克制。核心思路不是让模型“不胡思乱想”而是让系统在生成前就把可供使用的“事实范围”锁死生成后对关键事实做验证。我在系统里用了三道关卡。生成前Prompt中限定只能使用检索片段中的信息避免模型动用训练时的记忆生成后用一个规则模块检查引用编号是否都存在再让一个轻量校验模型把回答里的关键实体与原文逐一比对最后若检测到不确定的高风险关键词比如“我不确定”“模糊”“大概”就自动把回答标记为“低置信度”引导用户查看引用原文。这三道把关下来我线上服务的幻觉投诉率降到可接受范围内。哪怕这样也不能说高枕无忧。我始终建议在一些关键业务场景保留“确认机制”——AI系统给出建议人类负责最终决策这既是负责任的做法也是工程兜底的最稳手段。6. 实战心得与成长路线建议技术性的内容聊完了最后说几句掏心窝的话。我从零搭建这套AI系统最大的收获不是“会调用模型了”而是建立起一套“工程方法论”。你会慢慢发现AI工程的成功率并不取决于你用了多前沿的模型而是取决于你对数据、评估、反馈循环这些基本功的敬畏程度。模型每年都会换代但数据分层怎么设计、评估集怎么维护、线上日志怎么完善这些能力是可以沉淀下来、长期复用的。在成长路线上我建议所有想深耕AI工程的人花一段时间刻意练习“最小化系统复现”从数据清洗开始到向量检索到模型调用到评估与观察完整地做上两三遍。第一遍照猫画虎第二遍带着问题做第三遍尝试优化某个环节。经过这个过程你对整个系统的理解深度会远超那种直接套平台组件的人。最后再分享一个小技巧把每一次“踩坑”都记录下来形成自己的问题速查手册。不管是切分策略的教训还是并发控制的心得整理得多了你会发现这些都是未来设计新系统时的底层资产。AI领域变化快但工程经验从不贬值——只要你能持续学习、持续动手这条路会越走越宽。