AI工程从零到落地：RAG与Agent实战指南

这两年我经常被问到一个问题：想系统学 AI 工程，到底该从哪里下手？网上的东西要么是零散的模型教程，要么是厂商文档改编的营销稿，真正能从头讲到落地、把每一步为什么这么设计讲清楚的材料太少了。我自己带团队招人、带新人、做项目评审时也反复被同一个问题卡住——很多人能跑通一个 Demo，但讲不清楚一个完整的 AI 应用系统是怎么被设计出来、评估出来、部署上去的。这份 "ai-engineering-from-scratch" 就是我把自己过去几年做 AI 工程落地的经验整理成的一条完整路径，核心目的就一个：让完全没接触过 AI 工程、但有一定开发基础的人，能顺着一条清晰的主线，从零搭出一个可维护、可评估、能上线的 AI 应用系统。

这篇文章会覆盖 AI 工程的整体思路、技术栈选型、完整的 RAG 实战、Agent 开发、评估调优与部署，以及大量我在实际项目中踩过的坑。最适合三类人：准备转行做 AI 应用开发的工程师、已经在做传统后端想拓展 AI 能力的开发者，以及刚做完几个模型调用小项目、想往工程化方向走的初学者。那些只会念 prompt、调 API 的"教程式经验"我不会讲，这里只讲能真正落地的工程方法。

1. AI工程的核心边界：不止是"调模型"

1.1 AI工程和传统机器学习开发到底差在哪

很多人一开始就把 AI 工程等同于"搞模型"，这个理解会让人走很多弯路。传统机器学习强调的是数据清洗、特征工程、模型训练、指标调优这条线；而 AI 工程，尤其是大模型时代的 AI 工程，重心已经从"训练模型"转移到了"用模型构建软件系统"。你更需要的是一套把大模型嵌入到业务链路中的系统工程能力，包括需求拆解、上下文工程、检索增强、工具调用、评估体系、成本控制和部署运维。

打个比方：传统 ML 像是自己种菜、自己做饭，菜的口味好坏完全取决于种的过程；而今天的 AI 工程更像是把一家中央厨房提供的半成品食材，按照客户需求设计成一道道稳定出餐的菜品。你不再控制食材怎么生长，但你需要设计菜单、控制火候、保证每一桌稳定交付。这就是核心思维的转变。

正因为这个变化，AI 工程的技术栈也完全不同了。典型的技术组件包括大模型 API 网关、向量数据库、编排框架（如 LangChain、LlamaIndex 或自研 pipeline）、缓存层、评估数据集、观测监控系统。你不再纠结于 loss 曲线，而是纠结于上下文怎么组织、检索质量怎么提升、工具调用怎么规划、延迟和成本怎么平衡。

1.2 从零开始的完整技能地图

先给一张清晰的技能地图，照着这个地图走，你就不会迷失在层出不穷的新名词里。

这张地图不需要一步到位，但方向感很重要。我看到的大量半途而废的案例，都是因为一上来就学 Agent、学各种花哨的框架，结果基础概念没搞懂，项目根本没办法落地。正确的顺序应该是：先打通一个最简单的"模型调用闭环"，再逐步叠加检索、工具调用、评估、部署。

2. 技术选型与基础环境：把地基打牢

2.1 开发语言和运行环境怎么选最稳

语言这块没什么好争议的，Python 是 AI 工程的事实标准。原因不只是生态成熟，更重要的是 AI 相关的 SDK、数据处理库、评估工具全部优先支持 Python。如果你原来是做 Java 或者 Go 的，也没关系，我建议你不要纠结"要不要重新学 Python"，直接上手，一两个星期就能达到够用的水平。

Python 环境管理上，我强烈建议从一开始就别图省事。无论你是 macOS、Windows 还是 Linux，先把 pyenv 这类版本管理工具装好，再配合 venv 或 poetry 创建虚拟环境。很多新手拿到项目第一件事就是pip install全局装包，然后过几个月发现自己环境乱到无法复现。记住一条原则：每个工程必须有独立的依赖环境，且依赖版本必须锁定。项目里至少要有requirements.txt或pyproject.toml，最好用pip-tools或poetry做版本锁定。

