这两年我经常被问到一个问题想系统学 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 从零开始的完整技能地图先给一张清晰的技能地图照着这个地图走你就不会迷失在层出不穷的新名词里。技能模块核心能力要求主要工具/技术方向语言与编程基础Python 熟练、异步编程、类型标注Python 3.10、pydantic大模型应用基础理解 API 调用、上下文窗口、token 计算OpenAI SDK、Anthropic SDK、国内大模型 API提示词工程系统提示词设计、思维链、结构化输出少样本示例、JSON Schema、函数调用检索增强RAG文本切分、向量化、相似度检索、重排向量数据库、Embedding 模型、RerankerAgent 开发工具定义、任务规划、执行循环Function Calling、ReAct、多智能体编排评估与调优离线评估集构建、在线监控、多维指标分析评估框架、LLM-as-Judge、日志分析部署与运维API 服务化、容器化、弹性伸缩、成本优化FastAPI、Docker、Kubernetes、网关这张地图不需要一步到位但方向感很重要。我看到的大量半途而废的案例都是因为一上来就学 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, toolstool_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 tokenoverlap 加上 50 到 100再测一轮。另一个常见问题是用户问题的表述和文档表述差异太大比如文档里写报销流程用户问我出差花的钱怎么报向量检索往往无法直接命中。处理办法给每个知识片段附加别名元数据如报销出差费用报账或者在生成查询向量时先用一个小模型做一次查询改写把口语化问题转成书面化检索词。这个查询改写步骤对检索命中率的提升比换模型还明显。6.3 链路性能瓶颈和成本失控回答太慢优先检查是不是把太多候选片段喂给了模型。输入 token 越多首字延迟越长成本也越高。解决方向是快速缩小候选集先用向量检索粗取再用重排精取 Top 3 到 5保证上下文控制在 1500~2500 token 以内。另一个性能瓶颈往往是 Embedding 接口的同步调用串行阻塞了整条链路改成并发或异步之后响应时间经常能下降到原来的三分之一。成本失控的场景我见过的最多是 Agent 的多轮工具调用叠加了重复的向量化和模型调用。排查方式是给日志里每一步工具调用都打点记录 token 消耗找到消耗大户后针对性地加缓存。建议在工程开始时就在模型调用层统一封装一个带缓存、带用量统计的接口而不是所有代码直接调用 SDK——这个封装会在后续排查中省下大量心力。从我带项目的实际经验看AI 工程的本质不是炫技而是一套严谨的工程方法。从一个 RAG 项目起步逐步引入 Agent 能力每加一层都配上评估和监控这条路看起来慢实际上是最稳的一步到位。如果你正准备从零开始我的建议就是照着这条路径先做一个小而完整的项目。排名第一的体验门槛不是难而是开始写第一行代码这一下迈过去后面都不太难。
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 从零开始的完整技能地图先给一张清晰的技能地图照着这个地图走你就不会迷失在层出不穷的新名词里。技能模块核心能力要求主要工具/技术方向语言与编程基础Python 熟练、异步编程、类型标注Python 3.10、pydantic大模型应用基础理解 API 调用、上下文窗口、token 计算OpenAI SDK、Anthropic SDK、国内大模型 API提示词工程系统提示词设计、思维链、结构化输出少样本示例、JSON Schema、函数调用检索增强RAG文本切分、向量化、相似度检索、重排向量数据库、Embedding 模型、RerankerAgent 开发工具定义、任务规划、执行循环Function Calling、ReAct、多智能体编排评估与调优离线评估集构建、在线监控、多维指标分析评估框架、LLM-as-Judge、日志分析部署与运维API 服务化、容器化、弹性伸缩、成本优化FastAPI、Docker、Kubernetes、网关这张地图不需要一步到位但方向感很重要。我看到的大量半途而废的案例都是因为一上来就学 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, toolstool_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 tokenoverlap 加上 50 到 100再测一轮。另一个常见问题是用户问题的表述和文档表述差异太大比如文档里写报销流程用户问我出差花的钱怎么报向量检索往往无法直接命中。处理办法给每个知识片段附加别名元数据如报销出差费用报账或者在生成查询向量时先用一个小模型做一次查询改写把口语化问题转成书面化检索词。这个查询改写步骤对检索命中率的提升比换模型还明显。6.3 链路性能瓶颈和成本失控回答太慢优先检查是不是把太多候选片段喂给了模型。输入 token 越多首字延迟越长成本也越高。解决方向是快速缩小候选集先用向量检索粗取再用重排精取 Top 3 到 5保证上下文控制在 1500~2500 token 以内。另一个性能瓶颈往往是 Embedding 接口的同步调用串行阻塞了整条链路改成并发或异步之后响应时间经常能下降到原来的三分之一。成本失控的场景我见过的最多是 Agent 的多轮工具调用叠加了重复的向量化和模型调用。排查方式是给日志里每一步工具调用都打点记录 token 消耗找到消耗大户后针对性地加缓存。建议在工程开始时就在模型调用层统一封装一个带缓存、带用量统计的接口而不是所有代码直接调用 SDK——这个封装会在后续排查中省下大量心力。从我带项目的实际经验看AI 工程的本质不是炫技而是一套严谨的工程方法。从一个 RAG 项目起步逐步引入 Agent 能力每加一层都配上评估和监控这条路看起来慢实际上是最稳的一步到位。如果你正准备从零开始我的建议就是照着这条路径先做一个小而完整的项目。排名第一的体验门槛不是难而是开始写第一行代码这一下迈过去后面都不太难。