1. 为什么要把AI工程当成一门独立学科来学这两年我面试过的候选人里很大一部分人简历上写着精通大模型应用开发但问到底层逻辑时回答往往停留在调API、拼Prompt的层面。这不能怪谁因为大模型这个东西发展太快快到大家来不及形成体系化的认知就被推着上了生产环境。我写ai-engineering-from-scratch这个项目的初衷就是想给出一条相对完整的学习路径让新人不用再靠零散的博客和视频拼凑知识版图。先说清楚一个概念AI工程不等于机器学习也不等于写几个Prompt调用GPT接口。它是一个横跨多领域的交叉学科包含模型原理、数据工程、提示词工程、Agent架构、评估体系、推理优化、成本控制等等。你从零开始学AI工程学的不是某个模型怎么用而是一整套如何把模型能力稳定地转化为产品价值的方法论。这个项目适合谁我觉得至少有三类人值得投入时间第一类是后端或全栈工程师想往AI应用方向转型但不知道从哪儿下手第二类是已经在用大模型API做东西的产品经理或独立开发者想提升系统的稳定性和智能化水平第三类是刚毕业的计算机相关专业学生希望建立一个比课程内容更贴近工业界的认知框架。我自己在带团队和做项目的过程中踩过不少坑这些坑基本都是因为某个环节的知识缺失导致的。所以接下来的内容我会按照我复盘出来的完整学习路径来讲尽量把每个环节为什么要学学到什么程度怎么落地说清楚。2. 从零构建知识体系AI工程的六层地图2.1 第一层模型基础与选型逻辑很多人一上来就学Prompt怎么写这是本末倒置。你连模型的能力边界都不清楚怎么可能写出高质量的Prompt这一层需要掌握的核心内容有三块Transformer架构的基本原理、主流模型家族的能力差异、以及不同任务的模型选型方法。不需要你从零手写Transformer但至少要知道Attention机制在干什么——它解决的是序列中哪些位置的信息需要被重点关注的问题。这里有个生活化的类比你在人群里找朋友不会挨个看每个人的脸而是会先扫一圈锁定几个可能是的目标再走近确认。Attention做的就是类似的事情在长文本里快速定位关键信息的位置。模型选型方面你需要建立一个基本判断框架任务类型文本生成、分类、抽取、多模态、延迟要求、成本预算、数据隐私要求。比如做实时客服机器人参数量很大的模型虽然聪明但延迟高、单价贵未必比精心调校的中型模型更合适。我见过不少团队一上来就接最贵的模型结果成本翻了五倍效果提升却不到两个百分点。2.2 第二层数据工程与上下文管理这一层是最容易被忽视但实则决定上限的部分。大模型的能力再强喂进去的数据质量差输出也一定不稳定。数据工程在AI工程里包含两块一是训练/微调阶段的数据准备二是推理阶段的上下文构建。对于从零开始的初学者重点先放在第二部分。上下文构建涉及的知识包括文本分块策略、检索排序、上下文窗口管理、结构化数据的序列化。我举个实际例子你在做文档问答系统时不能把整本手册全塞给模型而是要把手册切成合适的块检索出最相关的几块再拼进Prompt。这个切的策略直接决定了答案质量。分块不是简单按字数切。我实践下来比较好用的方式是先按章节结构切再把过长的段落按语义边界切比如按标题、按列表、按代码块边界最后给每个块打上元信息标签比如来源章节、文档类型、更新时间。这样检索时就可以用元信息做过滤准确率能提升不少。2.3 第三层提示词工程与模式复用提示词工程是AI工程里最像艺术的部分但也在快速走向工程化。第三层学习的目标是掌握常见的提示词模式理解不同模式适用的场景并且学会把好的Prompt沉淀为可复用的模板。我常用的几个模式角色扮演模式适合专业性较强的任务比如你是一名资深运维工程师请分析以下日志。思维链模式适合推理任务让模型一步一步思考可以显著提升逻辑正确率。少样本模式给几个输入输出的示例比单纯描述规则更有效因为模型擅长模仿而不擅长理解抽象规则。结构化输出模式指定JSON格式或Markdown格式方便程序解析。学提示词工程有个误区就是觉得万能模板存在。实际上每个任务都需要调试我的习惯是每写一个Prompt都会记录版本和测试结果像写代码一样维护Prompt的版本历史。2.4 第四层Agent架构与工具调用这是目前最热门也最混乱的领域。Agent的本质是让模型具备感知—决策—行动的闭环能力感知来自用户输入和外部信息源决策由模型推理完成行动涉及调用工具、读写数据、发起网络请求。从零学Agent我建议按四个阶段推进。第一阶段用ReAct框架搭一个极简的思考-行动-观察循环理解Agent的基本工作原理。第二阶段学习函数调用Function Calling让模型学会输出结构化的工具调用指令。第三阶段引入规划能力让Agent能把复杂任务拆成多个子任务。第四阶段考虑多Agent协作不同Agent负责不同环节由一个协调者统一调度。这里必须提醒一句Agent的可靠性问题是当前最大的工程挑战。模型自主决策不可避免会出错所以工程上要做大量的约束限制工具权限、增加人工确认节点、设置执行超时、建立回滚机制。千万不要上来就做一个全自主的Agent放到生产环境我见过太多翻车案例了。2.5 第五层评估体系与质量保障这一层是我最想强调的也是绝大多数自学者完全缺失的部分。做传统软件你写单元测试就行但做AI应用你会发现同一个Prompt跑一百次可能有一百次不同的输出怎么验证系统是对的评估体系需要从两个维度建立离线评估和在线监控。离线评估是在发版前用一组标注好的测试集跑模型通过对比输出与标准答案来计算准确率、召回率、相关性等指标。在线监控是上线后用真实用户请求做抽样评估配合用户反馈机制持续发现问题。我现在团队里常用的做法是每周抽200条线上请求人工标注质量和模型版本、Prompt版本关联起来形成数据报表。这样每次改Prompt或者换模型都能看到量化指标的变化而不是凭感觉说好像变好了。2.6 第六层性能优化与成本控制最后一层是工程落地的硬功夫。大模型推理的延迟和成本往往决定了产品能不能规模化。你需要掌握的技术包括缓存策略把重复的请求结果缓存起来、模型蒸馏用大模型训练小模型、量化推理、批处理优化、以及多级缓存架构比如热门问题走短答案冷门问题走长答案。这一层的学习建议是先做成本估算练习把一个功能的单次调用成本算清楚再考虑优化。很多团队亏钱不是因为功能不好而是因为单位经济模型没有算明白。算清楚之后你自然知道哪些环节需要优化、优化到什么程度。3. 实操环节从零搭建一个完整的AI问答系统3.1 环境准备与API接入理论说再多不动手永远学不会。我带大家从零做一个基于本地技术文档的智能问答系统这个项目几乎涵盖了前面说的所有技术点。技术栈选型上我用的是Python FastAPI做后端向量数据库用Milvus或者Chromadb轻量方案根据部署环境而定大模型底座可以选OpenAI的API也可以选国内的开源模型比如Qwen、ChatGLM系列这里不绑定具体厂商因为整体架构是通用的。第一步搭建Python环境并安装依赖python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate pip install fastapi uvicorn openai chromadb langchain安装完成后建议先跑一个最小接口验证API连通性不要急着写业务逻辑。我踩过的一个坑是网络代理配置问题导致API调用超时排查了半天才发现是环境变量里的代理设置有问题这种基础问题先验证可以省下很多时间。3.2 文档处理与向量化索引文档问答系统的核心第一步是把原始文档转换成可检索的向量索引。我以一份约200页的产品手册为例演示完整的处理流程。处理流程分为三步加载解析、分块、向量化。加载解析用LangChain的文档加载器支持PDF、Markdown、HTML等格式。分块策略我直接给出一个经过调参的经验值块大小500-800个字符重叠50-100个字符。这个参数不是绝对的需要根据文档类型微调。比如代码示例多的文档块要小一些因为代码块的语义密度高太大容易混入无关内容。向量化环节有两个选择直接用OpenAI的Embedding接口或者本地跑开源的Embedding模型比如bge-large-zh。前者效果好但每次都调API有成本后者部署麻烦但隐私性好、无单次调用成本。个人项目我建议用bge系列生产环境则要评估数据量级和隐私要求。3.3 检索逻辑的实现与优化索引建好之后核心的检索逻辑需要精心设计。朴素的做法是用户提问向量检索TopK个相关片段拼进Prompt给LLM生成答案。但这在实际使用中远远不够因为相关性判断经常会出问题。我改进后的检索流程是这样的先做查询改写把用户的提问转换成更利于检索的表达形式比如用户问怎么改密码改写为修改密码的步骤和操作说明然后做混合检索同时使用向量相似度检索和关键词BM25检索把两路结果做融合排序最后做重排序用一个轻量级的rerank模型对候选片段重新打分过滤掉不相关的内容。# 伪代码示例混合检索与重排序 def search(query, top_k5): # 查询改写 rewritten rewrite_query(query) # 向量检索 vector_results vector_search(rewritten, top_k20) # 关键词检索 keyword_results bm25_search(rewritten, top_k20) # 结果融合 fused fuse_results(vector_results, keyword_results) # 重排序 reranked rerank(query, fused) return reranked[:top_k]这个流程跑下来检索准确率比单纯的向量检索高出很多。很多系统效果不好的根源不是模型能力不行而是检索环节就把相关信息弄丢了。3.4 生成策略与提示词设计检索到相关内容后生成环节的Prompt设计直接影响最终答案质量。我优化过的一个Prompts模板供参考你是一名技术支持工程师请基于以下技术文档回答用户的问题。 要求 1. 优先引用文档中的原文作为依据 2. 如果文档中没有相关内容明确告知并给出一般性建议 3. 回答要分步骤说明便于用户操作 4. 用词准确不要编造不存在的功能 技术文档片段 {context} 用户问题{question}这个Prompt的效果不错关键设计点在于限制了回答的信息来源范围只基于文档限制了行为边界没有相关内容时怎么办规定了输出格式分步骤说明并且在系统层面加了一个引用原文的机制方便用户验证答案的真实性。3.5 评估集构建与指标计算系统搭完最重要的事情是建立一套评估标准否则你根本不知道系统是好是坏。我的做法是准备50条代表性测试问题涵盖不同难度和类型简单事实类系统最低支持什么版本的Python操作步骤类如何配置数据库连接故障排查类如果服务启动失败如何查看日志定位问题边界情况类是否支持Windows 7系统文档中未提及每条问题标注标准答案或关键得分点然后对系统跑一遍测试逐条评分。评分维度可以包括答案正确性、完整性、规范性是否按格式要求输出、拒绝率不确定时是否诚实说明。我当时的评估结果简单类问题正确率大概在90%以上操作步骤类在70%左右故障排查类只有50%边界类问题系统经常错误地给出肯定回答这是一个需要特别注意的风险。后来通过调整系统提示语——明确要求未知的信息不要猜测——将边界类问题的错误率降下来了不少。4. 常见问题与排查技巧实录4.1 上下文窗口溢出问题做问答系统最常遇到的一个错误是输入超出模型最大上下文长度。这个问题的根源在于把检索到的所有片段都塞进Prompt没有做总量控制。解决方案有三个层级第一级控制检索数量不要追求Top20全塞进去一般Top5到8就够用了第二级做一个上下文压缩步骤把检索到的片段用LLM提取关键信息后再拼接第三级如果文档本身很长考虑用MapReduce的方式先分块总结再合并。这三个方案可以组合使用效果最好的是前两个。4.2 回答幻觉问题模型自信地给出一个完全错误的信息这是大模型应用最危险的问题。降低幻觉我实践下来最有效的手段有三板斧强制Grounding要求回答必须引用文档原文、降低回答的确定性指令上明确不确定就说不知道、增加事实验证模块用额外的模型调用检查回答中的关键声明是否与文档一致。第三板斧成本比较高生产环境建议只对高风险场景启用比如医疗、法律、财务等领域。一般场景做好前两点配合评估体系中拒绝率这个指标持续监控即可。4.3 检索结果不相关这种情况最让人崩溃你明确问了A系统检索到的全是B相关的内容。排查思路从三个方向进行第一检查Embedding模型和查询处理流程是否对查询做了有效的改写第二检查分块大小是否合适块太大容易把不相关的信息混进来块太小则语境不足第三检查元信息被检索环节使用是否正确比如本应该按文档类型过滤的没有过滤导致跨领域的片段干扰排序。4.4 常见问题速查表症状可能原因排查方法API调用超时网络环境异常、请求体过大检查代理配置、缩小Prompt长度、开启流式响应回答内容不合规系统提示词约束不够强化Prompt边界、增加输出安全性审查向量检索速度慢数据量过大、索引参数不当使用IVF索引、增加显存/内存、分片部署JSON格式解析失败模型输出不稳定使用结构化输出约束、增加异常重试连续对话出现矛盾上下文续传逻辑不完整维护独立的对话状态记录、安装系统信息注入RAG效果不如直接问LLM检索质量拖后腿优化分块与重排序、做查询改写、考虑微调Embedding模型4.5 从零起跑者的五个建议最后给想迈出第一步的人一些经验这五条是我带新人时反复强调的第一别一上来就追新模型、新框架。先把一个稳定的技术栈用熟深入理解其原理和局限新东西出来你迁移的成本会很低。第二一定要手工标注和评估数据。哪怕只标100条这个过程能让你切身感受到模型的边界远比你跑一万次盲测更有价值。第三每次修改必须做前后效果对比。没有对比的优化都是自嗨你需要用数据说服自己而不只是感觉。第四重视版本管理。Prompt要分版本Agent逻辑要分版本评估数据也要分版本否则出了问题根本没法回溯。这是AI项目与传统软件项目最大的差别之一你需要Debug的不仅是代码还有数据和文本。第五多在实践中积累不完美案例。AI工程是一门试错驱动的学科失败的实验记录往往比成功的经验更值钱——它们是你建立直觉的基础。5. 后续扩展路径从问答系统到AI原生应用基础问答系统做完之后扩展方向有三个层次。第一层次是增强把单轮问答扩展为多轮对话加入记忆管理、指代消解用户说那个功能你还能跟上这一步涉及对话状态维护和上下文压缩策略。第二层次是自动化引入Agent机制后系统就不再只是被动回答问题而是可以主动执行操作——查数据库、调内部API、发通知、生成报告。这个方向要用到我们前面说的Function Calling和任务规划。第三层次是协作多个专业Agent协同工作比如一个Agent负责理解需求一个Agent负责写代码一个Agent负责测试和Review。这个方向目前还在快速演进工程模式尚未定型但方向已经明确。坦白说我见过很多学习者走到RAG和评估那一步就停下来了觉得够用了。但实际上从工程价值的角度看真正拉开差距的反而是那些看似枯燥的部分——数据质量、评估体系、成本优化、可靠性保障。这些部分不性感但决定了产品能不能在真实世界里长期跑下去。AI工程从零开始学的不是花哨的炫技而是这些扎扎实实的基本功。这条路不算短但每一步都算数。 AI工程从零到落地：六层知识体系与RAG问答系统实战
1. 为什么要把AI工程当成一门独立学科来学这两年我面试过的候选人里很大一部分人简历上写着精通大模型应用开发但问到底层逻辑时回答往往停留在调API、拼Prompt的层面。这不能怪谁因为大模型这个东西发展太快快到大家来不及形成体系化的认知就被推着上了生产环境。我写ai-engineering-from-scratch这个项目的初衷就是想给出一条相对完整的学习路径让新人不用再靠零散的博客和视频拼凑知识版图。先说清楚一个概念AI工程不等于机器学习也不等于写几个Prompt调用GPT接口。它是一个横跨多领域的交叉学科包含模型原理、数据工程、提示词工程、Agent架构、评估体系、推理优化、成本控制等等。你从零开始学AI工程学的不是某个模型怎么用而是一整套如何把模型能力稳定地转化为产品价值的方法论。这个项目适合谁我觉得至少有三类人值得投入时间第一类是后端或全栈工程师想往AI应用方向转型但不知道从哪儿下手第二类是已经在用大模型API做东西的产品经理或独立开发者想提升系统的稳定性和智能化水平第三类是刚毕业的计算机相关专业学生希望建立一个比课程内容更贴近工业界的认知框架。我自己在带团队和做项目的过程中踩过不少坑这些坑基本都是因为某个环节的知识缺失导致的。所以接下来的内容我会按照我复盘出来的完整学习路径来讲尽量把每个环节为什么要学学到什么程度怎么落地说清楚。2. 从零构建知识体系AI工程的六层地图2.1 第一层模型基础与选型逻辑很多人一上来就学Prompt怎么写这是本末倒置。你连模型的能力边界都不清楚怎么可能写出高质量的Prompt这一层需要掌握的核心内容有三块Transformer架构的基本原理、主流模型家族的能力差异、以及不同任务的模型选型方法。不需要你从零手写Transformer但至少要知道Attention机制在干什么——它解决的是序列中哪些位置的信息需要被重点关注的问题。这里有个生活化的类比你在人群里找朋友不会挨个看每个人的脸而是会先扫一圈锁定几个可能是的目标再走近确认。Attention做的就是类似的事情在长文本里快速定位关键信息的位置。模型选型方面你需要建立一个基本判断框架任务类型文本生成、分类、抽取、多模态、延迟要求、成本预算、数据隐私要求。比如做实时客服机器人参数量很大的模型虽然聪明但延迟高、单价贵未必比精心调校的中型模型更合适。我见过不少团队一上来就接最贵的模型结果成本翻了五倍效果提升却不到两个百分点。2.2 第二层数据工程与上下文管理这一层是最容易被忽视但实则决定上限的部分。大模型的能力再强喂进去的数据质量差输出也一定不稳定。数据工程在AI工程里包含两块一是训练/微调阶段的数据准备二是推理阶段的上下文构建。对于从零开始的初学者重点先放在第二部分。上下文构建涉及的知识包括文本分块策略、检索排序、上下文窗口管理、结构化数据的序列化。我举个实际例子你在做文档问答系统时不能把整本手册全塞给模型而是要把手册切成合适的块检索出最相关的几块再拼进Prompt。这个切的策略直接决定了答案质量。分块不是简单按字数切。我实践下来比较好用的方式是先按章节结构切再把过长的段落按语义边界切比如按标题、按列表、按代码块边界最后给每个块打上元信息标签比如来源章节、文档类型、更新时间。这样检索时就可以用元信息做过滤准确率能提升不少。2.3 第三层提示词工程与模式复用提示词工程是AI工程里最像艺术的部分但也在快速走向工程化。第三层学习的目标是掌握常见的提示词模式理解不同模式适用的场景并且学会把好的Prompt沉淀为可复用的模板。我常用的几个模式角色扮演模式适合专业性较强的任务比如你是一名资深运维工程师请分析以下日志。思维链模式适合推理任务让模型一步一步思考可以显著提升逻辑正确率。少样本模式给几个输入输出的示例比单纯描述规则更有效因为模型擅长模仿而不擅长理解抽象规则。结构化输出模式指定JSON格式或Markdown格式方便程序解析。学提示词工程有个误区就是觉得万能模板存在。实际上每个任务都需要调试我的习惯是每写一个Prompt都会记录版本和测试结果像写代码一样维护Prompt的版本历史。2.4 第四层Agent架构与工具调用这是目前最热门也最混乱的领域。Agent的本质是让模型具备感知—决策—行动的闭环能力感知来自用户输入和外部信息源决策由模型推理完成行动涉及调用工具、读写数据、发起网络请求。从零学Agent我建议按四个阶段推进。第一阶段用ReAct框架搭一个极简的思考-行动-观察循环理解Agent的基本工作原理。第二阶段学习函数调用Function Calling让模型学会输出结构化的工具调用指令。第三阶段引入规划能力让Agent能把复杂任务拆成多个子任务。第四阶段考虑多Agent协作不同Agent负责不同环节由一个协调者统一调度。这里必须提醒一句Agent的可靠性问题是当前最大的工程挑战。模型自主决策不可避免会出错所以工程上要做大量的约束限制工具权限、增加人工确认节点、设置执行超时、建立回滚机制。千万不要上来就做一个全自主的Agent放到生产环境我见过太多翻车案例了。2.5 第五层评估体系与质量保障这一层是我最想强调的也是绝大多数自学者完全缺失的部分。做传统软件你写单元测试就行但做AI应用你会发现同一个Prompt跑一百次可能有一百次不同的输出怎么验证系统是对的评估体系需要从两个维度建立离线评估和在线监控。离线评估是在发版前用一组标注好的测试集跑模型通过对比输出与标准答案来计算准确率、召回率、相关性等指标。在线监控是上线后用真实用户请求做抽样评估配合用户反馈机制持续发现问题。我现在团队里常用的做法是每周抽200条线上请求人工标注质量和模型版本、Prompt版本关联起来形成数据报表。这样每次改Prompt或者换模型都能看到量化指标的变化而不是凭感觉说好像变好了。2.6 第六层性能优化与成本控制最后一层是工程落地的硬功夫。大模型推理的延迟和成本往往决定了产品能不能规模化。你需要掌握的技术包括缓存策略把重复的请求结果缓存起来、模型蒸馏用大模型训练小模型、量化推理、批处理优化、以及多级缓存架构比如热门问题走短答案冷门问题走长答案。这一层的学习建议是先做成本估算练习把一个功能的单次调用成本算清楚再考虑优化。很多团队亏钱不是因为功能不好而是因为单位经济模型没有算明白。算清楚之后你自然知道哪些环节需要优化、优化到什么程度。3. 实操环节从零搭建一个完整的AI问答系统3.1 环境准备与API接入理论说再多不动手永远学不会。我带大家从零做一个基于本地技术文档的智能问答系统这个项目几乎涵盖了前面说的所有技术点。技术栈选型上我用的是Python FastAPI做后端向量数据库用Milvus或者Chromadb轻量方案根据部署环境而定大模型底座可以选OpenAI的API也可以选国内的开源模型比如Qwen、ChatGLM系列这里不绑定具体厂商因为整体架构是通用的。第一步搭建Python环境并安装依赖python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate pip install fastapi uvicorn openai chromadb langchain安装完成后建议先跑一个最小接口验证API连通性不要急着写业务逻辑。我踩过的一个坑是网络代理配置问题导致API调用超时排查了半天才发现是环境变量里的代理设置有问题这种基础问题先验证可以省下很多时间。3.2 文档处理与向量化索引文档问答系统的核心第一步是把原始文档转换成可检索的向量索引。我以一份约200页的产品手册为例演示完整的处理流程。处理流程分为三步加载解析、分块、向量化。加载解析用LangChain的文档加载器支持PDF、Markdown、HTML等格式。分块策略我直接给出一个经过调参的经验值块大小500-800个字符重叠50-100个字符。这个参数不是绝对的需要根据文档类型微调。比如代码示例多的文档块要小一些因为代码块的语义密度高太大容易混入无关内容。向量化环节有两个选择直接用OpenAI的Embedding接口或者本地跑开源的Embedding模型比如bge-large-zh。前者效果好但每次都调API有成本后者部署麻烦但隐私性好、无单次调用成本。个人项目我建议用bge系列生产环境则要评估数据量级和隐私要求。3.3 检索逻辑的实现与优化索引建好之后核心的检索逻辑需要精心设计。朴素的做法是用户提问向量检索TopK个相关片段拼进Prompt给LLM生成答案。但这在实际使用中远远不够因为相关性判断经常会出问题。我改进后的检索流程是这样的先做查询改写把用户的提问转换成更利于检索的表达形式比如用户问怎么改密码改写为修改密码的步骤和操作说明然后做混合检索同时使用向量相似度检索和关键词BM25检索把两路结果做融合排序最后做重排序用一个轻量级的rerank模型对候选片段重新打分过滤掉不相关的内容。# 伪代码示例混合检索与重排序 def search(query, top_k5): # 查询改写 rewritten rewrite_query(query) # 向量检索 vector_results vector_search(rewritten, top_k20) # 关键词检索 keyword_results bm25_search(rewritten, top_k20) # 结果融合 fused fuse_results(vector_results, keyword_results) # 重排序 reranked rerank(query, fused) return reranked[:top_k]这个流程跑下来检索准确率比单纯的向量检索高出很多。很多系统效果不好的根源不是模型能力不行而是检索环节就把相关信息弄丢了。3.4 生成策略与提示词设计检索到相关内容后生成环节的Prompt设计直接影响最终答案质量。我优化过的一个Prompts模板供参考你是一名技术支持工程师请基于以下技术文档回答用户的问题。 要求 1. 优先引用文档中的原文作为依据 2. 如果文档中没有相关内容明确告知并给出一般性建议 3. 回答要分步骤说明便于用户操作 4. 用词准确不要编造不存在的功能 技术文档片段 {context} 用户问题{question}这个Prompt的效果不错关键设计点在于限制了回答的信息来源范围只基于文档限制了行为边界没有相关内容时怎么办规定了输出格式分步骤说明并且在系统层面加了一个引用原文的机制方便用户验证答案的真实性。3.5 评估集构建与指标计算系统搭完最重要的事情是建立一套评估标准否则你根本不知道系统是好是坏。我的做法是准备50条代表性测试问题涵盖不同难度和类型简单事实类系统最低支持什么版本的Python操作步骤类如何配置数据库连接故障排查类如果服务启动失败如何查看日志定位问题边界情况类是否支持Windows 7系统文档中未提及每条问题标注标准答案或关键得分点然后对系统跑一遍测试逐条评分。评分维度可以包括答案正确性、完整性、规范性是否按格式要求输出、拒绝率不确定时是否诚实说明。我当时的评估结果简单类问题正确率大概在90%以上操作步骤类在70%左右故障排查类只有50%边界类问题系统经常错误地给出肯定回答这是一个需要特别注意的风险。后来通过调整系统提示语——明确要求未知的信息不要猜测——将边界类问题的错误率降下来了不少。4. 常见问题与排查技巧实录4.1 上下文窗口溢出问题做问答系统最常遇到的一个错误是输入超出模型最大上下文长度。这个问题的根源在于把检索到的所有片段都塞进Prompt没有做总量控制。解决方案有三个层级第一级控制检索数量不要追求Top20全塞进去一般Top5到8就够用了第二级做一个上下文压缩步骤把检索到的片段用LLM提取关键信息后再拼接第三级如果文档本身很长考虑用MapReduce的方式先分块总结再合并。这三个方案可以组合使用效果最好的是前两个。4.2 回答幻觉问题模型自信地给出一个完全错误的信息这是大模型应用最危险的问题。降低幻觉我实践下来最有效的手段有三板斧强制Grounding要求回答必须引用文档原文、降低回答的确定性指令上明确不确定就说不知道、增加事实验证模块用额外的模型调用检查回答中的关键声明是否与文档一致。第三板斧成本比较高生产环境建议只对高风险场景启用比如医疗、法律、财务等领域。一般场景做好前两点配合评估体系中拒绝率这个指标持续监控即可。4.3 检索结果不相关这种情况最让人崩溃你明确问了A系统检索到的全是B相关的内容。排查思路从三个方向进行第一检查Embedding模型和查询处理流程是否对查询做了有效的改写第二检查分块大小是否合适块太大容易把不相关的信息混进来块太小则语境不足第三检查元信息被检索环节使用是否正确比如本应该按文档类型过滤的没有过滤导致跨领域的片段干扰排序。4.4 常见问题速查表症状可能原因排查方法API调用超时网络环境异常、请求体过大检查代理配置、缩小Prompt长度、开启流式响应回答内容不合规系统提示词约束不够强化Prompt边界、增加输出安全性审查向量检索速度慢数据量过大、索引参数不当使用IVF索引、增加显存/内存、分片部署JSON格式解析失败模型输出不稳定使用结构化输出约束、增加异常重试连续对话出现矛盾上下文续传逻辑不完整维护独立的对话状态记录、安装系统信息注入RAG效果不如直接问LLM检索质量拖后腿优化分块与重排序、做查询改写、考虑微调Embedding模型4.5 从零起跑者的五个建议最后给想迈出第一步的人一些经验这五条是我带新人时反复强调的第一别一上来就追新模型、新框架。先把一个稳定的技术栈用熟深入理解其原理和局限新东西出来你迁移的成本会很低。第二一定要手工标注和评估数据。哪怕只标100条这个过程能让你切身感受到模型的边界远比你跑一万次盲测更有价值。第三每次修改必须做前后效果对比。没有对比的优化都是自嗨你需要用数据说服自己而不只是感觉。第四重视版本管理。Prompt要分版本Agent逻辑要分版本评估数据也要分版本否则出了问题根本没法回溯。这是AI项目与传统软件项目最大的差别之一你需要Debug的不仅是代码还有数据和文本。第五多在实践中积累不完美案例。AI工程是一门试错驱动的学科失败的实验记录往往比成功的经验更值钱——它们是你建立直觉的基础。5. 后续扩展路径从问答系统到AI原生应用基础问答系统做完之后扩展方向有三个层次。第一层次是增强把单轮问答扩展为多轮对话加入记忆管理、指代消解用户说那个功能你还能跟上这一步涉及对话状态维护和上下文压缩策略。第二层次是自动化引入Agent机制后系统就不再只是被动回答问题而是可以主动执行操作——查数据库、调内部API、发通知、生成报告。这个方向要用到我们前面说的Function Calling和任务规划。第三层次是协作多个专业Agent协同工作比如一个Agent负责理解需求一个Agent负责写代码一个Agent负责测试和Review。这个方向目前还在快速演进工程模式尚未定型但方向已经明确。坦白说我见过很多学习者走到RAG和评估那一步就停下来了觉得够用了。但实际上从工程价值的角度看真正拉开差距的反而是那些看似枯燥的部分——数据质量、评估体系、成本优化、可靠性保障。这些部分不性感但决定了产品能不能在真实世界里长期跑下去。AI工程从零开始学的不是花哨的炫技而是这些扎扎实实的基本功。这条路不算短但每一步都算数。