我自己在 Windows 上也踩过不少坑，尤其是一些依赖了 C 扩展的库（比如某些向量计算相关的包）在 Windows 上安装容易出问题。我的建议是：如果你有选择权，尽量在 Linux 或 macOS 环境下做开发；如果只有 Windows，优先用 WSL2，很多底层兼容性问题能直接绕过去。这个建议听着不起眼，但我见过太多新手在环境配置上浪费了一个星期还没有真正的进展。

2.2 核心工具的定位和取舍逻辑

工具非常多，但你只需要理解每类工具解决什么问题，然后按需求选型，不用盲目追新。

先说大模型。对工程师来说，模型就是"智力API"。你需要关注的无非是上下文长度、价格、推理速度和输出质量。不要迷信"最强的模型一定最好"，很多时候一个小模型配合好的提示词工程和检索，效果远超直接用大模型裸跑，成本和延迟还低得多。项目初期建议先用成熟厂商的 API 跑通链路，不要一开始就琢磨本地部署开源模型，那会分散大量精力。

向量数据库的选择也有讲究。当前主流有开源方案如 Milvus、Qdrant、Chroma，也有云服务如 Pinecone。我的建议是：项目原型阶段用 Chroma 或 Qdrant 的本地模式，图个省事；到了需要正式部署、数据量上来之后，迁到 Milvus 或云服务。不要因为某个数据库热度高就无脑选，要预估你的数据规模。比如几万条文档用 Redis 的搜索模块都能扛，但到了百万级向量，你就必须考虑分片和索引策略了。

编排层工具（LangChain、LlamaIndex 等）的争论最大。我的真实体验是：这些框架适合快速原型验证，但如果你进入生产阶段，大概率要自己封装一层。原因在于框架抽象层次高，遇到问题你和框架之间隔着一层黑盒，调试成本极高。我见过太多团队用 LangChain 做 Demo 很爽，一上线就各种奇怪问题，最后不得不重写。这不算框架的问题，而是工程化必然路径。你要具备的能力是：读懂框架源码，或者自己实现一个迎合你需求的简洁 pipeline。

3. 第一个实战项目：从零搭建知识库问答系统

3.1 项目需求分析与整体架构设计

想让 AI 工程的知识点落地，最直观的方式就是做一个知识库问答系统，也就是常说的 RAG 应用。我建议任何人学 AI 工程，第一个完整项目都做这个，因为它覆盖了整个链路：数据处理、向量检索、提示词工程、评估优化，难度适中，价值感强。

需求定义清晰一点：给你一堆内部文档或产品手册，用户用自然语言提问，系统从文档中找到相关答案并组织成流畅回复。注意一个关键点——不只是"找到并返回原文"，而是"理解问题、检索证据、组织答案"，有推理和整合的过程。

整体架构分成离线构建和在线推理两部分。离线部分是文档加载、清洗、切分、向量化、写入向量库；在线部分是问题向量化、检索候选片段、重排、组装上下文、调用大模型生成答案。理解这个分层特别重要：离线部分做得好不好直接影响检索上限，在线部分做得好不好影响最终回答质量。很多人一上来就调 prompt，结果检索抓回来一堆无关片段，怎么都不可能答好。

3.2 文档加载、清洗与切分的实操细节

文档预处理是整个 RAG 里最容易被低估的环节。原始文档格式千奇百怪：PDF、Word、Markdown、HTML、扫描件。PDF 在工程上是个大坑，纯文本 PDF 可以直接抽取，但扫描件需要 OCR，表格和数据密集型文档抽取难度更大。我之前做过的项目里，光一个 PDF 表格解析就花了两三天。

切分策略是最影响检索质量的技术点。粗粒度切分（比如每 2000 token 一段）能保证语义完整性，但检索粒度太粗，经常把不相关的内容混进来；细粒度切分（比如每 200 token 一段）检索更精确，但上下文碎片化，可能把关键信息切断。实操里建议先按文档结构切，比如 Markdown 的章节、PDF 的标题层级，再在每个章节内按固定窗口滑动切分，同时加一些 overlap，比如相邻片段重叠 50 到 100 个字符，这样能极大缓解信息断层的问题。

每种文档类型最好单独写一段预处理逻辑，而不是用一个通用 loader 一把梭。我自己常用的做法是写一个 parser registry，按文件扩展名分发到不同解析器，每个解析器输出统一结构的 Document 对象，包含文本内容和元数据（来源、页码、章节路径）。元数据非常重要，不仅用于检索后定位引用来源，还能在过滤阶段发挥作用。很多人忽略元数据，到了做引用溯源的时候才发现后悔莫及。

