1. 先搞清楚AI工程师到底在解决什么问题很多人看到ai-engineering这个词的第一反应是又要学一堆算法和数学公式或者误以为这是个调参侠岗位。我在带了几批新人、也复盘过自己从普通后端转到AI工程方向的过程之后最大的感受是AI工程师的核心不是训练模型而是让模型在真实业务里稳定、可控、低成本地发挥作用。这个定位非常关键。它决定了你整个学习路径的重心分配也直接解释了你为什么需要了解RAG、向量数据库、Prompt工程、模型评估、服务端部署这些看起来庞杂的东西而不是埋头刷一个月的PyTorch教程。传统软件工程师的交付物是一个确定性系统输入固定输出可预期。但AI工程的操作对象是概率模型同样的Prompt今天回一句、明天可能回另一句同样的用户问题换一种问法输出质量就可能天差地别。你需要的是一套把概率变成可控的工程方法和基础设施。这就是ai-engineering从零开始这个主题真正要解决的问题。这也是为什么那些从纯算法背景转过来的人一开始反而不适应他们习惯在离线数据集上刷指标却不太在意模型上线后的延迟、吞吐、成本以及面对用户各种刁钻输入时的兜底策略。而AI工程恰好是这条从模型跑通到业务跑稳之间的所有环节。所以这篇内容适合三类人看想系统转行AI工程师的后端/前端/测试同学、已经在用API调模型但总感觉差点意思的业务开发者以及算法岗想补齐工程化能力的人。我会按照自己梳理这套体系时的思路把整个知识地图拆开讲清楚同时给出可以照着做的路线和避坑经验。2. 整体学习路线的设计思路先建地图再修路2.1 为什么不能一头扎进学深度学习我和很多自学AI工程的人聊过发现一个普遍问题大部分人最初都是被人工智能这个门面上的东西吸引然后去搜深度学习入门接着从感知机、反向传播开始啃结果两个月之后还停留在MNIST手写数字识别连一个能部署上线的功能都做不出来。然后就开始怀疑自己是不是不适合这行。这个问题的根源不是能力而是路径设计错了。AI工程是一门应用学科不是理论学科。它的知识结构是分层的底层有原理但上层不是学完底层才能碰。就像你不需要先精通发动机原理才能开车一样你完全可以在懂一点NLP基础的情况下先学会怎么用大模型API做出一套能跑的问答系统再反向补缺失的知识。我在梳理自己的学习体系时把整个ai-engineering的地图分成了七个层应用层直接面向业务的AI功能比如聊天机器人、知识库问答、内容生成、意图识别。模型交互层Prompt工程、上下文管理、function calling / tool use、参数配置。知识增强层RAG架构、向量化、检索策略、重排序、上下文压缩。数据层数据清洗、评估集构建、细粒度标注、回流闭环。模型层模型选型、量化、Fine-tuning、蒸馏、裁剪。工程层服务框架、异步处理、缓存、限流、监控、灰度发布。评估与治理层离线评估、线上评测、安全护栏、成本治理。这七个层不是要你全都精通才能干活。恰恰相反在实际工作中大约70%的业务场景只需要你打通应用层、模型交互层、知识增强层和工程层就能交付。模型层里的Fine-tuning是很多场景的加分项而非必选项评估与治理是专业度分水岭也是中高级工程师和初级工程师拉开差距的地方。2.2 核心技能树应该长什么样基于上面的分层我给自己和带过的学员都画过一张技能树现在分享出来你可以直接照着查漏补缺语言与基础Python为主重点掌握异步编程、装饰器、类型注解、上下文管理器。想精进的话补一点Go或者Node.js但Python够用。大模型API调用掌握OpenAI / Anthropic / 国内主流模型厂商的API规范理解temperature、top_p、max_tokens这些参数对输出的实际影响。Prompt工程不是写几句话那么简单。你需要掌握角色设定、少样本示例few-shot、思维链提示CoT、结构化输出约束等技巧。向量检索理解Embedding模型的作用掌握向量库选型对比ES、Milvus、Chroma、Milvus Lite、Qdrant等会写召回和精排两段式检索逻辑。RAG架构这一项是重中之重。知道什么时候该用RAG、什么时候不需要怎么对文档做分块chunking怎么把检索结果交给模型并约束它只基于检索内容回答。Agent开发理解任务规划、工具调用、多步推理、失败重试。会搭建一个具备工具调用的Agent而不只是调一个聊天的接口。服务化部署会用FastAPI把模型能力封装成接口会做流式输出SSE懂并发与限流的基本手段。评估与监控会构建一个小规模评测集能对模型输出做质量评估知道什么是回归测试在AI工程里的对应物。成本意识理解token消耗怎么计算Cache怎么用不同模型在成本和响应速度上的权衡点。这套树不是全部学会了再找工作的意思。说实话你只要掌握了前六项里的大部分配合一些实际项目经验就足够去面试初级AI工程师岗位了。关键在于把知识放进工程场景里学而不是抽象地背概念。3. 核心技术点逐个拆解从Prompt到RAG再到Agent3.1 Prompt工程所有人都低估了它的重要性在ai-engineering的日常工作中Prompt工程看起来最没有技术含量但它恰恰是性价比最高的一项技能。很多人对Prompt的理解是把需求说清楚实际上远不止于此。我自己的经验是一个高质量的系统Prompt需要具备四个要素角色与任务边界、约束条件与否定项、输入输出格式约定、异常兜底策略。举个例子同样是做一个客服问答机器人初级写法是你是一个客服请回答用户问题这基本等于没约束而合格的写法会是这样你是一位电商平台的售后客服助手。 你的任务是基于给定的商品信息和售后政策回答用户的问题。 约束 1. 只允许依据上下文中提供的信息回答不得编造。 2. 如果上下文中没有答案明确回复根据现有资料暂时无法回答。 3. 回答控制在200字以内用口语化表达。 4. 涉及退货、退款、赔偿等关键词时必须引用政策原文编号。这里的关键不是写得长而是每一项约束都有对应的工程目的。第1条是为了抑制幻觉第2条是兜底策略第3条是控制输出成本和可读性第4条是让模型在关键场景下必须有据可依。你在设计Prompt时心里想的应该是我要让模型在哪些维度上不出错而不是我要让它做什么。另一个容易忽略的点是Prompt是会被迭代的。我在实战中习惯把Prompt纳入版本管理每次调整都记录改动原因 预期效果 评测结果而不只是备忘录式地存一下。这样当下一次模型升级或者业务方反馈变多时你能快速定位是哪个约束失效了而不是从头再猜。3.2 RAG让模型学会查资料而不是背课文RAGRetrieval-Augmented Generation检索增强生成是我最建议AI工程初学者认真啃透的一个技术点因为它直接解决大模型的两个核心痛点知识过时和幻觉。企业内部的私有知识、实时数据、大量文档都不可能塞进模型参数里RAG就是让你用一个外部知识库来喂给模型答案。整个RAG流程拆开来看链路大致是文档解析 - 清洗 - 分块 - 向量化 - 存入向量库 - 用户查询向量化 - 检索召回 - 重排序 - 拼装上下文 - 模型生成。每一步看着不复杂但坑都在细节里。先说分块。很多人想当然地把文档按固定长度切比如每500个字一段。这么做的后果是语义被切碎——一句话的上半段在上一块下半段在下一块。我自己踩过这个坑之后总结出的经验是优先按语义结构分块Markdown/MD格式的文档按标题层级切PDF按章节边界切表格和列表单独处理。如果源文档没有清晰结构再用带重叠窗口的滑动切分。再说检索。只做一次TopK召回效果往往不稳定。目前工程上比较成熟的方案是召回-重排两段式第一段用向量检索或向量加上关键词BM25混合检索召回数量偏多的候选比如20到50条第二段用重排序模型Cross-Encoder按相关性精排只保留前5到10条进上下文。这样既保证了召回的覆盖面又控制了上下文长度和最终质量。还有一个细节很多人没意识到RAG的上下文拼装顺序是有讲究的。一般原则是相关性最高的放最靠近问题的地方同时明确告诉模型哪些是可参考内容、哪些是用户问题用清晰的标记分隔开。如果上下文里混入了无关文档模型很容易被带偏。3.3 向量数据库选型没有完美方案只有当下合适向量数据库这个话题网上争论很多也很容易让人选择困难。我梳理一下自己在实战中的选型思路供你参考起步阶段或原型验证直接用Chroma或者Milvus Lite本地跑零运维适合学习和POC。数据量在百万级以下且已有ES集群直接在Elasticsearch上加向量索引少维护一套系统。数据量几百万到千万级对性能和扩展性有要求认真评估Milvus或Qdrant。Milvus在云原生部署和规模扩展上更成熟Qdrant在Rust实现和单机性能上有优势。已有云厂商环境优先用云厂商托管的向量检索服务省运维成本要远大于自建可控带来的心理安慰。选型最忌讳的是为了用而用。如果你的业务只需要检索几百篇文档花大量精力部署一套分布式向量库完全是给自己找事。先跑通再扩展这是工程经验里很重要的一条。3.4 Agent开发从回答问题到完成任务Agent是最近一年热度非常高的方向但很多人把它神化了。一个Agent说白了就是给模型加上工具使用权和多步任务规划的能力让它可以调API、查数据库、使用搜索引擎等并在一系列动作中完成单靠对话无法完成的复杂任务。我从AI工程的角度建议你按三步来学Agent开发第一步掌握Function Calling或Tool Use。这是Agent的地基。你去官方文档里看文档结构其实就可以很快理解核心是把工具的调用签名描述清楚格式上是给模型一个JSON Schema定义告诉它有哪些工具、各自参数是什么模型在回答中会输出我要调用哪个工具、传什么参数然后由你的代码去真正执行并返回结果给模型。第二步掌握单轮工具调用的全流程。也就是用户提问 - 模型决定调工具A - 你的服务执行 - 将结果返回给模型 - 模型生成最终回答这套闭环逻辑。你不需要一开始就搞复杂的多Agent协作把这一步做扎实80%的实际业务都能覆盖。第三步再去看任务拆解、记忆管理、反思机制这些进阶玩法。比如AutoGPT一类项目里展示的自动循环以及后来的规划-执行-反思循环Plan-Execute-Reflection这些是加分项但前提是你已经能把前两步做得很顺。4. 从零搭建一个AI问答系统的完整实操4.1 项目设计与数据准备理论说了这么多我们直接走一个完整项目给一个内部文档库做一个AI问答机器人。这个项目非常适合作为ai-engineering入门的第一练手项目它把所有核心技术点都串在一起又不需要特别大的投入。假设你手上有一批企业内部的运维手册和产品说明文档大约几十个文件。第一个阶段的目标是用户输入一个问题系统基于这些文档内容给出有依据的回答并且能给出引用来源。我习惯把这个项目的实现分成五个阶段每个阶段都有明确的产出物阶段一文档加载与解析。写一个脚本把PDF和Markdown文件读进来做基本清洗去重、去空行、去无关页眉页脚。阶段二分块与向量化。实现语义分块逻辑调用Embedding模型将分块结果转成向量存入向量库。阶段三检索链路的初步搭建。输入一个问题能返回相关性最高的几块内容。阶段四生成链路的对接。将检索结果拼装为Prompt调用LLM生成回答支持流式输出。阶段五评估与迭代。人工检查一批测试问题对回答质量和引用正确性做评分定位并修复典型的坏案例。每个阶段不要超过两天。如果某个阶段你觉得不完美先别停顿继续往下走等整个链路通了之后再回头优化。这是工程里很核心的一个习惯先保证端到端闭环再深挖单点。4.2 核心代码骨架与执行要点这里我以Python生态为例给出一个最低可用的骨架。重点看设计思路不要逐行背诵代码。# 使用FastAPI搭建服务 import os from fastapi import FastAPI from pydantic import BaseModel app FastAPI() # 在项目启动时加载向量库和模型客户端 VECTOR_STORE None EMBED_MODEL None LLM_CLIENT None class QueryRequest(BaseModel): question: str app.on_event(startup) def load_resources(): # 全局加载一次避免每次请求重复初始化 pass app.post(/chat) async def chat(req: QueryRequest): # 1. 将用户问题向量化 # 2. 在向量库中检索TopK候选块 # 3. 重排序或过滤不相关结果 # 4. 拼装系统Prompt和上下文 # 5. 调用LLM生成回答支持SSE流式 # 6. 返回最终回答 引用来源 pass这个骨架的精髓在于把每个环节抽象成一个函数或模块比如embed_query()、retrieve()、build_prompt()、generate()。这样你在后期调试时可以直接在任意环节打印中间结果比如用户问题向量化后检索出来的前三块分别是什么而不用把整个流程翻一遍。这里有一个很实际的经验一定要把检索中间结果暴露出来。很多初级工程师只会看最终回答一旦回答不对就不知道是模型不行、检索不行还是Prompt不行。我会在开发环境里把每一步的中间输出都打印出来让调试变成一个可操作的事情而不是靠猜。4.3 一个容易踩坑的细节流式输出很多初学AI工程的人会忽略流式输出直到部署上线才发现问题用户在网页上提问之后界面白屏了几秒钟才蹦出完整回答体验极差。大模型生成一句完整回答可能需要好几秒如果等全量生成完再返回用户早就失去了耐心。流式输出SSEServer-Sent Events是目前最主流的方案原理上服务器端把模型生成的token按顺序实时推给前端。在FastAPI里实现SSE并不复杂你可以用StreamingResponse搭配异步生成器来实现。router.post(/chat_stream) async def chat_stream(req: QueryRequest): # 使用异步生成器yield每次返回的文本片段 async def event_generator(): async for chunk in llm_stream_generate(prompt): yield fdata: {chunk}\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)这段代码的重点是media_typetext/event-stream而前端用EventSource或者fetch ReadableStream来接收。等你实际做过一次流式接入你会对它有一个非常直观的感受用户第一句话还没问完回答的第一个字就已经开始蹦出来了这个体验和转圈等几秒是天壤之别。4.4 项目上线前必须做的三档自检在你觉得功能做好了的时候先别急着交付。我会做三档自检你可以把它当作一个清单模板用第一档是功能正确性。跑20到30个典型问题覆盖不同意图、不同格式短问题、长问题、带错别字的问题、引用了文档中专业术语的问题看回答内容是否准确、引用是否真实存在。这一档是最基本的要求如果连这都过不了后面都别谈。第二档是边界与兜底能力。测试没有任何相关信息的问题、和文档内容冲突的诱导性提问、多轮对话中突然换话题的情况。系统必须给出合理的兜底回复而不是生硬拼接内容或者幻觉式地胡编答案。这一档筛掉了大量线上事故隐患。第三档是性能与成本评估。记录端到端响应时间、单次请求的token消耗、检索阶段耗时占比、生成阶段耗时占比。如果预算敏感的场景还要考虑能不能用更小的模型做同样的任务或者给常见的问法加上缓存。这三档做完你才有底气说我这个AI问答系统是可以给别人用的而不是在我的电脑上跑通了。这种能跑和能用之间的距离就是AI工程师平常要填补的距离。5. 评估与监控AI工程最容易忽视的环节5.1 离线评估集你的AI项目测试用例传统软件开发里测试用例是刚需人人都有共识。但在AI工程里很多团队做出来的模型功能没有测试就上线了理由是AI的效果没法量化。这其实是偷懒的借口不是真实情况。再不确定的模型输出都能找到一套评估方案只是需要你刻意设计。我会建议你从第一天就为项目维护一份评估集Evaluation Set里面至少包括三类样本Golden Set有标准答案的问题集比如返回的答案中必须包含退换货时限为7天这类带明确事实的验证点这类型适合做自动判断。Adversarial Set诱导性问题、边界情况、无答案问题评估的是系统的鲁棒性和兜底能力。Quality Set偏主观体验类问题比如回答的可读性、条理性、口语化程度这类可以人工打分或者用另一个更强的模型来做辅助评分。评估不需要做成豪华平台初期用一个JSON文件就够每条记录包含{question, expected_points, test_type}。每次迭代完Prompt或者RAG策略之后跑一遍对比这句改完之后哪些问题变好了、哪些问题变差了。我见过太多人改Prompt全凭感觉这次调整在某几个case上效果好了就以为整体都变好了结果上线后被真实用户一怼就暴露问题。做AI工程的人一定要学会用数据说话。5.2 线上监控一个基础但有效的监控模型AI服务上线后监控和传统服务的区别在于你不仅要知道服务挂没挂还得知道我给的答案好不好。前者属于基础监控后者需要你额外设计一套评价逻辑。我建议的最低限度监控方案包含四个指标调用量、延迟、成功率、token消耗量这是基础中的基础。无答案率即系统返回无法回答这类兜底文案的比例。如果这个比例突然飙升通常是检索链路出问题了比如新文档没有同步索引。用户负面反馈率在对话结束后让用户点有帮助 / 没有帮助这是最廉价也最直接的质量信号。引用缺失率在RAG问答系统里回答没有附带引用来源的比例。有引用而用户仍然觉得没帮助和没有引用本身就是两种不同的问题。这四个指标不需要多复杂的BI系统一张Dashboard甚至一个表格都能管理。重点是你要在项目早期就把数据埋点和记录逻辑搭好不然等出了问题再补监控你会发现历史数据早丢了想复盘都没素材。最后再说一个我在实际项目中总结的经验AI工程的很多聪明问题到最后其实都靠笨办法解决。比如做一个高质量评估集本身不性感但它给你的系统带来的稳定性远比换一个更聪明的模型重要。这也是我从做过的大部分项目里得到的最真实的一条体会。
AI工程师实战指南：从Prompt到RAG再到Agent的完整学习路径
1. 先搞清楚AI工程师到底在解决什么问题很多人看到ai-engineering这个词的第一反应是又要学一堆算法和数学公式或者误以为这是个调参侠岗位。我在带了几批新人、也复盘过自己从普通后端转到AI工程方向的过程之后最大的感受是AI工程师的核心不是训练模型而是让模型在真实业务里稳定、可控、低成本地发挥作用。这个定位非常关键。它决定了你整个学习路径的重心分配也直接解释了你为什么需要了解RAG、向量数据库、Prompt工程、模型评估、服务端部署这些看起来庞杂的东西而不是埋头刷一个月的PyTorch教程。传统软件工程师的交付物是一个确定性系统输入固定输出可预期。但AI工程的操作对象是概率模型同样的Prompt今天回一句、明天可能回另一句同样的用户问题换一种问法输出质量就可能天差地别。你需要的是一套把概率变成可控的工程方法和基础设施。这就是ai-engineering从零开始这个主题真正要解决的问题。这也是为什么那些从纯算法背景转过来的人一开始反而不适应他们习惯在离线数据集上刷指标却不太在意模型上线后的延迟、吞吐、成本以及面对用户各种刁钻输入时的兜底策略。而AI工程恰好是这条从模型跑通到业务跑稳之间的所有环节。所以这篇内容适合三类人看想系统转行AI工程师的后端/前端/测试同学、已经在用API调模型但总感觉差点意思的业务开发者以及算法岗想补齐工程化能力的人。我会按照自己梳理这套体系时的思路把整个知识地图拆开讲清楚同时给出可以照着做的路线和避坑经验。2. 整体学习路线的设计思路先建地图再修路2.1 为什么不能一头扎进学深度学习我和很多自学AI工程的人聊过发现一个普遍问题大部分人最初都是被人工智能这个门面上的东西吸引然后去搜深度学习入门接着从感知机、反向传播开始啃结果两个月之后还停留在MNIST手写数字识别连一个能部署上线的功能都做不出来。然后就开始怀疑自己是不是不适合这行。这个问题的根源不是能力而是路径设计错了。AI工程是一门应用学科不是理论学科。它的知识结构是分层的底层有原理但上层不是学完底层才能碰。就像你不需要先精通发动机原理才能开车一样你完全可以在懂一点NLP基础的情况下先学会怎么用大模型API做出一套能跑的问答系统再反向补缺失的知识。我在梳理自己的学习体系时把整个ai-engineering的地图分成了七个层应用层直接面向业务的AI功能比如聊天机器人、知识库问答、内容生成、意图识别。模型交互层Prompt工程、上下文管理、function calling / tool use、参数配置。知识增强层RAG架构、向量化、检索策略、重排序、上下文压缩。数据层数据清洗、评估集构建、细粒度标注、回流闭环。模型层模型选型、量化、Fine-tuning、蒸馏、裁剪。工程层服务框架、异步处理、缓存、限流、监控、灰度发布。评估与治理层离线评估、线上评测、安全护栏、成本治理。这七个层不是要你全都精通才能干活。恰恰相反在实际工作中大约70%的业务场景只需要你打通应用层、模型交互层、知识增强层和工程层就能交付。模型层里的Fine-tuning是很多场景的加分项而非必选项评估与治理是专业度分水岭也是中高级工程师和初级工程师拉开差距的地方。2.2 核心技能树应该长什么样基于上面的分层我给自己和带过的学员都画过一张技能树现在分享出来你可以直接照着查漏补缺语言与基础Python为主重点掌握异步编程、装饰器、类型注解、上下文管理器。想精进的话补一点Go或者Node.js但Python够用。大模型API调用掌握OpenAI / Anthropic / 国内主流模型厂商的API规范理解temperature、top_p、max_tokens这些参数对输出的实际影响。Prompt工程不是写几句话那么简单。你需要掌握角色设定、少样本示例few-shot、思维链提示CoT、结构化输出约束等技巧。向量检索理解Embedding模型的作用掌握向量库选型对比ES、Milvus、Chroma、Milvus Lite、Qdrant等会写召回和精排两段式检索逻辑。RAG架构这一项是重中之重。知道什么时候该用RAG、什么时候不需要怎么对文档做分块chunking怎么把检索结果交给模型并约束它只基于检索内容回答。Agent开发理解任务规划、工具调用、多步推理、失败重试。会搭建一个具备工具调用的Agent而不只是调一个聊天的接口。服务化部署会用FastAPI把模型能力封装成接口会做流式输出SSE懂并发与限流的基本手段。评估与监控会构建一个小规模评测集能对模型输出做质量评估知道什么是回归测试在AI工程里的对应物。成本意识理解token消耗怎么计算Cache怎么用不同模型在成本和响应速度上的权衡点。这套树不是全部学会了再找工作的意思。说实话你只要掌握了前六项里的大部分配合一些实际项目经验就足够去面试初级AI工程师岗位了。关键在于把知识放进工程场景里学而不是抽象地背概念。3. 核心技术点逐个拆解从Prompt到RAG再到Agent3.1 Prompt工程所有人都低估了它的重要性在ai-engineering的日常工作中Prompt工程看起来最没有技术含量但它恰恰是性价比最高的一项技能。很多人对Prompt的理解是把需求说清楚实际上远不止于此。我自己的经验是一个高质量的系统Prompt需要具备四个要素角色与任务边界、约束条件与否定项、输入输出格式约定、异常兜底策略。举个例子同样是做一个客服问答机器人初级写法是你是一个客服请回答用户问题这基本等于没约束而合格的写法会是这样你是一位电商平台的售后客服助手。 你的任务是基于给定的商品信息和售后政策回答用户的问题。 约束 1. 只允许依据上下文中提供的信息回答不得编造。 2. 如果上下文中没有答案明确回复根据现有资料暂时无法回答。 3. 回答控制在200字以内用口语化表达。 4. 涉及退货、退款、赔偿等关键词时必须引用政策原文编号。这里的关键不是写得长而是每一项约束都有对应的工程目的。第1条是为了抑制幻觉第2条是兜底策略第3条是控制输出成本和可读性第4条是让模型在关键场景下必须有据可依。你在设计Prompt时心里想的应该是我要让模型在哪些维度上不出错而不是我要让它做什么。另一个容易忽略的点是Prompt是会被迭代的。我在实战中习惯把Prompt纳入版本管理每次调整都记录改动原因 预期效果 评测结果而不只是备忘录式地存一下。这样当下一次模型升级或者业务方反馈变多时你能快速定位是哪个约束失效了而不是从头再猜。3.2 RAG让模型学会查资料而不是背课文RAGRetrieval-Augmented Generation检索增强生成是我最建议AI工程初学者认真啃透的一个技术点因为它直接解决大模型的两个核心痛点知识过时和幻觉。企业内部的私有知识、实时数据、大量文档都不可能塞进模型参数里RAG就是让你用一个外部知识库来喂给模型答案。整个RAG流程拆开来看链路大致是文档解析 - 清洗 - 分块 - 向量化 - 存入向量库 - 用户查询向量化 - 检索召回 - 重排序 - 拼装上下文 - 模型生成。每一步看着不复杂但坑都在细节里。先说分块。很多人想当然地把文档按固定长度切比如每500个字一段。这么做的后果是语义被切碎——一句话的上半段在上一块下半段在下一块。我自己踩过这个坑之后总结出的经验是优先按语义结构分块Markdown/MD格式的文档按标题层级切PDF按章节边界切表格和列表单独处理。如果源文档没有清晰结构再用带重叠窗口的滑动切分。再说检索。只做一次TopK召回效果往往不稳定。目前工程上比较成熟的方案是召回-重排两段式第一段用向量检索或向量加上关键词BM25混合检索召回数量偏多的候选比如20到50条第二段用重排序模型Cross-Encoder按相关性精排只保留前5到10条进上下文。这样既保证了召回的覆盖面又控制了上下文长度和最终质量。还有一个细节很多人没意识到RAG的上下文拼装顺序是有讲究的。一般原则是相关性最高的放最靠近问题的地方同时明确告诉模型哪些是可参考内容、哪些是用户问题用清晰的标记分隔开。如果上下文里混入了无关文档模型很容易被带偏。3.3 向量数据库选型没有完美方案只有当下合适向量数据库这个话题网上争论很多也很容易让人选择困难。我梳理一下自己在实战中的选型思路供你参考起步阶段或原型验证直接用Chroma或者Milvus Lite本地跑零运维适合学习和POC。数据量在百万级以下且已有ES集群直接在Elasticsearch上加向量索引少维护一套系统。数据量几百万到千万级对性能和扩展性有要求认真评估Milvus或Qdrant。Milvus在云原生部署和规模扩展上更成熟Qdrant在Rust实现和单机性能上有优势。已有云厂商环境优先用云厂商托管的向量检索服务省运维成本要远大于自建可控带来的心理安慰。选型最忌讳的是为了用而用。如果你的业务只需要检索几百篇文档花大量精力部署一套分布式向量库完全是给自己找事。先跑通再扩展这是工程经验里很重要的一条。3.4 Agent开发从回答问题到完成任务Agent是最近一年热度非常高的方向但很多人把它神化了。一个Agent说白了就是给模型加上工具使用权和多步任务规划的能力让它可以调API、查数据库、使用搜索引擎等并在一系列动作中完成单靠对话无法完成的复杂任务。我从AI工程的角度建议你按三步来学Agent开发第一步掌握Function Calling或Tool Use。这是Agent的地基。你去官方文档里看文档结构其实就可以很快理解核心是把工具的调用签名描述清楚格式上是给模型一个JSON Schema定义告诉它有哪些工具、各自参数是什么模型在回答中会输出我要调用哪个工具、传什么参数然后由你的代码去真正执行并返回结果给模型。第二步掌握单轮工具调用的全流程。也就是用户提问 - 模型决定调工具A - 你的服务执行 - 将结果返回给模型 - 模型生成最终回答这套闭环逻辑。你不需要一开始就搞复杂的多Agent协作把这一步做扎实80%的实际业务都能覆盖。第三步再去看任务拆解、记忆管理、反思机制这些进阶玩法。比如AutoGPT一类项目里展示的自动循环以及后来的规划-执行-反思循环Plan-Execute-Reflection这些是加分项但前提是你已经能把前两步做得很顺。4. 从零搭建一个AI问答系统的完整实操4.1 项目设计与数据准备理论说了这么多我们直接走一个完整项目给一个内部文档库做一个AI问答机器人。这个项目非常适合作为ai-engineering入门的第一练手项目它把所有核心技术点都串在一起又不需要特别大的投入。假设你手上有一批企业内部的运维手册和产品说明文档大约几十个文件。第一个阶段的目标是用户输入一个问题系统基于这些文档内容给出有依据的回答并且能给出引用来源。我习惯把这个项目的实现分成五个阶段每个阶段都有明确的产出物阶段一文档加载与解析。写一个脚本把PDF和Markdown文件读进来做基本清洗去重、去空行、去无关页眉页脚。阶段二分块与向量化。实现语义分块逻辑调用Embedding模型将分块结果转成向量存入向量库。阶段三检索链路的初步搭建。输入一个问题能返回相关性最高的几块内容。阶段四生成链路的对接。将检索结果拼装为Prompt调用LLM生成回答支持流式输出。阶段五评估与迭代。人工检查一批测试问题对回答质量和引用正确性做评分定位并修复典型的坏案例。每个阶段不要超过两天。如果某个阶段你觉得不完美先别停顿继续往下走等整个链路通了之后再回头优化。这是工程里很核心的一个习惯先保证端到端闭环再深挖单点。4.2 核心代码骨架与执行要点这里我以Python生态为例给出一个最低可用的骨架。重点看设计思路不要逐行背诵代码。# 使用FastAPI搭建服务 import os from fastapi import FastAPI from pydantic import BaseModel app FastAPI() # 在项目启动时加载向量库和模型客户端 VECTOR_STORE None EMBED_MODEL None LLM_CLIENT None class QueryRequest(BaseModel): question: str app.on_event(startup) def load_resources(): # 全局加载一次避免每次请求重复初始化 pass app.post(/chat) async def chat(req: QueryRequest): # 1. 将用户问题向量化 # 2. 在向量库中检索TopK候选块 # 3. 重排序或过滤不相关结果 # 4. 拼装系统Prompt和上下文 # 5. 调用LLM生成回答支持SSE流式 # 6. 返回最终回答 引用来源 pass这个骨架的精髓在于把每个环节抽象成一个函数或模块比如embed_query()、retrieve()、build_prompt()、generate()。这样你在后期调试时可以直接在任意环节打印中间结果比如用户问题向量化后检索出来的前三块分别是什么而不用把整个流程翻一遍。这里有一个很实际的经验一定要把检索中间结果暴露出来。很多初级工程师只会看最终回答一旦回答不对就不知道是模型不行、检索不行还是Prompt不行。我会在开发环境里把每一步的中间输出都打印出来让调试变成一个可操作的事情而不是靠猜。4.3 一个容易踩坑的细节流式输出很多初学AI工程的人会忽略流式输出直到部署上线才发现问题用户在网页上提问之后界面白屏了几秒钟才蹦出完整回答体验极差。大模型生成一句完整回答可能需要好几秒如果等全量生成完再返回用户早就失去了耐心。流式输出SSEServer-Sent Events是目前最主流的方案原理上服务器端把模型生成的token按顺序实时推给前端。在FastAPI里实现SSE并不复杂你可以用StreamingResponse搭配异步生成器来实现。router.post(/chat_stream) async def chat_stream(req: QueryRequest): # 使用异步生成器yield每次返回的文本片段 async def event_generator(): async for chunk in llm_stream_generate(prompt): yield fdata: {chunk}\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)这段代码的重点是media_typetext/event-stream而前端用EventSource或者fetch ReadableStream来接收。等你实际做过一次流式接入你会对它有一个非常直观的感受用户第一句话还没问完回答的第一个字就已经开始蹦出来了这个体验和转圈等几秒是天壤之别。4.4 项目上线前必须做的三档自检在你觉得功能做好了的时候先别急着交付。我会做三档自检你可以把它当作一个清单模板用第一档是功能正确性。跑20到30个典型问题覆盖不同意图、不同格式短问题、长问题、带错别字的问题、引用了文档中专业术语的问题看回答内容是否准确、引用是否真实存在。这一档是最基本的要求如果连这都过不了后面都别谈。第二档是边界与兜底能力。测试没有任何相关信息的问题、和文档内容冲突的诱导性提问、多轮对话中突然换话题的情况。系统必须给出合理的兜底回复而不是生硬拼接内容或者幻觉式地胡编答案。这一档筛掉了大量线上事故隐患。第三档是性能与成本评估。记录端到端响应时间、单次请求的token消耗、检索阶段耗时占比、生成阶段耗时占比。如果预算敏感的场景还要考虑能不能用更小的模型做同样的任务或者给常见的问法加上缓存。这三档做完你才有底气说我这个AI问答系统是可以给别人用的而不是在我的电脑上跑通了。这种能跑和能用之间的距离就是AI工程师平常要填补的距离。5. 评估与监控AI工程最容易忽视的环节5.1 离线评估集你的AI项目测试用例传统软件开发里测试用例是刚需人人都有共识。但在AI工程里很多团队做出来的模型功能没有测试就上线了理由是AI的效果没法量化。这其实是偷懒的借口不是真实情况。再不确定的模型输出都能找到一套评估方案只是需要你刻意设计。我会建议你从第一天就为项目维护一份评估集Evaluation Set里面至少包括三类样本Golden Set有标准答案的问题集比如返回的答案中必须包含退换货时限为7天这类带明确事实的验证点这类型适合做自动判断。Adversarial Set诱导性问题、边界情况、无答案问题评估的是系统的鲁棒性和兜底能力。Quality Set偏主观体验类问题比如回答的可读性、条理性、口语化程度这类可以人工打分或者用另一个更强的模型来做辅助评分。评估不需要做成豪华平台初期用一个JSON文件就够每条记录包含{question, expected_points, test_type}。每次迭代完Prompt或者RAG策略之后跑一遍对比这句改完之后哪些问题变好了、哪些问题变差了。我见过太多人改Prompt全凭感觉这次调整在某几个case上效果好了就以为整体都变好了结果上线后被真实用户一怼就暴露问题。做AI工程的人一定要学会用数据说话。5.2 线上监控一个基础但有效的监控模型AI服务上线后监控和传统服务的区别在于你不仅要知道服务挂没挂还得知道我给的答案好不好。前者属于基础监控后者需要你额外设计一套评价逻辑。我建议的最低限度监控方案包含四个指标调用量、延迟、成功率、token消耗量这是基础中的基础。无答案率即系统返回无法回答这类兜底文案的比例。如果这个比例突然飙升通常是检索链路出问题了比如新文档没有同步索引。用户负面反馈率在对话结束后让用户点有帮助 / 没有帮助这是最廉价也最直接的质量信号。引用缺失率在RAG问答系统里回答没有附带引用来源的比例。有引用而用户仍然觉得没帮助和没有引用本身就是两种不同的问题。这四个指标不需要多复杂的BI系统一张Dashboard甚至一个表格都能管理。重点是你要在项目早期就把数据埋点和记录逻辑搭好不然等出了问题再补监控你会发现历史数据早丢了想复盘都没素材。最后再说一个我在实际项目中总结的经验AI工程的很多聪明问题到最后其实都靠笨办法解决。比如做一个高质量评估集本身不性感但它给你的系统带来的稳定性远比换一个更聪明的模型重要。这也是我从做过的大部分项目里得到的最真实的一条体会。
