1. 先搞清楚AI工程到底在解决什么问题我从这个标题里读出的第一层信息是AI工程从来不是某一个单一技能而是把模型变成可用系统的那一整条链路。很多人一听到AI engineering第一反应是“会训练模型”或者“会写Python调用API”但真正干过几个项目之后会发现训练和调用只占整个工作量的三分之一不到剩下的时间几乎都耗在数据处理、效果调优、接口对接、部署上线以及无穷无尽的问题排查上。如果你是个刚入行的新人或者一个想把自己的想法用AI落地的工程师我建议先别急着装PyTorch、买显卡而是花点时间想清楚“AI工程”这个词拆开之后的味道。工程意味着可复现、可测试、可维护、可交付。它不像做实验模型指标差不多就行工程要的是别人拿着你的代码搭好环境按下开关系统能稳定跑起来并且产出质量可控的结果。1.1 从模型训练到系统交付中间缺的不是魔法我见过很多人的误区包括我自己刚入行时也踩过以为AI项目最难的是模型本身于是花几个月死磕Transformer源码、手写反向传播结果一到真正做项目卡在“如何把一份PDF简历变成干净的文本”“如何让大模型回答不胡编”“如何让接口延迟控制在两秒内”这种一点都不性感的问题上。这是典型的把AI工程约等于模型训练的误解。模型训练尤其是今天大家都在用的基于预训练模型做微调或者直接做推理增强难度已经比五年前低了很多。HuggingFace上随便拉一个开源模型几行代码就能跑起来商用API更是开箱即用。真正拉开差距的是把模型嵌进业务系统后那些围绕模型展开的数据治理、评测体系、链路设计、性能优化和成本控制。打个比方模型像发动机AI工程是整车制造。发动机是核心技术但一辆能上路的车需要油箱、变速箱、底盘、刹车、车机系统以及一整套安全测试。现实是大多数业务的痛点根本不在发动机而在整车的协调性和可靠性。从零开始学AI工程说白了就是学怎么造整车而不是只盯着发动机。1.2 为什么“从零开始”是一条更靠谱的路线这个标题里的“from scratch”非常关键。市面上太多速成课程教你三天调用ChatGPT接口就算会AI了。这种学习方式最大的问题是根基不稳一遇到新模型、新框架、新业务场景就彻底歇菜。从零开始意味着你要亲手把每个环节走一遍自己写过数据清洗脚本才理解脏数据对效果的杀伤力有多大自己搭建过向量检索才知道索引参数和分块策略有多讲究自己亲手部署过推理服务才知道显存占用和并发吞吐之间要如何权衡。这些“亲手踩过”的经验是任何速成课都给不了的。我推荐的学习节奏是线性推进先掌握最核心的Python基本功再理解模型推理和微调的原理然后重点突破工程化四件套——数据、评估、部署、运维。每一步都配合一个极小的项目练手不要跳步。等到这条链路走通两三次你会发现自己再看任何新的AI技术都能很快定位它在链路中的位置学习速度会快很多。2. 学习路线与工具选型照着抄就行从零开始最大的困扰不是不知道要学什么而是网上信息太杂一会儿有人让你学深度学习数学基础一会儿有人让你直接上手LangChain一会儿又有人吹低代码平台。我的建议是把学习目标明确拆成三个阶段每个阶段的工具都控制在最小集内学完一个阶段立刻做一个小项目固化下来。2.1 第一阶段把地基打牢别嫌枯燥这一阶段我建议只用两个工具Python和Git。Python不用说了AI生态的通用语言。这里说的不是会写个for循环就行至少要有能力写清晰的数据处理脚本。具体来说要熟练掌握字典和列表的嵌套操作、文件读写、异常处理、函数式编程里的map和filter、面向对象的基本封装。推荐把Pandas和NumPy的基础操作也练熟因为后面所有数据清洗都会用到。Git的作用很多人低估了。做AI项目代码迭代速度极快数据、配置、Prompt、模型版本都在频繁更改没有版本控制基本是灾难。我见过不止一个团队因为配置文件和Prompt没有纳入git管理出了问题只能靠记忆回退最后浪费大量时间。建议至少掌握add、commit、branch、merge、revert这几个操作再配合一个Git托管平台使用。可以新建一个名为ai-engineering-practice的空仓库后面每个练习项目都放进去日积月累就是很宝贵的资产。这个阶段还要补一点命令行和Linux基础不需要到运维工程师的水准但至少会切换目录、操作文件、装Python包、看进程和显存占用。因为后面部署和调试GPU服务时你大概率要面对一台无图形界面的Linux服务器。2.2 第二阶段模型与框架动手跑起来比死磕理论重要第二阶段开始接触模型。我强烈建议选PyTorch作为主框架生态最全遇到问题搜解决方案也最容易。开始不要读大部头理论书先跑通一段推理代码用HuggingFace的transformers库加载一个中小型开源模型跑一次文本分类或者对话生成感受一下输入输出的完整流程。这一步的核心目标是理解模型推理的基本链路而不是理解模型内部的每一个数学推导。理论学习只需要三个点一是tokenization明白文本是怎么被切成token并映射成id的二是attention机制存在的意义明白模型为什么能捕捉上下文关系三是softmax和温度参数明白模型的输出概率是如何变成最终文本的。这三个点搞明白你就足够继续往前走了。反向传播和预训练目标等细节可以放到后续项目中带着问题去补一上来啃这些大概率劝退。跑通推理之后可以尝试微调。优先用LoRA之类的高效微调方法消费级显卡也能跑得动。找一个小规模的开源模型和一个几百条的领域数据集把原本只会通用对话的模型微调成能够识别你领域关键词的模型。做这个项目时你会接触到训练循环、损失函数、学习率、epoch等概念这才是有体感的理解比刷十遍理论课都深刻。2.3 第三阶段工程化三件套数据、评估、部署这阶段是AI工程的核心分水岭。数据方面的核心技能是清洗与构造。真实场景的数据永远比教程数据集脏你要学会处理缺失值、重复值、格式混乱、编码问题。对一个文档型RAG系统来说还要掌握拆分、解析、去重、转向量。推荐学习unstructured、BeautifulSoup这类解析库以及Chroma、FAISS这类轻量向量库。不要一上来就上分布式大数据技术绝大多数项目的数据量用不到反而徒增复杂度。评估是很多自学者最容易忽略的一环。模型效果好不好不能靠“感觉还行”来判断。至少要搭建一个小小的评测集准备二三十组输入和预期输出每次改动Prompt或者检索逻辑都跑一遍评测集用人工打分或者规则打分的方式记录效果变化。养成这个习惯之后你调优就不会再靠碰运气每次改动都有了可靠的反馈信号。部署方面先掌握FastAPI和Docker。用FastAPI把模型推理封装成一个HTTP接口然后写一个Dockerfile把环境和依赖打包成镜像。如果GPU资源够推荐了解vLLM这类推理加速框架如果资源有限用Ollama也能迅速部署本地模型服务。这个阶段的目标是做到“把项目打包交出去别人能一键跑起来”到了这一步你已经具备最基本的AI工程交付能力。3. 用一个小项目走通全流程简历问答助手理论聊再多都不如亲手做一遍。我选一个非常适合从零起步的练手项目简历问答助手。输入是一批简历文档用户可以问“候选人JAVA经验几年”“谁最适合前端岗位”系统从简历里检索相关片段调用模型生成回答。这个项目麻雀虽小五脏俱全数据解析、文本分块、向量检索、上下文增强、模型生成、评估回归、服务部署每个环节都能练习到非常适合作为你的第一个AI工程闭环。3.1 项目边界与目标定义动工之前先定边界。我给自己定的范围是只支持单份到几十份PDF简历的导入回答范围限定在简历内容之内不做联网检索不回答与简历无关的问题。这个限制非常关键它能把项目难度控制在合理范围内也让效果评估有明确基准。目标能力拆成三条一是准确召回对某个具体问题能检索到相关度最高的简历段落二是忠实生成答案必须基于检索文本不出现失实内容三是稳定服务能以Web方式访问并且单次问答延迟在合理范围内。三条目标都定义了可被验证的行为标准后续所有开发工作都围绕这三条展开。3.2 数据准备与知识库构建数据准备阶段我先是准备了十几份脱敏简历PDF。你不用纠结数据量少这个项目的重点是链路验证而不是刷大数据量。但为了覆盖不同情况建议你的测试数据里包含排版整齐的简历、表格形式的简历、扫描效果的PDF各几份这样才能暴露解析问题。解析PDF我用的工具组合是pypdf和unstructured。pypdf负责纯文本型PDF的快速提取unstructured负责处理表格和复杂布局某些识别不出来的位置会转为图片存储。解析之后得到的原始文本千万不要直接塞给模型还要做清洗去掉页眉页脚、多余空行、乱码字符把英文名的全角和半角统一。这一步脏活累活占用了整个项目三分之一的时间但它是后面所有环节质量的基础。清洗干净的文本进入分块环节。分块策略直接决定检索质量我是按语义段落来切每块控制在300到500个token左右块之间保留约50个token的重叠防止关键信息正好被切成两半。分块完成后对每一块生成向量。我用的嵌入模型是bge-m3的中文版本检索效果在同量级模型里算很稳的如果不想自己部署也可以直接调用商用embedding API。所有向量写入Chroma数据库同时把原文片段和文档名作为元数据一并存入方便后续追溯答案来源。3.3 RAG链路搭建与调优知识库就绪后搭建RAG链路。用户问题进来之后先做一次向量检索从库里召回最相关的8到10个文本块然后把这些文本块按照相关度排序拼进Prompt交给大模型生成答案。链路本身不复杂真正的调优点在检索质量和Prompt设计上。检索调优我经历了几个版本。第一版直接用向量相似度召回效果差强人意有些问题的关键词在简历里是同一句式但语义上是对不上的。后来我在召回阶段加了一层关键词过滤先根据问题里的核心实体比如“Python”“五年”这种词做粗筛再对粗筛结果做向量排序召回准确率提升非常明显。另外向量检索使用的top-k我最终定为8太少会漏上下文太多会把不相关的内容混进来干扰模型判断。Prompt设计同样重要。我的系统提示词里明确写了三条规则只依据提供的简历段落回答如果段落里没有信息直接说“简历中未找到相关信息”回答中尽量引用原简历中的项目和年限描述。这几条看起来简单但能有效压制模型的自由发挥倾向把“我认为”“大概”这类不靠谱的补全行为降到最低。每次改Prompt之后都跑一遍评测集靠数据确认效果而不是靠感觉。3.4 本地部署与服务化链路在Notebook里跑通之后下一步是服务化。我用了FastAPI写接口层核心逻辑封装成一个RAGEngine类对外暴露两个接口一个用于导入新增简历一个用于问答。接口层与业务逻辑分离后续就算换掉向量库或模型组件接口调用方感知不到变化。Docker部署时踩了个典型的坑原版的镜像体积非常大因为基础镜像里带了CUDA全套工具而推理只需要运行时库。后来我改成两阶段构建编译阶段用一个带全量依赖的镜像运行阶段用精简镜像只复制依赖和代码镜像尺寸直接砍掉了一半还多。GPU环境下记得加--gpus all参数并且显存不充裕时在配置文件里限制模型的最大生成长度。到这里项目已经具备最终交付形态数据导入、加工、建库、检索、增强、生成、服务全部打通。你完全可以把这一套流程当成一个模板换成法律合同、产品手册、论文库之类的其他文档一个全新的AI问答工具就搭出来了。4. 常见问题与排错实录项目做下来问题一个接一个我把最有代表性的几个整理出来每个都附带我的排查思路和最终解决方案希望能帮你省掉几天的摸索时间。4.1 模型效果差先查数据还是先调参这是排错顺序问题我自己的经验是八成以上的效果问题根源根本不在模型参数而在数据链路。有一次我对某个候选人的项目经历提问模型回答完全驴唇不对马嘴我第一反应是调整检索的top-k和重排逻辑折腾了两个小时效果依旧不佳。后来回去看原始简历发现这一页在PDF解析时表格错位了项目经历和技能描述混在同一行整块内容都是乱的。正确的排查顺序应该是先确认知识库里存的内容本身是否准确看原始文档解析是否有误文本清洗是否有遗漏然后检查检索环节是否能把包含答案的块召回最后才去动Prompt和模型参数。每一步都要有中间输出可以观测比如转存的清理后文本、向量库里的片段、每次检索返回的结果把这些中间产物打印出来或者落盘问题定位会快很多。另外一个经常被忽略的坑是测试数据太单一。你拿同一份简历反复问十个问题觉得效果不错就以为系统没问题。但换一份格式不同的简历整套检索完全失效的情况在我项目里发生过多次。测试样本至少要覆盖多种格式和异常情况评估才算有效。4.2 部署阶段的内存与延迟问题本地调试时一路顺畅部署之后在低配机器上频频OOM这是入门级部署最常见的遭遇。主要原因是加载模型、向量库和Web服务各自吃掉一块内存小机器根本扛不住。我的第一处理方案是分进程部署把向量检索和模型推理拆成两个服务让大模型进程独占内存敏感资源。如果还不行就只能在模型选择上做文章换更小的量化模型好在像Qwen和Llama这类模型都有提供4bit量化版本效果损失在可接受范围内。延迟方面常常被忽视的是首Token延迟和总生成时间这两个指标的区别。对话型应用更看重首Token延迟交互体感强离线批处理则在乎总吞吐。我自己做的一个优化是把模型的max_tokens从默认的2048调到512因为简历问答场景中大多数答案不会超过两三百字限制生成长度之后单次请求的总耗时下降了一半。别忘了还有一个免费的性能优化点在检索不到相关内容时直接让程序返回预设的“未找到相关信息”不需要走完整的模型推理流程这个逻辑能拦截掉相当比例的无效请求。4.3 评估指标怎么选才不骗自己最后聊聊评估。很多人一上来就研究精确率、召回率、F1值但对一个问答系统来说这些指标要么不适用要么定义起来非常模糊。我最终搭的评估框架非常简单准备一个包含内容覆盖、正确性、忠实度、完整性四个维度的评分卡每个维度一到五分让三个不同的人分别打分。内容覆盖是看系统是否能从简历里找到相关片段正确性是看答案是否和简历事实一致忠实度是看答案是否胡编了原文没有的信息完整性是看该说的要点是不是说全了。这个评分框架跑下来比任何单一量化指标都更能反映真实质量。特别要强调忠实度这个维度它是LLM应用和传统分类任务最大的不同点。传统模型的错误往往是分类错误LLM的错误则可能是一本正经地编造这种错误对用户伤害极大。我后来在Prompt里强制要求“如果简历中没有明确信息必须回答未找到”并把包含虚构信息的评测用例单独列成一个回归集每次改动系统时先跑这个回归集极大避免了模型“学坏”。评估时还要注意“测试集污染”就是用过的评测样例反复跑模型和检索逻辑过度拟合这些样例表面看评测分数越来越高实际上换一批新问题立刻现原形。养成定期更新评测集的习惯哪怕每次只替换一两个样本也能有效防止自欺欺人。最后再分享一个小技巧把这些评测结果和每次变更记录放在同一个目录下用日期命名文件。过一个月再回头翻你能清晰地看到每一次修改带来的真实变化也能回忆起当时为什么要做某个改动。AI工程这条路上你留下的评测记录就是帮你持续做出正确决策的最可靠依据。
AI工程从零到实战：数据、RAG与部署全流程指南
1. 先搞清楚AI工程到底在解决什么问题我从这个标题里读出的第一层信息是AI工程从来不是某一个单一技能而是把模型变成可用系统的那一整条链路。很多人一听到AI engineering第一反应是“会训练模型”或者“会写Python调用API”但真正干过几个项目之后会发现训练和调用只占整个工作量的三分之一不到剩下的时间几乎都耗在数据处理、效果调优、接口对接、部署上线以及无穷无尽的问题排查上。如果你是个刚入行的新人或者一个想把自己的想法用AI落地的工程师我建议先别急着装PyTorch、买显卡而是花点时间想清楚“AI工程”这个词拆开之后的味道。工程意味着可复现、可测试、可维护、可交付。它不像做实验模型指标差不多就行工程要的是别人拿着你的代码搭好环境按下开关系统能稳定跑起来并且产出质量可控的结果。1.1 从模型训练到系统交付中间缺的不是魔法我见过很多人的误区包括我自己刚入行时也踩过以为AI项目最难的是模型本身于是花几个月死磕Transformer源码、手写反向传播结果一到真正做项目卡在“如何把一份PDF简历变成干净的文本”“如何让大模型回答不胡编”“如何让接口延迟控制在两秒内”这种一点都不性感的问题上。这是典型的把AI工程约等于模型训练的误解。模型训练尤其是今天大家都在用的基于预训练模型做微调或者直接做推理增强难度已经比五年前低了很多。HuggingFace上随便拉一个开源模型几行代码就能跑起来商用API更是开箱即用。真正拉开差距的是把模型嵌进业务系统后那些围绕模型展开的数据治理、评测体系、链路设计、性能优化和成本控制。打个比方模型像发动机AI工程是整车制造。发动机是核心技术但一辆能上路的车需要油箱、变速箱、底盘、刹车、车机系统以及一整套安全测试。现实是大多数业务的痛点根本不在发动机而在整车的协调性和可靠性。从零开始学AI工程说白了就是学怎么造整车而不是只盯着发动机。1.2 为什么“从零开始”是一条更靠谱的路线这个标题里的“from scratch”非常关键。市面上太多速成课程教你三天调用ChatGPT接口就算会AI了。这种学习方式最大的问题是根基不稳一遇到新模型、新框架、新业务场景就彻底歇菜。从零开始意味着你要亲手把每个环节走一遍自己写过数据清洗脚本才理解脏数据对效果的杀伤力有多大自己搭建过向量检索才知道索引参数和分块策略有多讲究自己亲手部署过推理服务才知道显存占用和并发吞吐之间要如何权衡。这些“亲手踩过”的经验是任何速成课都给不了的。我推荐的学习节奏是线性推进先掌握最核心的Python基本功再理解模型推理和微调的原理然后重点突破工程化四件套——数据、评估、部署、运维。每一步都配合一个极小的项目练手不要跳步。等到这条链路走通两三次你会发现自己再看任何新的AI技术都能很快定位它在链路中的位置学习速度会快很多。2. 学习路线与工具选型照着抄就行从零开始最大的困扰不是不知道要学什么而是网上信息太杂一会儿有人让你学深度学习数学基础一会儿有人让你直接上手LangChain一会儿又有人吹低代码平台。我的建议是把学习目标明确拆成三个阶段每个阶段的工具都控制在最小集内学完一个阶段立刻做一个小项目固化下来。2.1 第一阶段把地基打牢别嫌枯燥这一阶段我建议只用两个工具Python和Git。Python不用说了AI生态的通用语言。这里说的不是会写个for循环就行至少要有能力写清晰的数据处理脚本。具体来说要熟练掌握字典和列表的嵌套操作、文件读写、异常处理、函数式编程里的map和filter、面向对象的基本封装。推荐把Pandas和NumPy的基础操作也练熟因为后面所有数据清洗都会用到。Git的作用很多人低估了。做AI项目代码迭代速度极快数据、配置、Prompt、模型版本都在频繁更改没有版本控制基本是灾难。我见过不止一个团队因为配置文件和Prompt没有纳入git管理出了问题只能靠记忆回退最后浪费大量时间。建议至少掌握add、commit、branch、merge、revert这几个操作再配合一个Git托管平台使用。可以新建一个名为ai-engineering-practice的空仓库后面每个练习项目都放进去日积月累就是很宝贵的资产。这个阶段还要补一点命令行和Linux基础不需要到运维工程师的水准但至少会切换目录、操作文件、装Python包、看进程和显存占用。因为后面部署和调试GPU服务时你大概率要面对一台无图形界面的Linux服务器。2.2 第二阶段模型与框架动手跑起来比死磕理论重要第二阶段开始接触模型。我强烈建议选PyTorch作为主框架生态最全遇到问题搜解决方案也最容易。开始不要读大部头理论书先跑通一段推理代码用HuggingFace的transformers库加载一个中小型开源模型跑一次文本分类或者对话生成感受一下输入输出的完整流程。这一步的核心目标是理解模型推理的基本链路而不是理解模型内部的每一个数学推导。理论学习只需要三个点一是tokenization明白文本是怎么被切成token并映射成id的二是attention机制存在的意义明白模型为什么能捕捉上下文关系三是softmax和温度参数明白模型的输出概率是如何变成最终文本的。这三个点搞明白你就足够继续往前走了。反向传播和预训练目标等细节可以放到后续项目中带着问题去补一上来啃这些大概率劝退。跑通推理之后可以尝试微调。优先用LoRA之类的高效微调方法消费级显卡也能跑得动。找一个小规模的开源模型和一个几百条的领域数据集把原本只会通用对话的模型微调成能够识别你领域关键词的模型。做这个项目时你会接触到训练循环、损失函数、学习率、epoch等概念这才是有体感的理解比刷十遍理论课都深刻。2.3 第三阶段工程化三件套数据、评估、部署这阶段是AI工程的核心分水岭。数据方面的核心技能是清洗与构造。真实场景的数据永远比教程数据集脏你要学会处理缺失值、重复值、格式混乱、编码问题。对一个文档型RAG系统来说还要掌握拆分、解析、去重、转向量。推荐学习unstructured、BeautifulSoup这类解析库以及Chroma、FAISS这类轻量向量库。不要一上来就上分布式大数据技术绝大多数项目的数据量用不到反而徒增复杂度。评估是很多自学者最容易忽略的一环。模型效果好不好不能靠“感觉还行”来判断。至少要搭建一个小小的评测集准备二三十组输入和预期输出每次改动Prompt或者检索逻辑都跑一遍评测集用人工打分或者规则打分的方式记录效果变化。养成这个习惯之后你调优就不会再靠碰运气每次改动都有了可靠的反馈信号。部署方面先掌握FastAPI和Docker。用FastAPI把模型推理封装成一个HTTP接口然后写一个Dockerfile把环境和依赖打包成镜像。如果GPU资源够推荐了解vLLM这类推理加速框架如果资源有限用Ollama也能迅速部署本地模型服务。这个阶段的目标是做到“把项目打包交出去别人能一键跑起来”到了这一步你已经具备最基本的AI工程交付能力。3. 用一个小项目走通全流程简历问答助手理论聊再多都不如亲手做一遍。我选一个非常适合从零起步的练手项目简历问答助手。输入是一批简历文档用户可以问“候选人JAVA经验几年”“谁最适合前端岗位”系统从简历里检索相关片段调用模型生成回答。这个项目麻雀虽小五脏俱全数据解析、文本分块、向量检索、上下文增强、模型生成、评估回归、服务部署每个环节都能练习到非常适合作为你的第一个AI工程闭环。3.1 项目边界与目标定义动工之前先定边界。我给自己定的范围是只支持单份到几十份PDF简历的导入回答范围限定在简历内容之内不做联网检索不回答与简历无关的问题。这个限制非常关键它能把项目难度控制在合理范围内也让效果评估有明确基准。目标能力拆成三条一是准确召回对某个具体问题能检索到相关度最高的简历段落二是忠实生成答案必须基于检索文本不出现失实内容三是稳定服务能以Web方式访问并且单次问答延迟在合理范围内。三条目标都定义了可被验证的行为标准后续所有开发工作都围绕这三条展开。3.2 数据准备与知识库构建数据准备阶段我先是准备了十几份脱敏简历PDF。你不用纠结数据量少这个项目的重点是链路验证而不是刷大数据量。但为了覆盖不同情况建议你的测试数据里包含排版整齐的简历、表格形式的简历、扫描效果的PDF各几份这样才能暴露解析问题。解析PDF我用的工具组合是pypdf和unstructured。pypdf负责纯文本型PDF的快速提取unstructured负责处理表格和复杂布局某些识别不出来的位置会转为图片存储。解析之后得到的原始文本千万不要直接塞给模型还要做清洗去掉页眉页脚、多余空行、乱码字符把英文名的全角和半角统一。这一步脏活累活占用了整个项目三分之一的时间但它是后面所有环节质量的基础。清洗干净的文本进入分块环节。分块策略直接决定检索质量我是按语义段落来切每块控制在300到500个token左右块之间保留约50个token的重叠防止关键信息正好被切成两半。分块完成后对每一块生成向量。我用的嵌入模型是bge-m3的中文版本检索效果在同量级模型里算很稳的如果不想自己部署也可以直接调用商用embedding API。所有向量写入Chroma数据库同时把原文片段和文档名作为元数据一并存入方便后续追溯答案来源。3.3 RAG链路搭建与调优知识库就绪后搭建RAG链路。用户问题进来之后先做一次向量检索从库里召回最相关的8到10个文本块然后把这些文本块按照相关度排序拼进Prompt交给大模型生成答案。链路本身不复杂真正的调优点在检索质量和Prompt设计上。检索调优我经历了几个版本。第一版直接用向量相似度召回效果差强人意有些问题的关键词在简历里是同一句式但语义上是对不上的。后来我在召回阶段加了一层关键词过滤先根据问题里的核心实体比如“Python”“五年”这种词做粗筛再对粗筛结果做向量排序召回准确率提升非常明显。另外向量检索使用的top-k我最终定为8太少会漏上下文太多会把不相关的内容混进来干扰模型判断。Prompt设计同样重要。我的系统提示词里明确写了三条规则只依据提供的简历段落回答如果段落里没有信息直接说“简历中未找到相关信息”回答中尽量引用原简历中的项目和年限描述。这几条看起来简单但能有效压制模型的自由发挥倾向把“我认为”“大概”这类不靠谱的补全行为降到最低。每次改Prompt之后都跑一遍评测集靠数据确认效果而不是靠感觉。3.4 本地部署与服务化链路在Notebook里跑通之后下一步是服务化。我用了FastAPI写接口层核心逻辑封装成一个RAGEngine类对外暴露两个接口一个用于导入新增简历一个用于问答。接口层与业务逻辑分离后续就算换掉向量库或模型组件接口调用方感知不到变化。Docker部署时踩了个典型的坑原版的镜像体积非常大因为基础镜像里带了CUDA全套工具而推理只需要运行时库。后来我改成两阶段构建编译阶段用一个带全量依赖的镜像运行阶段用精简镜像只复制依赖和代码镜像尺寸直接砍掉了一半还多。GPU环境下记得加--gpus all参数并且显存不充裕时在配置文件里限制模型的最大生成长度。到这里项目已经具备最终交付形态数据导入、加工、建库、检索、增强、生成、服务全部打通。你完全可以把这一套流程当成一个模板换成法律合同、产品手册、论文库之类的其他文档一个全新的AI问答工具就搭出来了。4. 常见问题与排错实录项目做下来问题一个接一个我把最有代表性的几个整理出来每个都附带我的排查思路和最终解决方案希望能帮你省掉几天的摸索时间。4.1 模型效果差先查数据还是先调参这是排错顺序问题我自己的经验是八成以上的效果问题根源根本不在模型参数而在数据链路。有一次我对某个候选人的项目经历提问模型回答完全驴唇不对马嘴我第一反应是调整检索的top-k和重排逻辑折腾了两个小时效果依旧不佳。后来回去看原始简历发现这一页在PDF解析时表格错位了项目经历和技能描述混在同一行整块内容都是乱的。正确的排查顺序应该是先确认知识库里存的内容本身是否准确看原始文档解析是否有误文本清洗是否有遗漏然后检查检索环节是否能把包含答案的块召回最后才去动Prompt和模型参数。每一步都要有中间输出可以观测比如转存的清理后文本、向量库里的片段、每次检索返回的结果把这些中间产物打印出来或者落盘问题定位会快很多。另外一个经常被忽略的坑是测试数据太单一。你拿同一份简历反复问十个问题觉得效果不错就以为系统没问题。但换一份格式不同的简历整套检索完全失效的情况在我项目里发生过多次。测试样本至少要覆盖多种格式和异常情况评估才算有效。4.2 部署阶段的内存与延迟问题本地调试时一路顺畅部署之后在低配机器上频频OOM这是入门级部署最常见的遭遇。主要原因是加载模型、向量库和Web服务各自吃掉一块内存小机器根本扛不住。我的第一处理方案是分进程部署把向量检索和模型推理拆成两个服务让大模型进程独占内存敏感资源。如果还不行就只能在模型选择上做文章换更小的量化模型好在像Qwen和Llama这类模型都有提供4bit量化版本效果损失在可接受范围内。延迟方面常常被忽视的是首Token延迟和总生成时间这两个指标的区别。对话型应用更看重首Token延迟交互体感强离线批处理则在乎总吞吐。我自己做的一个优化是把模型的max_tokens从默认的2048调到512因为简历问答场景中大多数答案不会超过两三百字限制生成长度之后单次请求的总耗时下降了一半。别忘了还有一个免费的性能优化点在检索不到相关内容时直接让程序返回预设的“未找到相关信息”不需要走完整的模型推理流程这个逻辑能拦截掉相当比例的无效请求。4.3 评估指标怎么选才不骗自己最后聊聊评估。很多人一上来就研究精确率、召回率、F1值但对一个问答系统来说这些指标要么不适用要么定义起来非常模糊。我最终搭的评估框架非常简单准备一个包含内容覆盖、正确性、忠实度、完整性四个维度的评分卡每个维度一到五分让三个不同的人分别打分。内容覆盖是看系统是否能从简历里找到相关片段正确性是看答案是否和简历事实一致忠实度是看答案是否胡编了原文没有的信息完整性是看该说的要点是不是说全了。这个评分框架跑下来比任何单一量化指标都更能反映真实质量。特别要强调忠实度这个维度它是LLM应用和传统分类任务最大的不同点。传统模型的错误往往是分类错误LLM的错误则可能是一本正经地编造这种错误对用户伤害极大。我后来在Prompt里强制要求“如果简历中没有明确信息必须回答未找到”并把包含虚构信息的评测用例单独列成一个回归集每次改动系统时先跑这个回归集极大避免了模型“学坏”。评估时还要注意“测试集污染”就是用过的评测样例反复跑模型和检索逻辑过度拟合这些样例表面看评测分数越来越高实际上换一批新问题立刻现原形。养成定期更新评测集的习惯哪怕每次只替换一两个样本也能有效防止自欺欺人。最后再分享一个小技巧把这些评测结果和每次变更记录放在同一个目录下用日期命名文件。过一个月再回头翻你能清晰地看到每一次修改带来的真实变化也能回忆起当时为什么要做某个改动。AI工程这条路上你留下的评测记录就是帮你持续做出正确决策的最可靠依据。