3.3 向量化、检索与重排序的完整实现

向量化方案选型，推荐用专门的 Embedding 模型，而不是自己训练或随便拿一个别的模型代替。国内可用 BGE、M3E 系列，国外常用 OpenAI 的 text-embedding-3-small 或 Cohere 的 embed 系列。不同 Embedding 模型的维度、语义匹配能力、多语言支持都有差异，建议在少量验证集上快速做一轮对比再定。

向量数据库选型上，原型阶段直接用 Qdrant 的本地模式会很顺手，因为它的 Python 客户端接口清晰，支持 filter 和 payload 元数据查询。实际写入流程如下：拿到上面切好的 Document 后，逐段调用 Embedding 接口生成向量，然后把向量和 metadata 一起写入 Collection。这里有一个性能细节：很多 Embedding 接口有 QPS 限制，批量写的时候注意控制并发度，并做好失败重试和进度断点记录，否则几万段文本跑到一半断掉，要从头再来，非常浪费时间。

检索不能只看向量相似度。我强烈建议在初始检索之后加一层重排。原因是向量相似度在语义召回上表现优秀，但在精确匹配和相关性排序上不够锐利。可以先用向量检索取出 Top 50 候选，再用一个重排模型（比如 BGE-Reranker 或 Cohere Rerank）对候选做精排，取 Top 5 进上下文。这个改动对回答质量提升显著，代价是多了一次模型调用和几十毫秒延迟。生产环境里，这个投入非常值得。

3.4 提示词组织与回答生成的工程细节

RAG 的最终生成质量不仅取决于模型能力，更取决于你如何组织上下文。我见过一种最懒的写法，就是把 Top 5 片段拼在一起直接塞给模型问"根据以下内容回答问题"，这种写法效果极不稳定。

一个更工程化的提示词模板至少包含四个部分：角色与任务说明、回答规则与边界、引用证据的原文、用户的具体问题。角色说明告诉模型"你是一个基于内部知识库的问答助手，只依据提供的上下文回答"；回答规则里加上"如果上下文中没有相关信息，请明确说不知道，不要编造"；证据部分用清晰的 XML 式分隔符包起来，并附上每段证据的来源编号；最后是用户问题。输出格式上，建议用结构化输出，让模型返回包含 answer 和 citations 的 JSON，方便后续程序直接解析和渲染引用来源。

在模型选择上，如果知识库领域比较垂直，优先考虑一个性价比高的模型，配合提示词工程。我自己常用的配置是：入口用中等参数模型（比如 7B~14B 级别的国产开源模型或者中价位 API 模型），关键链路配上重排模型。整套链路跑通之后，你可以测一测不同模型在同一套 RAG 链路上的表现差异——经常有惊喜，便宜模型在好检索和好提示词加持下效果并不差。

4. Agent开发：让模型会用工具、能干活

4.1 从RAG到Agent的本质差异

RAG 解决的是"从知识里找答案"，Agent 解决的是"把事情做完"。区别在于系统是否具备调用外部工具、主动规划任务的能力。AI 工程做到这个阶段，你面对的不再是一条静态的处理链路，而是一个循环结构：模型根据当前目标生成下一步动作，调用工具，观察结果，再生成下一轮动作。这就是 Agent 的核心理念。

这个概念听起来高级，但工程化以后你会发现，它其实是在"模型能力"和"系统控制力"之间找平衡。模型本身很有弹性，但如果你毫无约束地让它自由发挥，生产系统会非常难控。所以我在工程上做了一个"管制的 Agent"路线：定义清晰的工具集合、限制每一步可执行的范围、加入校验反馈环节、设置最大迭代次数。这比完全让模型自由规划要可靠得多，也是业界的共识方向。

4.2 工具定义与执行循环的实操要点

实现一个工程化的 Agent，第一步是把工具定义清楚。每个工具都要有一个名字、一段功能描述、一个参数 Schema，我们要让模型理解这个工具是干什么的、应该怎么调用。这里有个实操技巧：工具描述要写"何时使用"和"何时不使用"，比写"能做什么"更有用。因为模型在选择工具时，本质是在做语义匹配，描述越贴近用户问题的表达习惯，选择准确率越高。

