如果你正打算进入 AI 工程这条赛道大概率会被“深度学习框架”“大模型微调”“RAG 检索增强”“向量数据库”“模型部署”这一串名词直接砸晕。我差不多也是这样过来的。做了两年多的 AI 工程落地项目踩了无数坑才慢慢把这堆名词变成一条能从零开始跑通的路线。这篇文章不聊那些看起来很厉害但实际上离题万里的“科普”只讲我实际动手时认为最重要的几件事怎么搭一个能用的 AI 应用、怎么把它工程化、怎么排查那些让人掉头发的实际问题。适合刚入门但不想只停留在调 API 的开发者也适合已经在做简单模型实验、想往正式工程师方向走的朋友。1. AI 工程这条路上的第一课先分清“算法”和“工程”很多人以为 AI 工程师主要工作是写模型、调参数其实真正占时间的是数据和工程。我刚入行时也天真地以为把模型跑通就完事后来才发现一个训练好的模型只是服务器上一堆权重文件要让它变成别人能用、稳定运行、可监控、可迭代的系统背后全是工程问题。1.1 算法 Demo 和可运行系统之间的那道墙模型在 Notebook 里跑出漂亮效果和它真正对外提供服务之间隔着一整面墙。举一个最简单的例子离线实验时你可以随时把数据 shuffle 一遍再跑但部署上线后用户的请求顺序是不可控的你没法对生产流量做 shuffle必须在预处理阶段就做好特征一致性和校验逻辑。另一个典型例子是并发。你用 Flask 起一个接口把模型加载进内存本地请求一次要 300 毫秒感觉还行一旦涌进来几十个并发请求模型推理变成串行延迟马上飙到几秒。这时候要加批处理、要上消息队列、要搞异步甚至要把推理服务拆成独立进程。这些都不是“算法”问题而是“工程”问题。所以我给自己的第一课就是AI 工程的核心不只是模型效果而是构建一套能稳定拿到预期效果的体系。模型效果是其中一个变量数据质量、特征管线、服务架构、监控告警加起来才构成一个完整的 AI 应用。1.2 判断自己是否适合走工程方向如果你想了解自己适不适合做 AI 工程可以先用三个问题自测你是否愿意花大量时间在数据清理、格式转换、接口联调这些“看起来不酷”的事情上你是否习惯性地思考“如果线上报错怎么办”而不是“精度再提高几个点”你是否对系统稳定性、可复现性这些事情比对新模型的好奇心更敏感如果你的回答大多是“是”那你非常适合走 AI 工程方向。它不像算法研究那样频繁追求 SOTA但它要求你具备很强的工程判断力什么环节可以妥协、什么环节绝不能省什么东西选型成本低但收益高。说白了这是一门关于“取舍”和“落地”的手艺。2. 从零搭建一个“能跑起来”的端到端项目RAG 问答机器人纯讲概念没有意义真正上手一个项目才是最快的路径。我从零开始练手时选择的是 RAG检索增强生成问答机器人因为它覆盖面广而且涵盖了一个 AI 应用的大部分核心工程环节文本处理、向量检索、大模型调用、服务封装、效果评估。2.1 为什么选 RAG 而不是训练大模型很多人一开始会纠结要不要微调一个大模型我的建议是除非你有明确的领域知识和固定输出格式需求否则第一版项目不要碰微调。微调成本高数据准备复杂而且效果不稳定RAG 则通过“先检索再生成”的方式把外部知识动态塞进上下文实现成本低迭代速度快。RAG 还有一个巨大的工程优势改知识库内容不需要重新训练模型。你只要更新向量数据库里的文档切片再刷新索引回答内容立刻随之变化。这意味着系统对数据更新的响应可以做到分钟级别而不是按天、按周等微调流程。对于绝大多数内容型应用、知识库问答、客服辅助系统RAG 都是比微调更务实、更具性价比的架构。2.2 数据准备与 Embedding 流程我搭的第一个 RAG Demo 用的是本地一份 PDF 产品手册。工程第一步不是写模型调用代码而是把 PDF 解析成干净文本。这里最容易踩坑的是 PDF 里的表格和分栏直接读取会把版面搞乱甚至把文字顺序弄反。我当时的做法是先用专门的 PDF 解析库抽取文本块和表格区域再按一级标题、二级标题的位置把内容切分成多个段落。不要小看这一步RAG 的检索质量高度依赖文本切分策略。如果你一句话一个 chunk向量表达太碎片化检索不到完整信息如果整篇塞进一个 chunk向量方向又被大量无关内容稀释相关性反而下降。实际测试下来按语义段落切分、每个 chunk 控制在 300 到 800 字之间效果相对稳定。Embedding 模型我选的是中文效果还不错的通用模型直接通过 API 把每个 chunk 转成向量然后写入向量数据库。这里的工程细节包括批量请求要控制并发避免限流写入失败要设计重试机制向量字段和原始文本、来源页码要存在同一条记录里。你会发现还没有正式调用大模型工程复杂度已经上来了。2.3 检索与生成阶段的工程实现细节RAG 的检索阶段和生成阶段不是孤立的中间还隔着提示词组装。我最早犯的错误是所有问题都只取相似度最高的 top 1 结果去拼提示词结果模型经常一本正经地瞎编。后来改成取 top 4并且把每个结果都带上“来源xxx 部门产品手册页码 p23”这样的元信息让模型在回答时能引用来源明显降低了胡编概率。生成阶段的提示词也需要打磨。我最终用的模板很简单先告诉模型“你是一个基于资料库回答问题的助手只能使用给定资料中的信息”然后把问题和资料片段一起交出去最后强调“如果资料中没有相关信息请直接回答不知道”。不要小看这句话它对大模型的“幻觉抑制”作用比想象中大得多。跑通这个完整链路之后你才算真正摸到了 AI 工程的入门门槛。因为接下来要考虑的是怎么把它交给别人用、怎么保存版本、怎么处理异常。3. 工程化落地目录结构、依赖与版本管理的实战习惯做过几个实验项目后你会发现AI 项目和普通后端项目最大不同在于它不仅有代码还有数据、模型权重、实验记录。这些文件无法全部塞进 Git也不能靠注释说清楚。所以工程化落地的第一步就是设计一个合适的目录结构。3.1 一个能持续迭代的项目目录长什么样我现在的项目目录通常是这样project/ ├── data/ │ ├── raw/ │ ├── processed/ │ └── embeddings/ ├── src/ │ ├── ingestion/ │ ├── retrieval/ │ ├── generation/ │ └── evaluation/ ├── configs/ │ └── config.yaml ├── scripts/ ├── tests/ ├── experiments/ │ └── exp_001/ └── models/ └── embedding_model/这个结构最大的好处是职责清晰data/raw永远放原始数据任何脚本都禁止直接修改原始文件src/下按功能模块划分代码对应 RAG 的摄入、检索、生成、评估四大部分experiments/专门存放实验记录和指标避免“这个实验试过没有”的问题。我之前见过太多项目把原始数据、处理脚本、模型文件全部堆在项目根目录最后根本分不清哪个是哪个。建立一个目录结构不费多少时间却能省下后面几个月的混乱成本。3.2 依赖锁定与模型版本化被环境炸毁之后学会的事AI 项目依赖混乱造成的灾难我亲身体会过。有一次项目组新增了一个 Python 包结果把科学计算库的版本顶掉了所有跑批任务全部因版本冲突挂掉整整排查了一个下午。后来我学乖了项目一律使用虚拟环境并导出依赖锁定文件不仅锁定主依赖还要锁定传递依赖。改依赖时单独提交一次变更并在提交说明里写清楚“为什么升级这个包”。模型版本化也要重视。大模型对训练数据、tokenizer 和超参版本极其敏感一个模型目录不知道对应哪组参数等于项目埋了一颗雷。我现在每个模型目录都会放三个东西模型权重文件、一个模型的推理代码、一个 README 记录训练或微调时的实验参数。权重文件体积大没法走 Git就单独传到对象存储并在 README 里写清楚对应路径和创建时间。3.3 最小可复现的数据、代码、实验结果三件套干这行最怕的就是“我记得我做过这个实验但忘了当时用的哪份数据”。为了避免这种状态我现在每个实验都强制记录三样东西一份可以直接读取的数据样本几行即可但必须能代表全量一份完整的代码版本提交对应的哈希或分支一份记录实验配置和结果的文本包括种子、超参数、最终指标这三件套加在一起哪怕三个月后再翻回来看也能原样复现。对 AI 工程来说可复现性比高性能更重要因为它关乎信任和迭代速度。4. 踩坑实录RAG 项目里最折磨人的五个问题与完整排查链路RAG 这个方向看着简单真正调试起来能让人怀疑人生。下面这几个坑是我在实际项目里反复踩过的有的甚至踩了两轮每条都附上我的排查思路和最终解法。4.1 检索结果总是答非所问问题不在模型现象同一个问题在 Notebook 里测检索到的片段看着挺对但到了服务上线回答质量明显下降。排查链路我首先怀疑的是生成阶段的提示词调了几版没什么变化然后怀疑 Embedding 模型试了多种模型效果差不多最后才回头看数据流发现线上服务的文本解析逻辑和离线脚本并不同步。离线脚本对文档做了额外的清洗比如去掉页眉页脚、修正 OCR 错字而线上服务直接用了原始解析结果。两边数据不一致检索效果自然不一样。解法把数据处理逻辑抽成一个独立模块离线和线上统一调用同一个入口。这个坑给了一个很重要的教训——AI 服务里的“数据不一致”非常隐蔽排查时一定要先确认两个环境跑的是不是同一套代码、同一份处理逻辑。4.2 中文文本切分导致的语义断裂现象切分出来的 chunk 看起来正常但向量检索时很多看似能回答问题的片段召不回来。排查我最初用固定字符长度切分比如每 500 字一刀切。中文文本不像英文有天然空格固定长度切分很容易把完整语义切断比如“小明毕业于清华大学”被切成“小明毕业于清华”和“大学”两句单看都是残废。Embedding 模型对这种截断句子很敏感向量表达会偏离原意。解法改成按语义段落切分优先以换行符、句号等自然边界切分再按长度上限做二次合并。我还在预处理阶段保存了原文位置信息方便生成阶段引用来源。切分策略决定了检索的下限这个环节值得多花时间测试。4.3 向量召回和重排之间的管线断层现象top 10 召回结果里明明有正确答案但最终返回给模型的内容里没有它。排查我在检索阶段加了重排逻辑想通过交叉编码器把 top 20 精排成 top 4。但一开始重排器的输入用的是向量数据库返回的 score而不是把 query 和 doc 拼起来重新计算 relevance。这样导致部分低向量相似度但语义相关的文档被早早淘汰。解法把检索拆成两个阶段第一阶段是快速向量召回取 top 20第二阶段用重排模型基于 query 和 document 的完整文本重新打分。重排不能直接用第一阶段的向量距离必须重新算。这一步优化后回答的相关性肉眼可见提升。4.4 上下文窗口超限与 chunk 过大现象文档段落很长拼进提示词后直接把上下文窗口塞爆大模型开始“模糊记忆”输出反而离题。排查我最初为了追求信息完整把 chunk 上限设得很高。结果发现模型在长上下文里更容易被无关细节带偏注意不到真正关键的信息。上下文窗口不是越大越好而是要充分留白。解法压缩单个 chunk 长度把每轮送入模型的最大资料量控制在 1200 字以内。同时只把重排后最相关的 3 到 4 个片段送进去而不是一刀切全部取这样推理更快回答也更聚焦。4.5 线上服务常驻内存泄漏的排查思路现象部署上线两周后服务内存持续上涨最终 OOM 被重启。排查这是一个典型的工程问题。我先看观测面板发现内存曲线是阶梯式上涨怀疑有资源没释放查日志定位到问题在 Embedding 模型的 batch 处理进程原来在池化连接时对象没被正确回收累积成了内存泄漏。解法重写连接池的创建和销毁逻辑在并发请求结束后显式释放对象并在测试环境做了持续压测验证内存曲线终于稳成一条横线。这件事教会我一个道理AI 服务首先是一个常驻服务资源生命周期管理是基本功不能用“写脚本”的心态糊弄过去。下面用一张表把这些问题和根因整理清楚方便大家对照问题现象根因解决方案线上回答质量明显下降离线/线上数据处理逻辑不一致将数据处理抽成统一模块语义相关片段召不回来固定长度切分切断语义按语义段落切分保留原文位置答案明明在但没送进模型重排阶段误用向量距离打分重排时重新计算完整文本相关性上下文溢出、回答离题单个 chunk 过长压缩 chunk 长度限制送入片段数量常驻服务 OOM 重启连接池对象未正确释放重写资源生命周期管理并压测验证5. 再往前一步评估、监控和持续改进跑通 RAG 项目只是一个开始真正让这个项目“可靠”的是评估体系和监控体系。没有这两样你连“系统变好了还是变坏了”都不知道更谈不上迭代。5.1 离线评估集没有指标就等于没有方向我建议你从项目第一天就整理一份离线评估集哪怕只有几十条也一定要覆盖“单轮问答”“多轮追溯”“知识缺失”三类问题。每一条都要有标准答案和可接受的参考答案判断回答是否合格的标准可以放宽但不能缺。基于这个评估集每次改动检索策略、切分策略或提示词之后都跑一遍完整流程记录准确率、召回率、回答可接受率这几个指标。我实际用的评估逻辑很简单先把模型输出拆成几个关键判断点人工判断回答是否完整、是否有依据、是否出现明显事实错误。这样既能量化每次改动带来的影响也能在模型更新后快速发现回退现象。5.2 线上日志与反馈回路线上系统必须记录足够详细的日志。RAG 系统尤其要关注三个信息用户原始问题、检索出来的片段及来源、模型最终回答。把这些日志沉淀下来不仅能在出问题时回溯还能筛选出高价值的“失败样例”回填进离线评估集。我还会给每个回答加一个“回答是否有帮助”的反馈入口虽然参与率不高但样本仍比随机抽要有价值。当线上出现连续低分样本时我就拿这些样本去查是检索没找到相关资料还是生成阶段理解错了问题。有了这个回路系统迭代就是从“拍脑袋改参数”变成“有数据驱动的优化”。5.3 四种高性价比的优化杠杆评估体系跑起来后优化方向也就清晰了。我实际验证下来性价比最高的优化手段有四类提升检索质量清洗数据、优化切分策略、加入重排模型、调整召回数量优化提示词模板给模型明确的角色定位和回答边界对降低幻觉立竿见影引入反馈数据把线上失败样本加入评估集和知识库形成正反馈闭环合理控制上下文精简送入模型的片段缩短推理时间并减少噪声这四类优化的共同特点是成本低、见效快、可量化。我建议不要一上来就换模型或者重新微调先把基础工程做到位你会惊讶地发现系统整体效果提升远比换一个大模型更明显。最后分享一个我坚持了很久的复盘习惯每次项目告一段落我都会写一份“这周踩了什么坑”的小记录把问题现象、根因、解决路径、后续预防措施四条写清楚。不必长篇大论但一定要落到纸面上。很多坑下次换一个项目还会再遇到这份记录经常能在我快重复踩坑的时候拉我一把。AI 工程是典型的实践驱动的领域做得越多、踩得越多积累出来的经验就越值钱。希望这篇文章能帮你少走几段弯路把更多时间花在真正有价值的事情上。 AI工程实战：从RAG搭建到部署的完整落地指南
如果你正打算进入 AI 工程这条赛道大概率会被“深度学习框架”“大模型微调”“RAG 检索增强”“向量数据库”“模型部署”这一串名词直接砸晕。我差不多也是这样过来的。做了两年多的 AI 工程落地项目踩了无数坑才慢慢把这堆名词变成一条能从零开始跑通的路线。这篇文章不聊那些看起来很厉害但实际上离题万里的“科普”只讲我实际动手时认为最重要的几件事怎么搭一个能用的 AI 应用、怎么把它工程化、怎么排查那些让人掉头发的实际问题。适合刚入门但不想只停留在调 API 的开发者也适合已经在做简单模型实验、想往正式工程师方向走的朋友。1. AI 工程这条路上的第一课先分清“算法”和“工程”很多人以为 AI 工程师主要工作是写模型、调参数其实真正占时间的是数据和工程。我刚入行时也天真地以为把模型跑通就完事后来才发现一个训练好的模型只是服务器上一堆权重文件要让它变成别人能用、稳定运行、可监控、可迭代的系统背后全是工程问题。1.1 算法 Demo 和可运行系统之间的那道墙模型在 Notebook 里跑出漂亮效果和它真正对外提供服务之间隔着一整面墙。举一个最简单的例子离线实验时你可以随时把数据 shuffle 一遍再跑但部署上线后用户的请求顺序是不可控的你没法对生产流量做 shuffle必须在预处理阶段就做好特征一致性和校验逻辑。另一个典型例子是并发。你用 Flask 起一个接口把模型加载进内存本地请求一次要 300 毫秒感觉还行一旦涌进来几十个并发请求模型推理变成串行延迟马上飙到几秒。这时候要加批处理、要上消息队列、要搞异步甚至要把推理服务拆成独立进程。这些都不是“算法”问题而是“工程”问题。所以我给自己的第一课就是AI 工程的核心不只是模型效果而是构建一套能稳定拿到预期效果的体系。模型效果是其中一个变量数据质量、特征管线、服务架构、监控告警加起来才构成一个完整的 AI 应用。1.2 判断自己是否适合走工程方向如果你想了解自己适不适合做 AI 工程可以先用三个问题自测你是否愿意花大量时间在数据清理、格式转换、接口联调这些“看起来不酷”的事情上你是否习惯性地思考“如果线上报错怎么办”而不是“精度再提高几个点”你是否对系统稳定性、可复现性这些事情比对新模型的好奇心更敏感如果你的回答大多是“是”那你非常适合走 AI 工程方向。它不像算法研究那样频繁追求 SOTA但它要求你具备很强的工程判断力什么环节可以妥协、什么环节绝不能省什么东西选型成本低但收益高。说白了这是一门关于“取舍”和“落地”的手艺。2. 从零搭建一个“能跑起来”的端到端项目RAG 问答机器人纯讲概念没有意义真正上手一个项目才是最快的路径。我从零开始练手时选择的是 RAG检索增强生成问答机器人因为它覆盖面广而且涵盖了一个 AI 应用的大部分核心工程环节文本处理、向量检索、大模型调用、服务封装、效果评估。2.1 为什么选 RAG 而不是训练大模型很多人一开始会纠结要不要微调一个大模型我的建议是除非你有明确的领域知识和固定输出格式需求否则第一版项目不要碰微调。微调成本高数据准备复杂而且效果不稳定RAG 则通过“先检索再生成”的方式把外部知识动态塞进上下文实现成本低迭代速度快。RAG 还有一个巨大的工程优势改知识库内容不需要重新训练模型。你只要更新向量数据库里的文档切片再刷新索引回答内容立刻随之变化。这意味着系统对数据更新的响应可以做到分钟级别而不是按天、按周等微调流程。对于绝大多数内容型应用、知识库问答、客服辅助系统RAG 都是比微调更务实、更具性价比的架构。2.2 数据准备与 Embedding 流程我搭的第一个 RAG Demo 用的是本地一份 PDF 产品手册。工程第一步不是写模型调用代码而是把 PDF 解析成干净文本。这里最容易踩坑的是 PDF 里的表格和分栏直接读取会把版面搞乱甚至把文字顺序弄反。我当时的做法是先用专门的 PDF 解析库抽取文本块和表格区域再按一级标题、二级标题的位置把内容切分成多个段落。不要小看这一步RAG 的检索质量高度依赖文本切分策略。如果你一句话一个 chunk向量表达太碎片化检索不到完整信息如果整篇塞进一个 chunk向量方向又被大量无关内容稀释相关性反而下降。实际测试下来按语义段落切分、每个 chunk 控制在 300 到 800 字之间效果相对稳定。Embedding 模型我选的是中文效果还不错的通用模型直接通过 API 把每个 chunk 转成向量然后写入向量数据库。这里的工程细节包括批量请求要控制并发避免限流写入失败要设计重试机制向量字段和原始文本、来源页码要存在同一条记录里。你会发现还没有正式调用大模型工程复杂度已经上来了。2.3 检索与生成阶段的工程实现细节RAG 的检索阶段和生成阶段不是孤立的中间还隔着提示词组装。我最早犯的错误是所有问题都只取相似度最高的 top 1 结果去拼提示词结果模型经常一本正经地瞎编。后来改成取 top 4并且把每个结果都带上“来源xxx 部门产品手册页码 p23”这样的元信息让模型在回答时能引用来源明显降低了胡编概率。生成阶段的提示词也需要打磨。我最终用的模板很简单先告诉模型“你是一个基于资料库回答问题的助手只能使用给定资料中的信息”然后把问题和资料片段一起交出去最后强调“如果资料中没有相关信息请直接回答不知道”。不要小看这句话它对大模型的“幻觉抑制”作用比想象中大得多。跑通这个完整链路之后你才算真正摸到了 AI 工程的入门门槛。因为接下来要考虑的是怎么把它交给别人用、怎么保存版本、怎么处理异常。3. 工程化落地目录结构、依赖与版本管理的实战习惯做过几个实验项目后你会发现AI 项目和普通后端项目最大不同在于它不仅有代码还有数据、模型权重、实验记录。这些文件无法全部塞进 Git也不能靠注释说清楚。所以工程化落地的第一步就是设计一个合适的目录结构。3.1 一个能持续迭代的项目目录长什么样我现在的项目目录通常是这样project/ ├── data/ │ ├── raw/ │ ├── processed/ │ └── embeddings/ ├── src/ │ ├── ingestion/ │ ├── retrieval/ │ ├── generation/ │ └── evaluation/ ├── configs/ │ └── config.yaml ├── scripts/ ├── tests/ ├── experiments/ │ └── exp_001/ └── models/ └── embedding_model/这个结构最大的好处是职责清晰data/raw永远放原始数据任何脚本都禁止直接修改原始文件src/下按功能模块划分代码对应 RAG 的摄入、检索、生成、评估四大部分experiments/专门存放实验记录和指标避免“这个实验试过没有”的问题。我之前见过太多项目把原始数据、处理脚本、模型文件全部堆在项目根目录最后根本分不清哪个是哪个。建立一个目录结构不费多少时间却能省下后面几个月的混乱成本。3.2 依赖锁定与模型版本化被环境炸毁之后学会的事AI 项目依赖混乱造成的灾难我亲身体会过。有一次项目组新增了一个 Python 包结果把科学计算库的版本顶掉了所有跑批任务全部因版本冲突挂掉整整排查了一个下午。后来我学乖了项目一律使用虚拟环境并导出依赖锁定文件不仅锁定主依赖还要锁定传递依赖。改依赖时单独提交一次变更并在提交说明里写清楚“为什么升级这个包”。模型版本化也要重视。大模型对训练数据、tokenizer 和超参版本极其敏感一个模型目录不知道对应哪组参数等于项目埋了一颗雷。我现在每个模型目录都会放三个东西模型权重文件、一个模型的推理代码、一个 README 记录训练或微调时的实验参数。权重文件体积大没法走 Git就单独传到对象存储并在 README 里写清楚对应路径和创建时间。3.3 最小可复现的数据、代码、实验结果三件套干这行最怕的就是“我记得我做过这个实验但忘了当时用的哪份数据”。为了避免这种状态我现在每个实验都强制记录三样东西一份可以直接读取的数据样本几行即可但必须能代表全量一份完整的代码版本提交对应的哈希或分支一份记录实验配置和结果的文本包括种子、超参数、最终指标这三件套加在一起哪怕三个月后再翻回来看也能原样复现。对 AI 工程来说可复现性比高性能更重要因为它关乎信任和迭代速度。4. 踩坑实录RAG 项目里最折磨人的五个问题与完整排查链路RAG 这个方向看着简单真正调试起来能让人怀疑人生。下面这几个坑是我在实际项目里反复踩过的有的甚至踩了两轮每条都附上我的排查思路和最终解法。4.1 检索结果总是答非所问问题不在模型现象同一个问题在 Notebook 里测检索到的片段看着挺对但到了服务上线回答质量明显下降。排查链路我首先怀疑的是生成阶段的提示词调了几版没什么变化然后怀疑 Embedding 模型试了多种模型效果差不多最后才回头看数据流发现线上服务的文本解析逻辑和离线脚本并不同步。离线脚本对文档做了额外的清洗比如去掉页眉页脚、修正 OCR 错字而线上服务直接用了原始解析结果。两边数据不一致检索效果自然不一样。解法把数据处理逻辑抽成一个独立模块离线和线上统一调用同一个入口。这个坑给了一个很重要的教训——AI 服务里的“数据不一致”非常隐蔽排查时一定要先确认两个环境跑的是不是同一套代码、同一份处理逻辑。4.2 中文文本切分导致的语义断裂现象切分出来的 chunk 看起来正常但向量检索时很多看似能回答问题的片段召不回来。排查我最初用固定字符长度切分比如每 500 字一刀切。中文文本不像英文有天然空格固定长度切分很容易把完整语义切断比如“小明毕业于清华大学”被切成“小明毕业于清华”和“大学”两句单看都是残废。Embedding 模型对这种截断句子很敏感向量表达会偏离原意。解法改成按语义段落切分优先以换行符、句号等自然边界切分再按长度上限做二次合并。我还在预处理阶段保存了原文位置信息方便生成阶段引用来源。切分策略决定了检索的下限这个环节值得多花时间测试。4.3 向量召回和重排之间的管线断层现象top 10 召回结果里明明有正确答案但最终返回给模型的内容里没有它。排查我在检索阶段加了重排逻辑想通过交叉编码器把 top 20 精排成 top 4。但一开始重排器的输入用的是向量数据库返回的 score而不是把 query 和 doc 拼起来重新计算 relevance。这样导致部分低向量相似度但语义相关的文档被早早淘汰。解法把检索拆成两个阶段第一阶段是快速向量召回取 top 20第二阶段用重排模型基于 query 和 document 的完整文本重新打分。重排不能直接用第一阶段的向量距离必须重新算。这一步优化后回答的相关性肉眼可见提升。4.4 上下文窗口超限与 chunk 过大现象文档段落很长拼进提示词后直接把上下文窗口塞爆大模型开始“模糊记忆”输出反而离题。排查我最初为了追求信息完整把 chunk 上限设得很高。结果发现模型在长上下文里更容易被无关细节带偏注意不到真正关键的信息。上下文窗口不是越大越好而是要充分留白。解法压缩单个 chunk 长度把每轮送入模型的最大资料量控制在 1200 字以内。同时只把重排后最相关的 3 到 4 个片段送进去而不是一刀切全部取这样推理更快回答也更聚焦。4.5 线上服务常驻内存泄漏的排查思路现象部署上线两周后服务内存持续上涨最终 OOM 被重启。排查这是一个典型的工程问题。我先看观测面板发现内存曲线是阶梯式上涨怀疑有资源没释放查日志定位到问题在 Embedding 模型的 batch 处理进程原来在池化连接时对象没被正确回收累积成了内存泄漏。解法重写连接池的创建和销毁逻辑在并发请求结束后显式释放对象并在测试环境做了持续压测验证内存曲线终于稳成一条横线。这件事教会我一个道理AI 服务首先是一个常驻服务资源生命周期管理是基本功不能用“写脚本”的心态糊弄过去。下面用一张表把这些问题和根因整理清楚方便大家对照问题现象根因解决方案线上回答质量明显下降离线/线上数据处理逻辑不一致将数据处理抽成统一模块语义相关片段召不回来固定长度切分切断语义按语义段落切分保留原文位置答案明明在但没送进模型重排阶段误用向量距离打分重排时重新计算完整文本相关性上下文溢出、回答离题单个 chunk 过长压缩 chunk 长度限制送入片段数量常驻服务 OOM 重启连接池对象未正确释放重写资源生命周期管理并压测验证5. 再往前一步评估、监控和持续改进跑通 RAG 项目只是一个开始真正让这个项目“可靠”的是评估体系和监控体系。没有这两样你连“系统变好了还是变坏了”都不知道更谈不上迭代。5.1 离线评估集没有指标就等于没有方向我建议你从项目第一天就整理一份离线评估集哪怕只有几十条也一定要覆盖“单轮问答”“多轮追溯”“知识缺失”三类问题。每一条都要有标准答案和可接受的参考答案判断回答是否合格的标准可以放宽但不能缺。基于这个评估集每次改动检索策略、切分策略或提示词之后都跑一遍完整流程记录准确率、召回率、回答可接受率这几个指标。我实际用的评估逻辑很简单先把模型输出拆成几个关键判断点人工判断回答是否完整、是否有依据、是否出现明显事实错误。这样既能量化每次改动带来的影响也能在模型更新后快速发现回退现象。5.2 线上日志与反馈回路线上系统必须记录足够详细的日志。RAG 系统尤其要关注三个信息用户原始问题、检索出来的片段及来源、模型最终回答。把这些日志沉淀下来不仅能在出问题时回溯还能筛选出高价值的“失败样例”回填进离线评估集。我还会给每个回答加一个“回答是否有帮助”的反馈入口虽然参与率不高但样本仍比随机抽要有价值。当线上出现连续低分样本时我就拿这些样本去查是检索没找到相关资料还是生成阶段理解错了问题。有了这个回路系统迭代就是从“拍脑袋改参数”变成“有数据驱动的优化”。5.3 四种高性价比的优化杠杆评估体系跑起来后优化方向也就清晰了。我实际验证下来性价比最高的优化手段有四类提升检索质量清洗数据、优化切分策略、加入重排模型、调整召回数量优化提示词模板给模型明确的角色定位和回答边界对降低幻觉立竿见影引入反馈数据把线上失败样本加入评估集和知识库形成正反馈闭环合理控制上下文精简送入模型的片段缩短推理时间并减少噪声这四类优化的共同特点是成本低、见效快、可量化。我建议不要一上来就换模型或者重新微调先把基础工程做到位你会惊讶地发现系统整体效果提升远比换一个大模型更明显。最后分享一个我坚持了很久的复盘习惯每次项目告一段落我都会写一份“这周踩了什么坑”的小记录把问题现象、根因、解决路径、后续预防措施四条写清楚。不必长篇大论但一定要落到纸面上。很多坑下次换一个项目还会再遇到这份记录经常能在我快重复踩坑的时候拉我一把。AI 工程是典型的实践驱动的领域做得越多、踩得越多积累出来的经验就越值钱。希望这篇文章能帮你少走几段弯路把更多时间花在真正有价值的事情上。