先说实话我最近面试了不少挂着“AI工程师”头衔的候选人简历上写满了各种模型名和框架但当我问“你怎么证明这套系统这周比上周更好用”的时候一半以上的人会沉默。这个问题暴露的是很多人根本没理解 ai-engineering 到底在干什么。跑通一个模型不是工程把模型变成稳定、可控、低成本、可迭代的产品才算工程。这篇文章算是我从零搭建 AI 工程体系的一份完整复盘。我会把算法工程师和 AI 工程师的边界讲清楚把从 Python 基础到 RAG 实战的成长路线拆开把上线后那些没人提前告诉你的坑一个个摆出来再给你能直接抄作业的方法。适合想转 AI 方向的后端开发也适合刚入行的算法新人以及被老板扔了一个 AI 项目但脑子里还没地图的团队负责人。放心我不贴大段论文公式尽量用能落地的大白话讲清楚每一步的“为什么”。1. AI工程到底是什么和跑通一个模型完全不是一回事1.1 算法岗和工程岗隔着一整条产品线我见过太多团队把算法工程师和 AI 工程师混为一谈结果项目做到一半就卡死。算法工程师的核心任务是“证明可行”在一个数据集上把某个指标刷上去验证某个模型结构是否有效。他们的产出是一份实验记录、一组权重文件、一篇研究报告。而 AI 工程师的核心任务是“交付可用”把已经证明可行的技术变成用户能稳定使用的东西要管数据、管服务、管成本、管监控、管回归测试。这两个岗位的思维模式差异很大。我常用一个比喻算法工程师是发明新菜谱的厨师AI 工程师是把菜谱变成中央厨房标准化流程的人。你当然可以既懂研发又懂生产但你的精力分配和做事方式会截然不同。后台算法同学把离线召回准确率做到 98%上线以后用户依然骂“这机器人答非所问”这种案例我见过不止一次。原因是用户的问题分布和精挑细选的测试集永远不一样离线 98% 的分数在线上可能连 60% 都不到。这就是典型的不理解 AI 工程模型能力只是系统能力的一部分数据质量、检索逻辑、提示词结构、兜底策略每一环都在决定最终用户体验。再具体一点我给你画一下两种角色的日常。算法工程师一天下来主要在研究 loss 曲线、调整超参数、洗特征。AI 工程师一天下来可能在写文档解析脚本、调向量检索参数、设计 prompt 模板的版本管理、和运维一起排查 GPU 显存泄漏。你看着都很“AI”但关注点完全不同。如果你是转行进来的你要明白行业里大量岗位说的“AI工程师”其实更接近后者。1.2 AI工程师的真实能力栈数据、模型、服务、评测很多新人学 AI 工程第一反应是“我要把 Transformer 底层写出花”。但真实项目里AI 工程师最值钱的往往不是手写模型而是另外几项不太炫酷的能力。我按重要程度排序数据工程能力数据采集、格式解析、清洗、去重、标注、质检。一个 AI 项目里人力成本最大、迭代最频繁的环节十有八九在数据侧不在模型侧。模型与算法基础不需要从零手写 Transformer但要能读懂模型卡说明、知道不同模型的适用长度、了解 temperature 和 top_p 对输出的影响、能判断什么时候该微调、什么时候该用 RAG。服务化与部署API 设计、并发控制、推理加速、镜像打包、灰度发布、监控告警。这部分能力决定了系统能不能扛住真实流量。评测与迭代建评测集、跑回归、比较不同 prompt 或不同模型版本的效果。很多团队做不好 AI 项目不是因为模型不够强而是因为“变好了还是变差了”全靠感觉。上面这个能力栈四分之三的人都低估了“评测”这一环。我后面会专门展开这里先点一句没有评测体系的 AI 系统就是一辆没有仪表盘的跑车你能开但你不知道什么时候会爆缸。为了让你更直观地对照我把常见误区也列一下能力域核心工具举例常见误区数据工程Pandas、PaddleOCR、pdfplumber、Label Studio拿到文档直接切分向量化不做清洗模型基础PyTorch、Transformers、vLLM只看榜单选最大模型不看场景成本服务化FastAPI、Docker、Nginx没做并发控制直接用同步阻塞接口评测自建评测集、模型打分、回归脚本凭人工抽查代替系统性评测2. 从零起步的技术选型和一条成长路线2.1 为什么语言和框架要先选Python很多后端同事一听说 AI第一反应就是“我要用 Java 或 Go 写一个高性能推理服务”。我的建议正好相反从零开始学 AI 工程语言先死磕 Python 就好。理由非常简单目前 AI 生态几乎全部长在 Python 上。PyTorch、Transformers、LangChain、LlamaIndex、FastAPI甚至 vLLM 的 Python 接口你都能在一小时之内把模型串起来。如果你非要一开始就用 Go 或 Java 去对接推理引擎光是 tokenizer 兼容、模型格式解析、prompt 模板管理这些事就能把你劝退。速度是不是瓶颈在这个架构下基本不是。AI 工程的性能瓶颈绝大多数在 GPU 显存带宽、推理引擎的调度效率、向量检索的召回精度这些地方不在业务语言的循环速度上。Python 负责调度和管理真正跑重活的交给 vLLM、TensorRT-LLM 这些专用引擎或者用 C 写一个独立的推理微服务。这套分工已经是行业默认范式没必要逆着来。2.2 工具链选型框架、向量数据库、推理引擎从零搭一套 AI 系统最核心的选型点有四块模型框架、向量存储、推理服务和业务服务框架。以我自己的实践经验每个位置都有相对稳妥的选择核心逻辑不是“哪个新用哪个”而是“稳定、生态好、团队学得会”。组件我建议的选项备选项选择理由模型框架PyTorch无Transformers/HuggingFace 生态默认基于它向量存储起步用 FAISS数据量大换 Milvus 或 QdrantElasticsearch 自带向量能力FAISS 够简单百万级数据轻松扛住推理服务vLLMOllama、TensorRT-LLM、ONNX RuntimevLLM 吞吐高、兼容性好社区活跃业务框架FastAPIFlask、Gradio自带 OpenAPI 文档写起来快选型有一个极易踩的坑过早引入重量级组件。我见过一个几万条文档的知识库项目团队第一周就上了分布式向量数据库集群三个人维护了两周还没把数据灌进去。其实这个量级一个 FAISS 本地索引加一份 JSON 快照就够了效果一样运维成本低一个数量级。你要记住选型帮你解决的是当前瓶颈不是提前透支未来的麻烦。2.3 三步爬坡路线从本地脚本到线上服务我给零基础读者和半路转行的朋友画过一条路线叫“三步爬坡法”。按这个顺序走成长曲线最平滑每个阶段都能看到成果。第一步本地跑通一个开源模型。到 HuggingFace 上下一个 Qwen 或 Llama 的小尺寸版本用 Transformers 库加载起来让它复述一句你写的话。整个过程里你会自然理解 tokenizer 怎么把文本变成 token模型怎么加载权重输出怎么采样解码。这一步不要贪大一个 1B 到 7B 之间的模型足够建立体感。第二步把它用 FastAPI 包成一个 HTTP 接口。给服务加一个全局并发控制防止多个请求同时撞到同一个推理进程里。这一步的核心是理解“模型是有状态的接口必须是无状态的”这个工程事实。你还需要学会如何在进程启动时加载模型而不是每次请求都重新加载一次。第三步给它加记忆和工具。试试给服务接一个向量检索数据库让它能基于你自己的文档回答问题。做到这一步你就摸到了 RAG 的门口这也是我认为目前 AI 工程落地率最高、性价比最好的架构。后面我会专门用一个章节把 RAG 的完整搭建过程拆给你看。3. 手把手拆解一个RAG知识库问答系统3.1 需求分解与架构设计先想清楚再写代码我挑一个最常见的场景来讲企业内部售后知识库问答。比如一家卖设备的企业库里躺着几百份产品说明书、故障手册和维修记录售后客服每天要重复回答大量“设备故障代码怎么解决”之类的问题。我们要做的就是让售前人员或最终用户直接提问系统自动从文档库中检索相关内容生成准确回答并且附上原文编号方便追溯。这个需求第一眼感觉“接一个对话模型就行”但一拆就发现问题不少。你至少需要处理五件事文档格式五花八门有扫描 PDF有 Word有带复杂表格的 Excel文档会定期更新旧的知识不能一直占着回答必须可追溯否则客服不敢采纳不同的用户问题风格差异很大有人问“机器报 E001 错怎么处理”有人问“怎么解决设备启动后又立刻停机”。每一件事对应系统里的一个模块文档解析、切分、向量化、存储、检索、生成、引用溯源。在架构上我建议把系统拆成两条链路坚决不要把所有的逻辑堆在一个脚本里。离线数据链路原始文档 → 格式解析 → 清洗 → 切分 → 向量化 → 索引构建 → 索引版本管理。在线推理链路用户提问 → 问题向量化 → 混合检索 → 候选片段排序 → prompt 组装 → 大模型生成 → 引用校验 → 输出返回。两条链路分开的最大好处是互不干扰你更新文档索引的时候在线服务不用重启在线链路出了性能问题你也不会被数据解析的逻辑干扰排查思路。3.2 文档解析和清洗最容易被忽视的起跑线很多 RAG 项目翻车不是模型选错了而是“文档没洗干净”。企业文档是重灾区扫描 PDF 里文字是图片Word 里嵌着表格Excel 明明是结构化数据却被绕来绕去的注释搞得很难解析。这些问题若不处理检索时就会出现片段错位、信息残缺、表格内容完全走样。我现在的处理流程固定为四步格式摸底先统计你手上有多少种文档格式各自占比。这一步看似多余但决定了你后面人力怎么分配。文本提取扫描件用 OCR我主要用 PaddleOCR中文识别效果比很多老牌开源工具好数字化 PDF 用 pdfplumber 或 PyMuPDF各有用武之地优先保表格和段落结构。清洗去掉页眉页脚、页号、重复标题、无关声明。表格在清洗过程中统一转成 Markdown 表格避免后续模型和切分算法丢掉结构。语义切分按标题层级和段落边界切不是简单按字符数硬切。切分这一步特别值得说。固定长度切分比如每 512 个字符一刀切过去看着省事但频繁地把话题从“设备安装步骤”切到“故障代码表”检索的时候会莫名其妙召回一些语义断裂的片段。我现在的做法是先用 Markdown 标题把文档切成大块再把大块内按段落、列表项切成长度 200 到 400 字的小片段相邻片段之间保留 30 到 50 个字的重叠这样既能保证语义完整又能照顾到跨段落的上下文衔接。3.3 向量化与索引构建选对Embedding模型检索就赢了一半文档切好之后要做 embedding 向量化。中文场景下我很推荐开源的 BAAI/bge-m3效果不错且能本地部署维度是 1024不依赖云端接口也能跑。如果你的团队不想维护 embedding 模型直接用云厂商的向量化接口也行1536 维或 1024 维都常见。这里提醒一句维度不是越高越好。高维度带来更高的存储成本和检索耗时如果 bge-m3 的 1024 维已经够用没必要追着更大的模型跑。向量化之后就是构建索引。我的做法是先用 FAISS 搭一个本地索引做验证等数据量过了百万条再考虑迁移到 Milvus 或 Qdrant。核心检索参数里top-k 我一般取 4 到 8。k 太小上下文不足k 太大噪声片段会冲淡真正的答案。另外强烈建议用混合检索纯向量检索对专业术语和型号不敏感而 BM25 关键词检索能弥补这一点把那几个召回结果加权融合后的分数作为排序依据。下面是构建索引的一个极简示例帮助你理解链路from sentence_transformers import SentenceTransformer import faiss import numpy as np model SentenceTransformer(BAAI/bge-m3) chunks load_chunks(clean_docs.jsonl) # 把每个片段编码为向量 vectors np.array([model.encode(chunk) for chunk in chunks]) # FAISS内积索引配合归一化后等价于余弦相似度 index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) faiss.write_index(index, kb_index.bin)别以为生产环境就这两行代码。至少还要补三件事索引版本管理、增量更新机制、向量备份。否则文档一更新旧索引还在线上跑用户问出来的就是已经被删除的旧知识。3.4 生成链路与提示词设计把上下文窗口当成稀缺资源检索到候选片段后真正的战斗才刚开始。把片段组装成 prompt 时有一件事必须刻在脑子里上下文窗口是稀缺资源。假设你用的模型上下文上限是 8K token你一股脑把 6K 的检索片段塞进去留给模型“思考”和生成的空间就只剩 2K最后输出的内容自然会显得僵硬、细节缺失。我的分配策略是给检索片段设置一个总体积预算比如总上下文 8K 的话检索片段不超过 4K剩下的留给指令、历史对话和模型输出区。同时把用户问题放在 prompt 靠近末尾的位置避免被长段历史对话干扰。提示词模板可以长这样SYSTEM_PROMPT 你是设备售后助手。只能根据提供的文档片段回答用户问题。 如果片段中没有答案明确说根据现有资料无法回答。 引用资料时请在句末标注对应片段ID。 build_prompt f 完整文档片段如下 {formatted_chunks} 请回答用户问题{user_question} 看见上面“请标注片段ID”这个要求了吗它不是为了好看而是帮你做两件事用户能看到答案的溯源出处增强信任感你可以在后台校验模型引用的 ID 是否存在从而判断这次回答是否可能“编造来源”。这个细节我在生产项目里用过太多次它能直接抓出一批胡编乱造的回复非常管用。3.5 评测与迭代让系统持续变好的发动机RAG 上线之后你不能当甩手掌柜。它的灵魂在评估没有评估的 RAG 就是一个黑箱。我的习惯是建一个 50 到 100 条真实问题的评测集每条问题都标注标准答案和与之对应的文档片段。之后每一次改 prompt、换 embedding 模型、调切分参数都在评测集上跑一遍记录三个指标检索命中率top-k 片段里是否包含答案所在片段。生成准确率模型回答是否和标准答案一致可以用一个大模型做裁判来打分也可以用相似度工具辅助判断。引用正确率答案标注的片段 ID 是否真实存在并与答案内容吻合。迭代的收益非常可观。我之前带过一个售后问答项目光是把评测集建起来连续跑了两周回归回答正确率从 58% 提到 82%这期间没有换任何模型只做了检索参数和提示词的微调。你说评测值不值钱所以说AI 工程里最贵的东西不是 GPU而是你愿不愿意把“感觉变好了”变成“数据证明变好了”。4. 生产环境踩坑实录四个最痛的点4.1 GPU成本就像水龙头不管它就会漏水RAG 系统如果完全本地部署最大的成本项就是 GPU。可很多团队一上来就把一个大模型实例全天候运行哪怕深夜只有两个人访问卡照样烧着。满负荷 vs 空转花的钱一模一样但回报截然不同。我的策略是加一层弹性推理路由高峰时段把流量导向 GPU 上的完整版模型低谷时段转向 CPU 上的轻量小模型或者直接走云上按量计费。迁移初期不要搞复杂在 FastAPI 网关层加一个按时间窗口切换的开关把请求分流到不同推理后端就行。另外压缩 prompt token 是实打实的省钱手段。检索回来的片段如果堆了太多冗余文字可以先做一个摘要压缩再灌给生成模型成本往往能省两到三成回答质量还更高。4.2 模型输出幻觉压不住但可以圈住幻觉问题绕不开说几个我亲测有效的手段。第一个是降 temperature。很多对话场景设成 0.2 左右就足够别默认用 0.8。温度越高模型越“敢编”而知识库问答场景要的是纪律。第二个是强制引用刚才已经说过。第三个是加自校验步让模型在回答之前先判断“检索片段里是否有足够信息”。代价是多一次模型调用但能显著减少一本正经胡说八道的回复。第四个是兜底策略如果检索到的最高分段相关度分低于某个阈值直接返回“资料不足建议转人工”而不是硬着头皮生成。我的体感是幻觉不可能完全归零但产品层面一定能兜住。最简单的做法就是答案后面永远带原文链接让用户有能力去核对。AI 系统不应该替用户做最终判断而应该把判断依据交给用户。4.3 并发和延迟瓶颈往往不在大模型一个 RAG 服务并发上不去很多人第一时间会怀疑生成模型推理太慢。但真实项目里瓶颈常常出现在更隐蔽的地方每次请求都现算用户问题的 embedding然后在向量库里再查一遍。用户问题的 embedding 计算本身就要调一次小模型它和生成大模型抢显存互相拖慢。我的优化清单对问题 embedding 结果做缓存相同或相近的问题直接命中。对检索结果做 30 到 60 秒的短时缓存热点问题不用反复查库。生成接口用流式输出首字延时会显著改善用户体感会好很多。数据库连接池、HTTP 客户端连接复用这些后端基本功在 AI 工程里一个都不能丢。我做过一个对比加上问题缓存和检索缓存之后单实例 QPS 提升了两倍多首字延迟缩短了一半。这类优化见效极快不需要动模型。4.4 监控和告警AI服务最怕死得不明不白AI 服务出故障最让人崩溃的不是故障本身而是你分不清到底“模型抽风”还是“系统报错”。所以日志和监控必须从第一天就设计好。每次请求至少要记录三组信息用户问题与最终的 prompt 全文、检索到的片段 ID 列表与相关度分数、模型返回内容与耗时。有了它们排查任何问题都能回答三个核心问题用户问了什么、系统检索到了什么、模型答了什么。这三个问题几乎每次线上事故复盘都要用到。告警阈值建议按滑动平均值来设定比如近 5 分钟错误率、超时率、token 消耗趋势。不要用固定阈值线上流量波动大固定阈值要么天天误报要么等真出事的时候已经晚了一小时。5. 流程管理让AI系统不靠个人英雄主义5.1 Prompt也是代码要版本化、可测试、能回滚一个 AI 工程体系成熟与否最直接的标志就是 prompt 是否被当作代码来管理。我见过最乱的项目prompt 模板被人存在微信聊天记录里改了一版没有人记录效果变好了说不清原因变坏了也没法回退。我的建议很朴素把 prompt 模板抽成独立的文件和代码一起纳入 Git 管理。每个 prompt 文件头部写清设计目的、输入格式、重要禁忌。任何 prompt 改动都必须先在评测集上跑一遍回归通过之后才允许合并上线。这样改进以后线上出了任何问题你都能倒查是哪一次改动引入的而不是全组人凭记忆互相拷问。5.2 从Demo到可维护系统的清单化改造很多团队的 RAG 项目能跑 demo但称不上可维护的系统。我整理了一个自查清单每一条都来自真实项目里的教训有没有专职负责数据更新文档变更后多久自动同步索引有没有日志聚合出事能否在一分钟内找到当时的请求记录有没有成本统计每个模块的 token 消耗和 GPU 占用是否能按天追溯有没有回滚预案prompt 更新后效果变差能否一键切换旧版本这些事单独拎出来都不难难的是把它们变成制度化流程。我见过太多团队把 RAG 当 demo 运维白天人少还能应付晚上用户一多就开始批量超时和乱答然后全组人连夜救火。那不叫 AI 工程叫 AI 放飞自我。6. 回归工程本质我的一点个人体会写到最后我觉得真正重要的不是某一个模型、某一个框架而是“工程心态”。从零开始学 AI 工程难的不是背模型架构而是你面对一个天生带随机性的输出时仍然愿意用确定性的流程去约束它。数据清洗、评测集、版本管理、监控告警这些事都不性感但它们是 AI 系统能长期运转的真正地基。再分享一个小技巧每次迭代完一个版本录一个一分钟的演示视频把改动前后的效果放在一起对比。视频在汇报和复盘时比任何文档都有说服力也会倒逼你从“感觉变好了”过渡到“证据显示变好了”。我现在还留着三年前第一版 demo 的视频每次翻出来看都觉得当年能跑起来是奇迹。但也就是一个又一个这种不起眼的、枯燥的工程细节叠在一起才最终变成今天异常稳定的线上产品。 从零搭建AI工程体系：RAG实战与算法工程师转型指南
先说实话我最近面试了不少挂着“AI工程师”头衔的候选人简历上写满了各种模型名和框架但当我问“你怎么证明这套系统这周比上周更好用”的时候一半以上的人会沉默。这个问题暴露的是很多人根本没理解 ai-engineering 到底在干什么。跑通一个模型不是工程把模型变成稳定、可控、低成本、可迭代的产品才算工程。这篇文章算是我从零搭建 AI 工程体系的一份完整复盘。我会把算法工程师和 AI 工程师的边界讲清楚把从 Python 基础到 RAG 实战的成长路线拆开把上线后那些没人提前告诉你的坑一个个摆出来再给你能直接抄作业的方法。适合想转 AI 方向的后端开发也适合刚入行的算法新人以及被老板扔了一个 AI 项目但脑子里还没地图的团队负责人。放心我不贴大段论文公式尽量用能落地的大白话讲清楚每一步的“为什么”。1. AI工程到底是什么和跑通一个模型完全不是一回事1.1 算法岗和工程岗隔着一整条产品线我见过太多团队把算法工程师和 AI 工程师混为一谈结果项目做到一半就卡死。算法工程师的核心任务是“证明可行”在一个数据集上把某个指标刷上去验证某个模型结构是否有效。他们的产出是一份实验记录、一组权重文件、一篇研究报告。而 AI 工程师的核心任务是“交付可用”把已经证明可行的技术变成用户能稳定使用的东西要管数据、管服务、管成本、管监控、管回归测试。这两个岗位的思维模式差异很大。我常用一个比喻算法工程师是发明新菜谱的厨师AI 工程师是把菜谱变成中央厨房标准化流程的人。你当然可以既懂研发又懂生产但你的精力分配和做事方式会截然不同。后台算法同学把离线召回准确率做到 98%上线以后用户依然骂“这机器人答非所问”这种案例我见过不止一次。原因是用户的问题分布和精挑细选的测试集永远不一样离线 98% 的分数在线上可能连 60% 都不到。这就是典型的不理解 AI 工程模型能力只是系统能力的一部分数据质量、检索逻辑、提示词结构、兜底策略每一环都在决定最终用户体验。再具体一点我给你画一下两种角色的日常。算法工程师一天下来主要在研究 loss 曲线、调整超参数、洗特征。AI 工程师一天下来可能在写文档解析脚本、调向量检索参数、设计 prompt 模板的版本管理、和运维一起排查 GPU 显存泄漏。你看着都很“AI”但关注点完全不同。如果你是转行进来的你要明白行业里大量岗位说的“AI工程师”其实更接近后者。1.2 AI工程师的真实能力栈数据、模型、服务、评测很多新人学 AI 工程第一反应是“我要把 Transformer 底层写出花”。但真实项目里AI 工程师最值钱的往往不是手写模型而是另外几项不太炫酷的能力。我按重要程度排序数据工程能力数据采集、格式解析、清洗、去重、标注、质检。一个 AI 项目里人力成本最大、迭代最频繁的环节十有八九在数据侧不在模型侧。模型与算法基础不需要从零手写 Transformer但要能读懂模型卡说明、知道不同模型的适用长度、了解 temperature 和 top_p 对输出的影响、能判断什么时候该微调、什么时候该用 RAG。服务化与部署API 设计、并发控制、推理加速、镜像打包、灰度发布、监控告警。这部分能力决定了系统能不能扛住真实流量。评测与迭代建评测集、跑回归、比较不同 prompt 或不同模型版本的效果。很多团队做不好 AI 项目不是因为模型不够强而是因为“变好了还是变差了”全靠感觉。上面这个能力栈四分之三的人都低估了“评测”这一环。我后面会专门展开这里先点一句没有评测体系的 AI 系统就是一辆没有仪表盘的跑车你能开但你不知道什么时候会爆缸。为了让你更直观地对照我把常见误区也列一下能力域核心工具举例常见误区数据工程Pandas、PaddleOCR、pdfplumber、Label Studio拿到文档直接切分向量化不做清洗模型基础PyTorch、Transformers、vLLM只看榜单选最大模型不看场景成本服务化FastAPI、Docker、Nginx没做并发控制直接用同步阻塞接口评测自建评测集、模型打分、回归脚本凭人工抽查代替系统性评测2. 从零起步的技术选型和一条成长路线2.1 为什么语言和框架要先选Python很多后端同事一听说 AI第一反应就是“我要用 Java 或 Go 写一个高性能推理服务”。我的建议正好相反从零开始学 AI 工程语言先死磕 Python 就好。理由非常简单目前 AI 生态几乎全部长在 Python 上。PyTorch、Transformers、LangChain、LlamaIndex、FastAPI甚至 vLLM 的 Python 接口你都能在一小时之内把模型串起来。如果你非要一开始就用 Go 或 Java 去对接推理引擎光是 tokenizer 兼容、模型格式解析、prompt 模板管理这些事就能把你劝退。速度是不是瓶颈在这个架构下基本不是。AI 工程的性能瓶颈绝大多数在 GPU 显存带宽、推理引擎的调度效率、向量检索的召回精度这些地方不在业务语言的循环速度上。Python 负责调度和管理真正跑重活的交给 vLLM、TensorRT-LLM 这些专用引擎或者用 C 写一个独立的推理微服务。这套分工已经是行业默认范式没必要逆着来。2.2 工具链选型框架、向量数据库、推理引擎从零搭一套 AI 系统最核心的选型点有四块模型框架、向量存储、推理服务和业务服务框架。以我自己的实践经验每个位置都有相对稳妥的选择核心逻辑不是“哪个新用哪个”而是“稳定、生态好、团队学得会”。组件我建议的选项备选项选择理由模型框架PyTorch无Transformers/HuggingFace 生态默认基于它向量存储起步用 FAISS数据量大换 Milvus 或 QdrantElasticsearch 自带向量能力FAISS 够简单百万级数据轻松扛住推理服务vLLMOllama、TensorRT-LLM、ONNX RuntimevLLM 吞吐高、兼容性好社区活跃业务框架FastAPIFlask、Gradio自带 OpenAPI 文档写起来快选型有一个极易踩的坑过早引入重量级组件。我见过一个几万条文档的知识库项目团队第一周就上了分布式向量数据库集群三个人维护了两周还没把数据灌进去。其实这个量级一个 FAISS 本地索引加一份 JSON 快照就够了效果一样运维成本低一个数量级。你要记住选型帮你解决的是当前瓶颈不是提前透支未来的麻烦。2.3 三步爬坡路线从本地脚本到线上服务我给零基础读者和半路转行的朋友画过一条路线叫“三步爬坡法”。按这个顺序走成长曲线最平滑每个阶段都能看到成果。第一步本地跑通一个开源模型。到 HuggingFace 上下一个 Qwen 或 Llama 的小尺寸版本用 Transformers 库加载起来让它复述一句你写的话。整个过程里你会自然理解 tokenizer 怎么把文本变成 token模型怎么加载权重输出怎么采样解码。这一步不要贪大一个 1B 到 7B 之间的模型足够建立体感。第二步把它用 FastAPI 包成一个 HTTP 接口。给服务加一个全局并发控制防止多个请求同时撞到同一个推理进程里。这一步的核心是理解“模型是有状态的接口必须是无状态的”这个工程事实。你还需要学会如何在进程启动时加载模型而不是每次请求都重新加载一次。第三步给它加记忆和工具。试试给服务接一个向量检索数据库让它能基于你自己的文档回答问题。做到这一步你就摸到了 RAG 的门口这也是我认为目前 AI 工程落地率最高、性价比最好的架构。后面我会专门用一个章节把 RAG 的完整搭建过程拆给你看。3. 手把手拆解一个RAG知识库问答系统3.1 需求分解与架构设计先想清楚再写代码我挑一个最常见的场景来讲企业内部售后知识库问答。比如一家卖设备的企业库里躺着几百份产品说明书、故障手册和维修记录售后客服每天要重复回答大量“设备故障代码怎么解决”之类的问题。我们要做的就是让售前人员或最终用户直接提问系统自动从文档库中检索相关内容生成准确回答并且附上原文编号方便追溯。这个需求第一眼感觉“接一个对话模型就行”但一拆就发现问题不少。你至少需要处理五件事文档格式五花八门有扫描 PDF有 Word有带复杂表格的 Excel文档会定期更新旧的知识不能一直占着回答必须可追溯否则客服不敢采纳不同的用户问题风格差异很大有人问“机器报 E001 错怎么处理”有人问“怎么解决设备启动后又立刻停机”。每一件事对应系统里的一个模块文档解析、切分、向量化、存储、检索、生成、引用溯源。在架构上我建议把系统拆成两条链路坚决不要把所有的逻辑堆在一个脚本里。离线数据链路原始文档 → 格式解析 → 清洗 → 切分 → 向量化 → 索引构建 → 索引版本管理。在线推理链路用户提问 → 问题向量化 → 混合检索 → 候选片段排序 → prompt 组装 → 大模型生成 → 引用校验 → 输出返回。两条链路分开的最大好处是互不干扰你更新文档索引的时候在线服务不用重启在线链路出了性能问题你也不会被数据解析的逻辑干扰排查思路。3.2 文档解析和清洗最容易被忽视的起跑线很多 RAG 项目翻车不是模型选错了而是“文档没洗干净”。企业文档是重灾区扫描 PDF 里文字是图片Word 里嵌着表格Excel 明明是结构化数据却被绕来绕去的注释搞得很难解析。这些问题若不处理检索时就会出现片段错位、信息残缺、表格内容完全走样。我现在的处理流程固定为四步格式摸底先统计你手上有多少种文档格式各自占比。这一步看似多余但决定了你后面人力怎么分配。文本提取扫描件用 OCR我主要用 PaddleOCR中文识别效果比很多老牌开源工具好数字化 PDF 用 pdfplumber 或 PyMuPDF各有用武之地优先保表格和段落结构。清洗去掉页眉页脚、页号、重复标题、无关声明。表格在清洗过程中统一转成 Markdown 表格避免后续模型和切分算法丢掉结构。语义切分按标题层级和段落边界切不是简单按字符数硬切。切分这一步特别值得说。固定长度切分比如每 512 个字符一刀切过去看着省事但频繁地把话题从“设备安装步骤”切到“故障代码表”检索的时候会莫名其妙召回一些语义断裂的片段。我现在的做法是先用 Markdown 标题把文档切成大块再把大块内按段落、列表项切成长度 200 到 400 字的小片段相邻片段之间保留 30 到 50 个字的重叠这样既能保证语义完整又能照顾到跨段落的上下文衔接。3.3 向量化与索引构建选对Embedding模型检索就赢了一半文档切好之后要做 embedding 向量化。中文场景下我很推荐开源的 BAAI/bge-m3效果不错且能本地部署维度是 1024不依赖云端接口也能跑。如果你的团队不想维护 embedding 模型直接用云厂商的向量化接口也行1536 维或 1024 维都常见。这里提醒一句维度不是越高越好。高维度带来更高的存储成本和检索耗时如果 bge-m3 的 1024 维已经够用没必要追着更大的模型跑。向量化之后就是构建索引。我的做法是先用 FAISS 搭一个本地索引做验证等数据量过了百万条再考虑迁移到 Milvus 或 Qdrant。核心检索参数里top-k 我一般取 4 到 8。k 太小上下文不足k 太大噪声片段会冲淡真正的答案。另外强烈建议用混合检索纯向量检索对专业术语和型号不敏感而 BM25 关键词检索能弥补这一点把那几个召回结果加权融合后的分数作为排序依据。下面是构建索引的一个极简示例帮助你理解链路from sentence_transformers import SentenceTransformer import faiss import numpy as np model SentenceTransformer(BAAI/bge-m3) chunks load_chunks(clean_docs.jsonl) # 把每个片段编码为向量 vectors np.array([model.encode(chunk) for chunk in chunks]) # FAISS内积索引配合归一化后等价于余弦相似度 index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) faiss.write_index(index, kb_index.bin)别以为生产环境就这两行代码。至少还要补三件事索引版本管理、增量更新机制、向量备份。否则文档一更新旧索引还在线上跑用户问出来的就是已经被删除的旧知识。3.4 生成链路与提示词设计把上下文窗口当成稀缺资源检索到候选片段后真正的战斗才刚开始。把片段组装成 prompt 时有一件事必须刻在脑子里上下文窗口是稀缺资源。假设你用的模型上下文上限是 8K token你一股脑把 6K 的检索片段塞进去留给模型“思考”和生成的空间就只剩 2K最后输出的内容自然会显得僵硬、细节缺失。我的分配策略是给检索片段设置一个总体积预算比如总上下文 8K 的话检索片段不超过 4K剩下的留给指令、历史对话和模型输出区。同时把用户问题放在 prompt 靠近末尾的位置避免被长段历史对话干扰。提示词模板可以长这样SYSTEM_PROMPT 你是设备售后助手。只能根据提供的文档片段回答用户问题。 如果片段中没有答案明确说根据现有资料无法回答。 引用资料时请在句末标注对应片段ID。 build_prompt f 完整文档片段如下 {formatted_chunks} 请回答用户问题{user_question} 看见上面“请标注片段ID”这个要求了吗它不是为了好看而是帮你做两件事用户能看到答案的溯源出处增强信任感你可以在后台校验模型引用的 ID 是否存在从而判断这次回答是否可能“编造来源”。这个细节我在生产项目里用过太多次它能直接抓出一批胡编乱造的回复非常管用。3.5 评测与迭代让系统持续变好的发动机RAG 上线之后你不能当甩手掌柜。它的灵魂在评估没有评估的 RAG 就是一个黑箱。我的习惯是建一个 50 到 100 条真实问题的评测集每条问题都标注标准答案和与之对应的文档片段。之后每一次改 prompt、换 embedding 模型、调切分参数都在评测集上跑一遍记录三个指标检索命中率top-k 片段里是否包含答案所在片段。生成准确率模型回答是否和标准答案一致可以用一个大模型做裁判来打分也可以用相似度工具辅助判断。引用正确率答案标注的片段 ID 是否真实存在并与答案内容吻合。迭代的收益非常可观。我之前带过一个售后问答项目光是把评测集建起来连续跑了两周回归回答正确率从 58% 提到 82%这期间没有换任何模型只做了检索参数和提示词的微调。你说评测值不值钱所以说AI 工程里最贵的东西不是 GPU而是你愿不愿意把“感觉变好了”变成“数据证明变好了”。4. 生产环境踩坑实录四个最痛的点4.1 GPU成本就像水龙头不管它就会漏水RAG 系统如果完全本地部署最大的成本项就是 GPU。可很多团队一上来就把一个大模型实例全天候运行哪怕深夜只有两个人访问卡照样烧着。满负荷 vs 空转花的钱一模一样但回报截然不同。我的策略是加一层弹性推理路由高峰时段把流量导向 GPU 上的完整版模型低谷时段转向 CPU 上的轻量小模型或者直接走云上按量计费。迁移初期不要搞复杂在 FastAPI 网关层加一个按时间窗口切换的开关把请求分流到不同推理后端就行。另外压缩 prompt token 是实打实的省钱手段。检索回来的片段如果堆了太多冗余文字可以先做一个摘要压缩再灌给生成模型成本往往能省两到三成回答质量还更高。4.2 模型输出幻觉压不住但可以圈住幻觉问题绕不开说几个我亲测有效的手段。第一个是降 temperature。很多对话场景设成 0.2 左右就足够别默认用 0.8。温度越高模型越“敢编”而知识库问答场景要的是纪律。第二个是强制引用刚才已经说过。第三个是加自校验步让模型在回答之前先判断“检索片段里是否有足够信息”。代价是多一次模型调用但能显著减少一本正经胡说八道的回复。第四个是兜底策略如果检索到的最高分段相关度分低于某个阈值直接返回“资料不足建议转人工”而不是硬着头皮生成。我的体感是幻觉不可能完全归零但产品层面一定能兜住。最简单的做法就是答案后面永远带原文链接让用户有能力去核对。AI 系统不应该替用户做最终判断而应该把判断依据交给用户。4.3 并发和延迟瓶颈往往不在大模型一个 RAG 服务并发上不去很多人第一时间会怀疑生成模型推理太慢。但真实项目里瓶颈常常出现在更隐蔽的地方每次请求都现算用户问题的 embedding然后在向量库里再查一遍。用户问题的 embedding 计算本身就要调一次小模型它和生成大模型抢显存互相拖慢。我的优化清单对问题 embedding 结果做缓存相同或相近的问题直接命中。对检索结果做 30 到 60 秒的短时缓存热点问题不用反复查库。生成接口用流式输出首字延时会显著改善用户体感会好很多。数据库连接池、HTTP 客户端连接复用这些后端基本功在 AI 工程里一个都不能丢。我做过一个对比加上问题缓存和检索缓存之后单实例 QPS 提升了两倍多首字延迟缩短了一半。这类优化见效极快不需要动模型。4.4 监控和告警AI服务最怕死得不明不白AI 服务出故障最让人崩溃的不是故障本身而是你分不清到底“模型抽风”还是“系统报错”。所以日志和监控必须从第一天就设计好。每次请求至少要记录三组信息用户问题与最终的 prompt 全文、检索到的片段 ID 列表与相关度分数、模型返回内容与耗时。有了它们排查任何问题都能回答三个核心问题用户问了什么、系统检索到了什么、模型答了什么。这三个问题几乎每次线上事故复盘都要用到。告警阈值建议按滑动平均值来设定比如近 5 分钟错误率、超时率、token 消耗趋势。不要用固定阈值线上流量波动大固定阈值要么天天误报要么等真出事的时候已经晚了一小时。5. 流程管理让AI系统不靠个人英雄主义5.1 Prompt也是代码要版本化、可测试、能回滚一个 AI 工程体系成熟与否最直接的标志就是 prompt 是否被当作代码来管理。我见过最乱的项目prompt 模板被人存在微信聊天记录里改了一版没有人记录效果变好了说不清原因变坏了也没法回退。我的建议很朴素把 prompt 模板抽成独立的文件和代码一起纳入 Git 管理。每个 prompt 文件头部写清设计目的、输入格式、重要禁忌。任何 prompt 改动都必须先在评测集上跑一遍回归通过之后才允许合并上线。这样改进以后线上出了任何问题你都能倒查是哪一次改动引入的而不是全组人凭记忆互相拷问。5.2 从Demo到可维护系统的清单化改造很多团队的 RAG 项目能跑 demo但称不上可维护的系统。我整理了一个自查清单每一条都来自真实项目里的教训有没有专职负责数据更新文档变更后多久自动同步索引有没有日志聚合出事能否在一分钟内找到当时的请求记录有没有成本统计每个模块的 token 消耗和 GPU 占用是否能按天追溯有没有回滚预案prompt 更新后效果变差能否一键切换旧版本这些事单独拎出来都不难难的是把它们变成制度化流程。我见过太多团队把 RAG 当 demo 运维白天人少还能应付晚上用户一多就开始批量超时和乱答然后全组人连夜救火。那不叫 AI 工程叫 AI 放飞自我。6. 回归工程本质我的一点个人体会写到最后我觉得真正重要的不是某一个模型、某一个框架而是“工程心态”。从零开始学 AI 工程难的不是背模型架构而是你面对一个天生带随机性的输出时仍然愿意用确定性的流程去约束它。数据清洗、评测集、版本管理、监控告警这些事都不性感但它们是 AI 系统能长期运转的真正地基。再分享一个小技巧每次迭代完一个版本录一个一分钟的演示视频把改动前后的效果放在一起对比。视频在汇报和复盘时比任何文档都有说服力也会倒逼你从“感觉变好了”过渡到“证据显示变好了”。我现在还留着三年前第一版 demo 的视频每次翻出来看都觉得当年能跑起来是奇迹。但也就是一个又一个这种不起眼的、枯燥的工程细节叠在一起才最终变成今天异常稳定的线上产品。