第二步是执行循环的工程实现。推荐先参考 ReAct 模式：思考（Thought）→ 行动（Action）→ 观察（Observation）→ 再思考。但在 API 型大模型上，我们一般不直接让模型输出自由的 Thought 文本，而是通过函数调用接口直接输出结构化动作指令，这样可以省去冗长的中间推理文本，还能显著降低延迟成本。循环结构的伪代码如下，方便你快速理解：

for step in range(max_steps): response = model.call(messages, tools=tool_definitions) if response.tool_call: tool_result = execute_tool(response.tool_call) messages.append(tool_result) else: return response.text

循环必须设置 max_steps，一般 5 到 8 步就足够，不要无限跑。另外我强烈建议做"步骤缓存"：如果某一步的工具返回结果命中缓存，直接复用之前的输出，不再调用模型。很多 Agent 项目上线之后成本失控，就是因为没有缓存和成本护栏。

4.3 什么场景真的需要Agent

这是一个非常值得冷静思考的问题。我在评审项目时，经常看到有人为了用 Agent 而用 Agent。一个固定流程的多步骤任务，用代码写一个确定性 pipeline 就能解决，偏偏要交给模型动态规划，结果延迟高、出错多、还不好调试。

真正适合 Agent 的场景有两个特点：一是任务路径不确定，比如用户输入多样化，无法预先枚举所有步骤顺序；二是需要根据中间结果做出动态决策，比如客服工单分诊、复杂的资料调研、代码仓库修复任务。而像"根据表单内容生成一段摘要"这种任务，用固定 prompt 就解决了，完全不需要 Agent。

即便决定用 Agent，也要从"简单 Agent"起步。不要一开始就上多智能体协同，那是工程复杂度爆炸的起点。先做单个 Agent 配合三到五个工具，跑通之后再考虑拆分角色。我在一个复杂项目里做过四五个智能体的协作框架，维护成本和错误定位难度是指数级上升的，没有充分的理由，尽量别玩这么多花活。

5. 评估、调优与部署：从Demo到系统

5.1 离线评估的构建方法

很多 AI 应用最后没法上线，问题不在功能开发，而在没有一套可靠的评估体系。没有评估，你就没有办法判断改动之后系统是变好了还是变坏了。我见过太多团队凭"感觉回答效果不错"上线，等用户反馈问题才回头找原因，非常被动。

离线评估要从数据集开始。针对你的业务场景，整理 50 到 200 条有代表性的问题，每条问题配上理想答案或用例来源。这个工作量没有捷径，但可以迭代：先让模型生成初版回答，人工修正并标注，积累成种子集。评估指标上，传统指标如精确匹配、BLEU 对开放生成任务意义不大，至少有三种更实用的评估方法：检索质量评估看召回率、命中率，引用准确率看生成答案引用的片段是否真能支撑结论，端到端回答质量则可以用 LLM-as-Judge 的方式。所谓 LLM-as-Judge，就是用另一个模型对回答打分，评估维度包括忠实度、完整性、相关性，这种方法虽然不够完美，但规模化评估效率远高于人工。

我在实践中会把评估做成自动化的回归测试：任何一次 prompt 修改、检索参数调整，都跑一遍评估集，对比基准版本的分数，用分数变化来决定是否上线。这套机制要早建，不要等问题多起来再做，否则后面每次改动都是盲人摸象。

5.2 在线监控与日志怎么设计

离线评估管的是"应该变好"，在线监控管的是"实际表现"。AI 应用和传统工程系统的监控有一个显著差异：你不仅需要监控延迟、错误率，还要监控"回答质量维度"的指标。

日志设计是最基本也最重要的环节。每条请求至少要记录：输入问题、检索到的候选片段和得分、重排结果、最终进入上下文的片段、模型返回的完整输出、Token 消耗（拆分输入输出）、延迟（分阶段记录）。有了这些日志，你才能在问题发生时做完整的复盘。没有检索日志和提示词日志，你永远不知道问题是出在检索还是出在生成。

在此基础上，可以做两个体验层的监控指标：无引用回答率，即回答中没有附上任何来源的比例，这个值偏高通常说明检索失效；负面反馈率，即在产品端设置点赞/点踩或"回答不满意"入口，直接收集用户信号。这两个指标比任何离线评估都更贴近用户的真实感受。

5.3 部署实战与成本控制

部署层面，我的推荐组合是 FastAPI 封装应用服务，Docker 容器化，配合 Nginx 或网关做统一入口。为什么选 FastAPI？性能和类型支持都很好，而且天然适配异步大模型调用。在容器化之前，先把应用配置抽离成环境变量，模型 Key、数据库地址、向量库地址不要写死在代码里。

