如果你正在“想搞AI工程”和“不知道从哪下手”之间反复横跳这篇东西大概能当一份参考地图用。去年我干过一件有点蠢的事花三个月把Transformer的前向传播和反向传播手推得滚瓜烂熟结果接手第一个真实AI项目时被一句特别简单的提问问住了——“这个模型答错了你能定位到它在生产环境里为什么答错吗”我当场语塞。也是从那一刻起我才真正想明白AI工程和算法研究完全是两条路。所谓from scratch不是从线性代数开始重造所有公式而是把一个AI系统从零到能上线、能维护、能迭代的每一环都亲手摸一遍。这篇内容就是按这个思路来的写给那些和我一样想把AI真正做成产品、而不是只停在一个跑通的Demo上的人。1. from scratch到底意味着什么先拆掉重造轮子的执念1.1 算法研究和工程落地之间的真正分水岭刚接触AI时我特别容易被“原理派”带节奏觉得不懂反向传播推导就不配写AI代码。后来在真实项目里被毒打了几次才明白研究者的任务是把模型能力推向极限而工程师的任务是在约束条件内把已有能力稳定复现出来。这两件事需要的技能集有很大差别。工程视角关心的是模型在什么输入下会失效、一个请求的平均延迟是多少、显存够不够、出错了能不能回溯、换了个模型版本后行为有没有变化、用户的真实反馈怎么回流到系统里。这些东西没有一条写在论文里也没有一条能靠推公式推出来只能在真实系统里摸出来。所以当我重新梳理“从零学AI工程”时给自己定下的第一个原则是不要再抱着“必须从数学原理一路推到最新论文”的完美主义。那个路径不是不对而是对大多数人来说太长长到还没碰到工程问题就先放弃了。1.2 我的地基验收清单不追求满分但求够用我不反对打基础但基础要打在该打的地方。自己复盘下来真正“兜底”用的基础能力其实就四块Python工程能力不是会写for循环和import而是会写类型注解、会管理虚拟环境、会写pytest用例、能看懂依赖树、能处理异常和日志。这是整个AI工程的基座绕不过去。数据处理能力SQL要熟练pandas或polars至少精通一个能处理脏数据、缺值、格式不统一、单位不一致这类日常糟心事。真实数据集里从没有干净得像Kaggle一样的这个觉悟越早越好。数学的“够用”标准线性代数的矩阵乘法、维度变化要熟概率统计里的分布、均值方差、贝叶斯直觉要顺微积分知道链式法则和高阶导是干嘛的就行。不需要会证明定理但模型结构图和loss曲线要能读懂。模型机制的直觉能说出Transformer里attention在干什么知道embedding之后向量进了什么空间理解softmax输出为什么能当概率看。这种“直觉”比记住参数量更有用。1.3 给自己定的一条工程验收线光列清单没有用得有一个能自我检验的标准。我当时的验收线是给我一份不太干净的CSV和一批杂乱的文档我能独立做出一个带检索和问答能力的系统并且能说清楚每一个环节为什么这样做、出问题时怎么排查。这条线听起来不高但真能做到就已经比很多只能跑通Notebook的人强很多了。2. 模型生命周期里的工程重头戏数据和评估才是主要矛盾2.1 数据准备是又脏又关键的第一步大模型时代有一个错觉数据工作被“自动”了。实际上恰恰相反数据是整个链路里最不自动的环节也是最决定上限的环节。模型再强喂进去的是垃圾出来的就是精致的垃圾。我做过的第一个实战项目就栽在这里。当时拿到一份业务导出的原始数据包含用户反馈文本、日志记录、历史工单。表面上看字段名都挺清楚实际一打开日期格式有三种、同一个用户出现多次但ID不一致、文本里有大量HTML残留和重复拼接、空值用五种不同符号表示。当时想直接用LangChain把整批文档灌进向量库跑出来的检索结果稀烂后来才发现是数据清洗根本没做到位。经过那次之后我给自己定了一套数据准备的固定动作先做数据探查不急着清洗。统计字段完整性、值分布、样本总量把“不知道数据长什么样”的风险前置。清洗规则要可复现不能手动改完就没记录。所有清洗逻辑写成脚本保证重跑一遍结果一致。清洗后做抽样检查人工看几百条确认没有把有效信息洗掉。敏感信息处理脱敏、加密、脱标识从源头管住合规风险。2.2 评估体系没有标尺就谈不上优化程序出Bug是确定的模型出错是概率性的。这种天然差异让很多工程师极不适应——你不能说“它修好了”只能说“它好多了但还有5%的边角情况会翻车”。所以必须先建评估标尺再谈优化。以我做过的问答系统为例评估维度不能只有“答得对不对”这一个指标我把评估拆成了四层准确性命中答案核心信息是否与参考答案一致可以用自动化方式比对关键词和语义相似度。引用可溯源性模型给出的答案能不能关联到原始文档这是减少幻觉的关键防线。拒答能力遇到知识范围外的问题模型能不能明确说“不知道”而不是硬编一个答案。稳定性同一个问题在表述略有变化时答案方向是否一致会不会换个问法就翻脸。每一层都要留一部分bad case做人工复盘。模型优化不是看平均指标而是看那些“极端但真实”的样本有没有改善。2.3 没有数据怎么办从规则和人工开始很多人一上来就想训练模型但手里连一百条有效样本都没有。我的建议是先用规则和人工把流程跑起来再逐步用模型替代。手工阶段产出的记录本身就是第一批高质量标注数据。这个过程慢但每一步都有产出而且能逼你理解业务逻辑。等到积累了几百条真实样本就可以开始做半自动化标注先用模型给候选答案由人工确认修改再把这些确认过的答案回流成训练数据。数据就是这么滚起来的别指望一步到位。3. 我的推进路线API调用、RAG、微调、自训练一步都没跳3.1 为什么先跑通业务逻辑而不是一开始就自己训我当时犯过一个想当然的错误觉得“用现成API”没什么技术含量不如一上来就微调开源模型。结果训练还没搞定业务逻辑先卡住了——用户问的问题有歧义、多轮对话里指代消解困难、答案格式不满足下游系统要求。这些问题跟用什么模型根本无关是产品逻辑层面的问题。正确的顺序应该是先借助成熟的API服务把完整的业务链路跑通。这一步的目的不是“偷懒”而是隔离变量冲突。链路通畅之后你再知道瓶颈到底在模型能力、检索质量还是交互设计上。没跑通完整链路就去微调模型相当于房子里水管都没铺好先把最贵的浴室瓷砖贴了。API本身也有取舍逻辑。选型时要考虑接口的稳定性和延迟、计费方式、数据隐私约束、可替换性。至少保证代码层面做了抽象将来换个模型服务商不需要重写整个系统。3.2 RAG是把知识接进模型的最短路径当业务逻辑跑通你会发现另一个问题模型再强它也不知道你私域里的知识。这时候摆在面前的有两条路微调让模型“记住”新知识或者用RAG让模型“检索”新知识。我的建议是大多数场景先上RAG因为它胜在可控、可更新、可溯源。微调相当于把知识写进模型的参数里改起来慢、验证难、错了还不好定位RAG相当于给模型配了一个随时可换的参考资料库每句话都能回溯到原始文档业务侧也更容易接受。当然RAG不是没有成本你要做文档切分、向量化、检索相关性优化还要处理“检索结果质量不高导致答案质量下降”的问题。但这些都是工程问题比模型参数问题可控得多。3.3 微调和自训练的适用边界RAG跑顺之后微调的意义才能真正显现。我理解的微调适用场景有三类风格与格式控制希望模型以特定口吻、固定模板输出RAG给不了这种稳定约束。指令遵循能力增强需要模型丝滑地理解一套私有指令体系靠提示词写太多容易不稳定。精简化用一个小模型微调做到接近大模型的效果换推理成本和延迟的下降。至于从零预训练普通业务场景基本不用考虑。那是真正的基础设施玩家做的事需要的数据量和算力都不是业务团队能随手覆盖的。4. 亲手搭一个最小知识库问答系统从切分到检索的完整动作4.1 选型和环境准备先在本地把小系统跑通很多教程一上来就部署大模型其实本地跑一个开源小模型完全够学习用。显存不够就选量化版或者干脆先把流程搭在纯CPU推理上——慢一点没关系先把链路打通最重要。技术栈方面我把自己常用的组合列出来供参考框架层用轻量级工作流库把组件串起来自己实现的关键模块保持独立方便替换和调试。向量存储先选一个支持本地运行的开源向量库几百条文档规模起步避免一上来就上分布式。模型选择开源的中文底座模型参数规模根据你手里的卡来定优先选有量化版本可用的。开发工具一个支持超参数调节和日志的前端界面方便交互测试。4.2 五段链路切分、向量化、检索、生成、回传我搭最小系统时把流程严格拆成五段每一段单独验证文档加载与解析把PDF、Word、Markdown、网页全部转成纯文本。这个环节的坑比想象中多PDF里图片扫描件、表格错位、页眉页脚混入正文都是常见情况。文本切分把长文档切成小块。这是RAG里最影响效果但最容易被忽略的环节。切多大、有没有重叠、按什么边界切都直接影响检索质量。我当时用“章节标题识别段落边界优先固定大小兜底”的组合策略比纯按字符切好了不少。向量化把切好的文本块转成向量。这个环节的选型核心是看模型对中文的支持程度和向量维度是否匹配存储库的要求。检索用户问题转向量后在库里做相似度查找取top-k结果。注意不要只依赖向量相似度关键词匹配和重排模型都能显著提升召回质量。生成把检索到的文本块作为参考材料连同用户问题一起交给大模型生成答案。提示词要明确告诉模型“只依据给到的材料回答材料中没有就说不知道”这是控制幻觉的第一道防线。每一段都要单独写一个测试脚本来验证输出不要等串起来再整体调否则出了错都不知道哪一环坏了。4.3 这一路最容易翻车的三个点切分不当导致语义断裂。我最初按固定500字切结果很多段落在一个句子中间被截断检索到的文本块连人看都读不通更别说让模型生成好答案。后来改成优先按标题和段落边界切固定长度只作为兜底情况才好转。检索结果top-1定生死。系统默认只取最相似的一个文本块结果很多问题因为检索时关键词偏移拿到了一个不相关的块答案自然错。后来改成取top-3到top-5让模型在多个候选里自行组织准确率明显上升。上下文拼接过长导致成本飙升。一开始贪心把尽量多的检索结果全塞进上下文结果token消耗直线上升延迟变高生成质量反而下降。后来加了“按相关性截断”的逻辑只保留超过阈值的文本块成本和效果同时改善。5. demo能跑和系统可用之间隔着评估、测试、成本与监控5.1 从离线指标到线上效果的闭环在Demo阶段拿几个例子出来“看起来不错”就能交差但真实系统不能这么干。必须把离线评估和线上表现连成一个闭环离线跑出指标 → 上线观察效果 → 收集bad case → 回流到数据和提示词迭代 → 再跑离线评估。离线评估我用的是固定评测集规模不大但覆盖了主要业务场景和典型边角情况每次改动都拿它回归一遍。线上则要看真实流量下的表现比如答案被采纳的比例、用户是否追问、检索命中率变化等。两边口径要尽量对齐不然离线涨分、线上翻车的情况会反复出现。5.2 回归测试用例集是刚需做传统软件时我们写过单元测试和回归测试AI系统同样需要。我用的是提示词回归用例集把一百多个有代表性的输入固化下来每次修改提示词、调整检索策略、更换模型后全量跑一遍对比输出是否回退。这个用例集的价值举两个真实的例子就懂了某次调优为了提升长文本处理效果改动了提示词模板结果长文本确实变好了但大量短问题开始出现不必要的展开回答靠回归用例集一下子抓了出来。更换向量模型后整体检索相似度都变了人肉看了几个例子感觉没问题回归用例集跑出来发现两类专业术语的检索质量明显下降及时做了回滚。没有回归集AI应用就像没有安全网走钢丝。5.3 成本与延迟压下来才算真的能用模型能力再强上线是要花钱和时间的。我在成本控制上常用的几个招缓存命中优先高频问题复用历史答案省下重复的计算开销。模型路由简单问题走小模型复杂问题才上大模型整体成本能降一大截体验上用户感知不明显。量化与精简把大模型量化到低精度评估指标基本持平延迟却能降不少。上下文瘦身严格控制塞给模型的内容量既省钱又降低延迟。延迟方面还要注意分位数而不是只看平均。线上系统的真实体验主要由P95甚至P99决定某个请求突然变慢可能比平均延迟高出一倍还多。我排查后发现很多延迟尖峰来自检索环节的一次串行调用改成并行后P95立刻明显下降。6. 三笔学费上下文窗口、显存幻觉与版本漂移6.1 上下文窗口不是加长就万事大吉我一度以为上下文窗口越长越好后来发现在超长上下文下模型对中间部分内容的关注度会下降这在检索增强场景里尤其要命。你要喂给模型的文本块太多太杂反而会让它“看花眼”。有一段时间我们遇到一个问题检索回来的内容明明是对的但生成的答案却漏掉了关键信息。后来发现是因为上下文里塞了五六个文本块其中包含大量和问题无关的背景描述模型被无关信息干扰了。解决办法就是建立相关性过滤把“可能有用”变成“确定有用才算数”不要迷信上下文越长越聪明。6.2 显存规划别靠“看起来能跑”自建模型推理服务时最坑的一种“错觉”是某个模型在本地跑通了就觉得显存没问题。真实场景差异巨大上线后并发请求同一时间到达峰值显存和单条推理完全不同。另外即便同一个模型不同输入长度对应的显存占用也差别巨大长文本请求会把显存拉到另一个量级。我的教训是上线前一定要做压测和显存画像。至少要知道单请求最大显存占用、并发N路时的峰值、输入长度和显存的关系曲线。不然服务一接真实流量就OOM重启脚本写一百遍也补不回来。压测工具不需要很复杂几十行Python脚本模拟并发即可重点是把画像数据记录下来以后换模型也有参考依据。6.3 版本漂移锁死你的依赖和模型模型和依赖库的版本漂移是我在工程化过程中最头疼的隐性坑。细节非常反直觉你觉得代码没动过结果系统行为变了。背后的原因往往是中间换了依赖库的小版本或者GPU驱动更新后推理结果有了细微差异甚至同一个模型权重文件被重新加载时精度截断逻辑不同。后来我养成的习惯是“锁版本锁一切”依赖锁文件必须提交进仓库模型权重记录下载地址、SHA256摘要、量化格式、加载参数每次模型更新严格走版本号管理线上稳定版本和实验版本分开部署关键测试环境用固定镜像禁止“临时升级依赖”这种操作。这套流程看起来偏传统软件工程但恰恰是AI项目从实验品走向稳定产品的关键一步。越是“研究味”重的项目越要主动往工程规范上靠否则后期维护成本会让你很痛苦。最后说一个我一直在坚持的小习惯每隔几周我会故意回到“最笨的手工状态”——不用任何框架用纯代码和基础库把最小链路重新走一遍。这个习惯帮我挡掉了不少“工具幻觉”。from scratch这条路走下来的终点不是你会用多少个框架而是对系统里每一层都心里有数。这个数有了后面学什么新东西都会快很多。
AI工程实践指南：数据、评估与RAG全流程落地
如果你正在“想搞AI工程”和“不知道从哪下手”之间反复横跳这篇东西大概能当一份参考地图用。去年我干过一件有点蠢的事花三个月把Transformer的前向传播和反向传播手推得滚瓜烂熟结果接手第一个真实AI项目时被一句特别简单的提问问住了——“这个模型答错了你能定位到它在生产环境里为什么答错吗”我当场语塞。也是从那一刻起我才真正想明白AI工程和算法研究完全是两条路。所谓from scratch不是从线性代数开始重造所有公式而是把一个AI系统从零到能上线、能维护、能迭代的每一环都亲手摸一遍。这篇内容就是按这个思路来的写给那些和我一样想把AI真正做成产品、而不是只停在一个跑通的Demo上的人。1. from scratch到底意味着什么先拆掉重造轮子的执念1.1 算法研究和工程落地之间的真正分水岭刚接触AI时我特别容易被“原理派”带节奏觉得不懂反向传播推导就不配写AI代码。后来在真实项目里被毒打了几次才明白研究者的任务是把模型能力推向极限而工程师的任务是在约束条件内把已有能力稳定复现出来。这两件事需要的技能集有很大差别。工程视角关心的是模型在什么输入下会失效、一个请求的平均延迟是多少、显存够不够、出错了能不能回溯、换了个模型版本后行为有没有变化、用户的真实反馈怎么回流到系统里。这些东西没有一条写在论文里也没有一条能靠推公式推出来只能在真实系统里摸出来。所以当我重新梳理“从零学AI工程”时给自己定下的第一个原则是不要再抱着“必须从数学原理一路推到最新论文”的完美主义。那个路径不是不对而是对大多数人来说太长长到还没碰到工程问题就先放弃了。1.2 我的地基验收清单不追求满分但求够用我不反对打基础但基础要打在该打的地方。自己复盘下来真正“兜底”用的基础能力其实就四块Python工程能力不是会写for循环和import而是会写类型注解、会管理虚拟环境、会写pytest用例、能看懂依赖树、能处理异常和日志。这是整个AI工程的基座绕不过去。数据处理能力SQL要熟练pandas或polars至少精通一个能处理脏数据、缺值、格式不统一、单位不一致这类日常糟心事。真实数据集里从没有干净得像Kaggle一样的这个觉悟越早越好。数学的“够用”标准线性代数的矩阵乘法、维度变化要熟概率统计里的分布、均值方差、贝叶斯直觉要顺微积分知道链式法则和高阶导是干嘛的就行。不需要会证明定理但模型结构图和loss曲线要能读懂。模型机制的直觉能说出Transformer里attention在干什么知道embedding之后向量进了什么空间理解softmax输出为什么能当概率看。这种“直觉”比记住参数量更有用。1.3 给自己定的一条工程验收线光列清单没有用得有一个能自我检验的标准。我当时的验收线是给我一份不太干净的CSV和一批杂乱的文档我能独立做出一个带检索和问答能力的系统并且能说清楚每一个环节为什么这样做、出问题时怎么排查。这条线听起来不高但真能做到就已经比很多只能跑通Notebook的人强很多了。2. 模型生命周期里的工程重头戏数据和评估才是主要矛盾2.1 数据准备是又脏又关键的第一步大模型时代有一个错觉数据工作被“自动”了。实际上恰恰相反数据是整个链路里最不自动的环节也是最决定上限的环节。模型再强喂进去的是垃圾出来的就是精致的垃圾。我做过的第一个实战项目就栽在这里。当时拿到一份业务导出的原始数据包含用户反馈文本、日志记录、历史工单。表面上看字段名都挺清楚实际一打开日期格式有三种、同一个用户出现多次但ID不一致、文本里有大量HTML残留和重复拼接、空值用五种不同符号表示。当时想直接用LangChain把整批文档灌进向量库跑出来的检索结果稀烂后来才发现是数据清洗根本没做到位。经过那次之后我给自己定了一套数据准备的固定动作先做数据探查不急着清洗。统计字段完整性、值分布、样本总量把“不知道数据长什么样”的风险前置。清洗规则要可复现不能手动改完就没记录。所有清洗逻辑写成脚本保证重跑一遍结果一致。清洗后做抽样检查人工看几百条确认没有把有效信息洗掉。敏感信息处理脱敏、加密、脱标识从源头管住合规风险。2.2 评估体系没有标尺就谈不上优化程序出Bug是确定的模型出错是概率性的。这种天然差异让很多工程师极不适应——你不能说“它修好了”只能说“它好多了但还有5%的边角情况会翻车”。所以必须先建评估标尺再谈优化。以我做过的问答系统为例评估维度不能只有“答得对不对”这一个指标我把评估拆成了四层准确性命中答案核心信息是否与参考答案一致可以用自动化方式比对关键词和语义相似度。引用可溯源性模型给出的答案能不能关联到原始文档这是减少幻觉的关键防线。拒答能力遇到知识范围外的问题模型能不能明确说“不知道”而不是硬编一个答案。稳定性同一个问题在表述略有变化时答案方向是否一致会不会换个问法就翻脸。每一层都要留一部分bad case做人工复盘。模型优化不是看平均指标而是看那些“极端但真实”的样本有没有改善。2.3 没有数据怎么办从规则和人工开始很多人一上来就想训练模型但手里连一百条有效样本都没有。我的建议是先用规则和人工把流程跑起来再逐步用模型替代。手工阶段产出的记录本身就是第一批高质量标注数据。这个过程慢但每一步都有产出而且能逼你理解业务逻辑。等到积累了几百条真实样本就可以开始做半自动化标注先用模型给候选答案由人工确认修改再把这些确认过的答案回流成训练数据。数据就是这么滚起来的别指望一步到位。3. 我的推进路线API调用、RAG、微调、自训练一步都没跳3.1 为什么先跑通业务逻辑而不是一开始就自己训我当时犯过一个想当然的错误觉得“用现成API”没什么技术含量不如一上来就微调开源模型。结果训练还没搞定业务逻辑先卡住了——用户问的问题有歧义、多轮对话里指代消解困难、答案格式不满足下游系统要求。这些问题跟用什么模型根本无关是产品逻辑层面的问题。正确的顺序应该是先借助成熟的API服务把完整的业务链路跑通。这一步的目的不是“偷懒”而是隔离变量冲突。链路通畅之后你再知道瓶颈到底在模型能力、检索质量还是交互设计上。没跑通完整链路就去微调模型相当于房子里水管都没铺好先把最贵的浴室瓷砖贴了。API本身也有取舍逻辑。选型时要考虑接口的稳定性和延迟、计费方式、数据隐私约束、可替换性。至少保证代码层面做了抽象将来换个模型服务商不需要重写整个系统。3.2 RAG是把知识接进模型的最短路径当业务逻辑跑通你会发现另一个问题模型再强它也不知道你私域里的知识。这时候摆在面前的有两条路微调让模型“记住”新知识或者用RAG让模型“检索”新知识。我的建议是大多数场景先上RAG因为它胜在可控、可更新、可溯源。微调相当于把知识写进模型的参数里改起来慢、验证难、错了还不好定位RAG相当于给模型配了一个随时可换的参考资料库每句话都能回溯到原始文档业务侧也更容易接受。当然RAG不是没有成本你要做文档切分、向量化、检索相关性优化还要处理“检索结果质量不高导致答案质量下降”的问题。但这些都是工程问题比模型参数问题可控得多。3.3 微调和自训练的适用边界RAG跑顺之后微调的意义才能真正显现。我理解的微调适用场景有三类风格与格式控制希望模型以特定口吻、固定模板输出RAG给不了这种稳定约束。指令遵循能力增强需要模型丝滑地理解一套私有指令体系靠提示词写太多容易不稳定。精简化用一个小模型微调做到接近大模型的效果换推理成本和延迟的下降。至于从零预训练普通业务场景基本不用考虑。那是真正的基础设施玩家做的事需要的数据量和算力都不是业务团队能随手覆盖的。4. 亲手搭一个最小知识库问答系统从切分到检索的完整动作4.1 选型和环境准备先在本地把小系统跑通很多教程一上来就部署大模型其实本地跑一个开源小模型完全够学习用。显存不够就选量化版或者干脆先把流程搭在纯CPU推理上——慢一点没关系先把链路打通最重要。技术栈方面我把自己常用的组合列出来供参考框架层用轻量级工作流库把组件串起来自己实现的关键模块保持独立方便替换和调试。向量存储先选一个支持本地运行的开源向量库几百条文档规模起步避免一上来就上分布式。模型选择开源的中文底座模型参数规模根据你手里的卡来定优先选有量化版本可用的。开发工具一个支持超参数调节和日志的前端界面方便交互测试。4.2 五段链路切分、向量化、检索、生成、回传我搭最小系统时把流程严格拆成五段每一段单独验证文档加载与解析把PDF、Word、Markdown、网页全部转成纯文本。这个环节的坑比想象中多PDF里图片扫描件、表格错位、页眉页脚混入正文都是常见情况。文本切分把长文档切成小块。这是RAG里最影响效果但最容易被忽略的环节。切多大、有没有重叠、按什么边界切都直接影响检索质量。我当时用“章节标题识别段落边界优先固定大小兜底”的组合策略比纯按字符切好了不少。向量化把切好的文本块转成向量。这个环节的选型核心是看模型对中文的支持程度和向量维度是否匹配存储库的要求。检索用户问题转向量后在库里做相似度查找取top-k结果。注意不要只依赖向量相似度关键词匹配和重排模型都能显著提升召回质量。生成把检索到的文本块作为参考材料连同用户问题一起交给大模型生成答案。提示词要明确告诉模型“只依据给到的材料回答材料中没有就说不知道”这是控制幻觉的第一道防线。每一段都要单独写一个测试脚本来验证输出不要等串起来再整体调否则出了错都不知道哪一环坏了。4.3 这一路最容易翻车的三个点切分不当导致语义断裂。我最初按固定500字切结果很多段落在一个句子中间被截断检索到的文本块连人看都读不通更别说让模型生成好答案。后来改成优先按标题和段落边界切固定长度只作为兜底情况才好转。检索结果top-1定生死。系统默认只取最相似的一个文本块结果很多问题因为检索时关键词偏移拿到了一个不相关的块答案自然错。后来改成取top-3到top-5让模型在多个候选里自行组织准确率明显上升。上下文拼接过长导致成本飙升。一开始贪心把尽量多的检索结果全塞进上下文结果token消耗直线上升延迟变高生成质量反而下降。后来加了“按相关性截断”的逻辑只保留超过阈值的文本块成本和效果同时改善。5. demo能跑和系统可用之间隔着评估、测试、成本与监控5.1 从离线指标到线上效果的闭环在Demo阶段拿几个例子出来“看起来不错”就能交差但真实系统不能这么干。必须把离线评估和线上表现连成一个闭环离线跑出指标 → 上线观察效果 → 收集bad case → 回流到数据和提示词迭代 → 再跑离线评估。离线评估我用的是固定评测集规模不大但覆盖了主要业务场景和典型边角情况每次改动都拿它回归一遍。线上则要看真实流量下的表现比如答案被采纳的比例、用户是否追问、检索命中率变化等。两边口径要尽量对齐不然离线涨分、线上翻车的情况会反复出现。5.2 回归测试用例集是刚需做传统软件时我们写过单元测试和回归测试AI系统同样需要。我用的是提示词回归用例集把一百多个有代表性的输入固化下来每次修改提示词、调整检索策略、更换模型后全量跑一遍对比输出是否回退。这个用例集的价值举两个真实的例子就懂了某次调优为了提升长文本处理效果改动了提示词模板结果长文本确实变好了但大量短问题开始出现不必要的展开回答靠回归用例集一下子抓了出来。更换向量模型后整体检索相似度都变了人肉看了几个例子感觉没问题回归用例集跑出来发现两类专业术语的检索质量明显下降及时做了回滚。没有回归集AI应用就像没有安全网走钢丝。5.3 成本与延迟压下来才算真的能用模型能力再强上线是要花钱和时间的。我在成本控制上常用的几个招缓存命中优先高频问题复用历史答案省下重复的计算开销。模型路由简单问题走小模型复杂问题才上大模型整体成本能降一大截体验上用户感知不明显。量化与精简把大模型量化到低精度评估指标基本持平延迟却能降不少。上下文瘦身严格控制塞给模型的内容量既省钱又降低延迟。延迟方面还要注意分位数而不是只看平均。线上系统的真实体验主要由P95甚至P99决定某个请求突然变慢可能比平均延迟高出一倍还多。我排查后发现很多延迟尖峰来自检索环节的一次串行调用改成并行后P95立刻明显下降。6. 三笔学费上下文窗口、显存幻觉与版本漂移6.1 上下文窗口不是加长就万事大吉我一度以为上下文窗口越长越好后来发现在超长上下文下模型对中间部分内容的关注度会下降这在检索增强场景里尤其要命。你要喂给模型的文本块太多太杂反而会让它“看花眼”。有一段时间我们遇到一个问题检索回来的内容明明是对的但生成的答案却漏掉了关键信息。后来发现是因为上下文里塞了五六个文本块其中包含大量和问题无关的背景描述模型被无关信息干扰了。解决办法就是建立相关性过滤把“可能有用”变成“确定有用才算数”不要迷信上下文越长越聪明。6.2 显存规划别靠“看起来能跑”自建模型推理服务时最坑的一种“错觉”是某个模型在本地跑通了就觉得显存没问题。真实场景差异巨大上线后并发请求同一时间到达峰值显存和单条推理完全不同。另外即便同一个模型不同输入长度对应的显存占用也差别巨大长文本请求会把显存拉到另一个量级。我的教训是上线前一定要做压测和显存画像。至少要知道单请求最大显存占用、并发N路时的峰值、输入长度和显存的关系曲线。不然服务一接真实流量就OOM重启脚本写一百遍也补不回来。压测工具不需要很复杂几十行Python脚本模拟并发即可重点是把画像数据记录下来以后换模型也有参考依据。6.3 版本漂移锁死你的依赖和模型模型和依赖库的版本漂移是我在工程化过程中最头疼的隐性坑。细节非常反直觉你觉得代码没动过结果系统行为变了。背后的原因往往是中间换了依赖库的小版本或者GPU驱动更新后推理结果有了细微差异甚至同一个模型权重文件被重新加载时精度截断逻辑不同。后来我养成的习惯是“锁版本锁一切”依赖锁文件必须提交进仓库模型权重记录下载地址、SHA256摘要、量化格式、加载参数每次模型更新严格走版本号管理线上稳定版本和实验版本分开部署关键测试环境用固定镜像禁止“临时升级依赖”这种操作。这套流程看起来偏传统软件工程但恰恰是AI项目从实验品走向稳定产品的关键一步。越是“研究味”重的项目越要主动往工程规范上靠否则后期维护成本会让你很痛苦。最后说一个我一直在坚持的小习惯每隔几周我会故意回到“最笨的手工状态”——不用任何框架用纯代码和基础库把最小链路重新走一遍。这个习惯帮我挡掉了不少“工具幻觉”。from scratch这条路走下来的终点不是你会用多少个框架而是对系统里每一层都心里有数。这个数有了后面学什么新东西都会快很多。