大模型 API 的调用方式在国内生产环境里要注意一点，尽量选择服务端调用而不是客户端直连，这样你的密钥不会暴露给前端。服务端再配一个简单的缓存层，常见的做法是使用语义缓存，就是判断两个问题是否语义相似，完全相同的语义直接命中之前的回答。这个优化能省掉大量重复调用成本，尤其适合面向 C 端的客服问答场景。

成本控制要和模型选型结合起来。我先列一下常见的成本优化手段：入口主模型选择价格低但能力够用的档位，特别难的问题再升级到更强模型；控制上下文长度，不要让不相干的检索片段填充 token；使用输出 token 约束，限制回答长度，避免模型长篇大论；低峰期任务走批量或异步模式，分摊成本。这些手段叠加起来，往往能把单次问答成本降到原来的三分之一甚至更低，代价只是多花一点工程时间。

部署完成不代表结束。你的 AI 应用上线只是开始，真正的工作在上线之后——持续收集用户反馈、分析失败案例、迭代评估集、每周更新检索索引。我见过太多项目上线之后就把精力转到新项目，老系统效果慢慢退化，最后被用户弃用。一个 AI 系统如果没有专门的维护周期，它的质量曲线大概率是往下的。

6. 常见问题与排查技巧实录

6.1 模型幻觉和"答非所问"怎么排查

幻觉问题首选的排查方向不是模型，而是上下文。你先打开日志看这一条回答实际用到了哪些检索片段，如果答案内容和引用片段对不上，那是生成阶段的问题，你可以在提示词里加重"只依据上下文"的约束，并让模型在证据不足时直接回答不知道。如果答案是依据上下文生成的，但是上下文本身就不对，那是检索阶段的问题，要从切分策略和重排策略上入手。

一个非常有效的防幻觉技巧是"答案引用必带出处"：强制模型在输出回答时带上引用编号，系统在后端校验引用的片段是否真实存在，回答内容是否和引用的片段一致。这一步放在提示词层和代码层双保险，能拦截掉大部分编造式回答，在实践中极大提升用户信任感。

6.2 检索效果差，改哪里最有效

检索召回不到相关内容时，不要急着换 Embedding 模型，先检查文本切分粒度。最常见的问题是一个长文档被切得过大，语义混杂，一个文档块里有一半是不相关的内容，向量检索标记出来的相似度被稀释。先把切分长度调小到 300~500 token，overlap 加上 50 到 100，再测一轮。

另一个常见问题是用户问题的表述和文档表述差异太大，比如文档里写"报销流程"，用户问"我出差花的钱怎么报"，向量检索往往无法直接命中。处理办法：给每个知识片段附加别名元数据（如"报销=出差费用=报账"），或者在生成查询向量时先用一个小模型做一次"查询改写"，把口语化问题转成书面化检索词。这个"查询改写"步骤对检索命中率的提升，比换模型还明显。

6.3 链路性能瓶颈和成本失控

回答太慢，优先检查是不是把太多候选片段喂给了模型。输入 token 越多，首字延迟越长，成本也越高。解决方向是快速缩小候选集：先用向量检索粗取，再用重排精取 Top 3 到 5，保证上下文控制在 1500~2500 token 以内。另一个性能瓶颈往往是 Embedding 接口的同步调用串行阻塞了整条链路，改成并发或异步之后，响应时间经常能下降到原来的三分之一。

成本失控的场景，我见过的最多是 Agent 的多轮工具调用叠加了重复的向量化和模型调用。排查方式是给日志里每一步工具调用都打点记录 token 消耗，找到消耗大户后针对性地加缓存。建议在工程开始时就在模型调用层统一封装一个"带缓存、带用量统计"的接口，而不是所有代码直接调用 SDK——这个封装会在后续排查中省下大量心力。

从我带项目的实际经验看，AI 工程的本质不是炫技，而是一套严谨的工程方法。从一个 RAG 项目起步，逐步引入 Agent 能力，每加一层都配上评估和监控，这条路看起来慢，实际上是最稳的一步到位。如果你正准备从零开始，我的建议就是照着这条路径，先做一个小而完整的项目。排名第一的体验门槛不是难，而是"开始写第一行代码"这一下，迈过去后面都不太难。