1. 从零开始不是从Transformer开始先辨清AI工程的学习地图先说个我经常遇到的场景。今年有好几个朋友来问我说自己想转行做AI买了深度学习教材准备从反向传播、Transformer结构开始啃问我这个路线对不对。我的回答通常让他们意外你要是想做AI工程师最不该花大量时间的就是从零手推Transformer。不是说原理不重要而是从零开始学AI工程和从零开始研究AI算法是两条完全不同的路。很多人把这两件事搞混了结果学了三个月数学发现自己连一个能跑起来的应用都没做出来挫败感极强。1.1 算法工程师和AI工程师干的是完全不同的两件事打个比方。算法工程师研究的是怎么让模型更聪明。他们关心的是这个模型结构能不能改一改训练数据要不要再加大Loss函数是不是可以设计得更好他们的交付物是更好的模型权重和证明这个模型有效的实验报告。AI工程师关心的是怎么让模型在真实环境里持续稳定地干活。他们的交付物是一个别人真能打开用、在业务里创造价值的系统。同样一个模型算法工程师交到AI工程师手里之后要考虑的是模型怎么部署并发大了怎么办用户问的问题不在知识库里怎么答有没有幻觉改了一个Prompt会不会影响其他问答每个月光调模型API要烧多少钱所以AI工程里的从零开始本质是从零开始搭建一套能让AI模型稳定产出价值的工程系统而不是从零开始推导Attention机制。前者是工程问题后者是科研问题。1.2 真正的从零是走完一条端到端链路我见过太多所谓的AI项目半途而废原因惊人的一致卡在不知道下一步该干什么。会调一个ModelScope上的开源模型但不知道数据怎么弄知道LangChain能串流程但文档看了两章就开始犯困。其实把一个AI应用落地拆到最粗也就五步明确问题这个应用解决谁的什么痛点答错了损失有多大。准备数据知识从哪来怎么清洗怎么切分怎么向量化。构建核心链路检索还是生成走RAG还是微调Prompt怎么写。评估与迭代怎么量化回答得好不好怎么发现模型在哪些问题上翻车。部署与运维服务怎么起并发怎么扛日志怎么查成本怎么控。只要这五步完整走通一遍——哪怕做了一个功能极其简单的小工具——你就已经具备了从零开始做AI工程的骨架。后面所有的进阶都是往这个骨架上填肌肉。如果你现在刚开始我建议你用两周时间把上面这条链路走通一遍走的越笨越好先别追求花哨。1.3 学习顺序建议让第一个项目在两周内落地我整理一下给新人的建议顺序这和我当年自学时的路线不同——当年顺序反了走了不少弯路。第一周找一个足够窄的问题准备几十份真实文档搭一个最小RAG链路跑通提问-检索-生成-回答全过程。工具链直接用现成的开源Embedding模型加一个向量库加一个LLM API。第二周建立评估集找30到50个真实问题把每次回答记录下来逐条看失败原因调整切分策略和Prompt。做完这两件事你对AI工程的体感会比啃三个月理论强得多。后续带着实际项目中遇到的瓶颈去补理论。比如发现检索效果差就去学Embedding和重排原理发现模型回答稳定性差就去研究Prompt工程和模型微调的边界。让项目问题当老师这是我最推荐的路径。2. 第一个闭环把一个200页的内部手册变成问答助手理论说了不少接下来我用一个我自己做过的真实项目来走一遍完整链路。这个项目的需求特别简单公司内部有一本差不多200页的《客户服务操作手册》新人培训期总是翻不着东西——文档是PDF搜索靠CtrlF目录还经常过期。我给它做成一个问答助手让它能回答某某业务类型的标准处理时效是多久遇到投诉升级的流程是什么这类问题。这个小项目我后来反复推荐给想入门AI工程的人因为它的复杂度刚刚好有点真实业务价值不会大到失控又足够覆盖全链路。2.1 为什么选择RAG而不是微调当时我第一个念头绝对不是训练一个模型。200页操作手册哪怕把它微调进一个7B模型里风险也非常大手册内容经常更新微调一次成本高、周期长而且微调模型很容易在事实性问题上胡编。你要的是一个随时能更新知识的系统不是一个背熟了某版教材的学生。所以选了RAG检索增强生成Retrieval-Augmented Generation。核心思路一句话每次回答问题前先从文档库里把最相关的几个片段检索出来把这些片段连同问题一起交给大模型生成答案。模型不依赖记忆回答而是看着资料回答这就把答案过时和胡编的风险降低了非常多。你不需要让模型提前记住你的手册你只需要让它在回答的瞬间查得到、查得准。2.2 最小闭环拆解五个环节依次打通这个项目我没有用现成全家桶框架因为当时想的是把每个环节都摸清楚——后来证明这个决定极其正确。整体长这样文档加载把PDF逐页解析成文本手动抽查了目录、表格、页眉页脚有没有被正确识别。文本切块按固定长度切块每个块大约600 token块与块之间重叠80 token。向量化用开源的Embedding模型把每块文本转成一串向量存进向量库。检索用户提问时把问题也转成向量在向量库里做相似度搜索取前5个最相关片段。生成把检索到的片段和用户问题塞进一个结构化的Prompt模板由大模型生成回答。下面是当时核心的检索函数我简化了框架代码保留最直接的逻辑def retrieve_and_answer(query: str, top_k: int 5) - dict: # 1. 把用户问题转成向量 query_vec embedding_model.encode(query, normalize_embeddingsTrue) # 2. 在向量库里做相似度搜索 hits vector_db.search(query_vec, top_ktop_k) # 3. 拼装上下文这里有个细节控制检索片段的总长度 context_parts [] for hit in hits: context_parts.append( f[来源{hit[source]}第{hit[page]}页]\n{hit[text]} ) context \n\n---\n\n.join(context_parts) # 4. 组装Prompt并调用模型 prompt build_prompt(queryquery, contextcontext) answer llm.chat(messages[{role: user, content: prompt}]) return {answer: answer, context: context_parts}这里有个细节我想特别说一下检索结果的排序逻辑不能只看得分。很多向量库默认按距离排序但如果你做了多路召回比如同时用了关键词和向量一定要自己定义合并策略。我后来在这个小项目里就因为这个栽过跟头后面会细说。五个环节全部打通大约花了一个周末。第一个完整回答生成出来的时候说实话有点激动——它答对了标准时效是24小时这句这在以前得翻十几页PDF才找得到。2.3 评估基线跑通之前先想好怎么算有效这个项目起步时最容易犯的错误是我自己差点犯的Demo能出答案就觉得大功告成。实际上能出答案和能稳定出对答案之间差着十万八千里。我做了一个最原始的评估集找业务同事要了40条真实的用户问题覆盖手册里各个章节比如客户投诉三次以上怎么办退款审批链路上有几个节点。然后人工给每一条标了答案出处和预期要点。用这套评估集跑一遍记录下来每个问题答得好不好作为基线。评判标准也简单粗暴三个等级达标核心要点答对了人也看得懂。及格方向没错但漏了关键细节。翻车答错或答非所问。第一轮测下来达标率大概只有三成。一半以上的问题翻车原因集中在两类一是检索出来的上下文里压根没有正确答案检索失败二是上下文里有答案但模型没提取出来生成失败。这两类问题后面去修的方向完全不同所以没有评估集就调优等于闭着眼开车。3. 数据管线的细节盲区文档清洗、切块粒度与Embedding选型说句得罪人的话大部分AI项目做不好不是模型选得不好而是数据管线太糙。RAG这个技术看着简单真正把文档变成可检索片段这一步做好的人十个里面没有一个。3.1 PDF解析常见的三种坑PDF大概是这个世界上最不适合做文本提取的格式。我当时用的解析工具看着挺美真正跑起来就露馅了。表格乱序手册里有个业务流程时限一览表解析出来完全成了天书数字都挤在一行里。这是PDF处理中最常见的坑——表格和分栏布局的还原依赖工具能力。最后我单独把这类表格截图、用OCR提取成结构化文本再按原始表头重新拼接才解决。页眉页脚污染每页顶部都在重复客户服务操作手册V3.2切块之后有五六块内容是纯页眉检索时白白占掉上下文槽位。清洗阶段要把这些高频重复内容筛掉一个简单的办法是统计全文中出现次数最多的片段手动确认后全局删除。文字错位页边距和特殊字符偶尔导致句子断行比如标准时效是2\n4小时检索到了也影响大模型理解。清洗时要加一道连字符和断行处理把孤零零的数字与下一行拼起来。如果你处理的是Word文档一般比PDF好很多但也要注意批注、修订模式和目录页——历史版本的修订痕迹混进知识库检索出来是会误导模型的。3.2 切块策略决定检索上限的第一道关卡切块Chunking是整个数据管线里最考验经验的一个环节。切太碎了语义被切断检索返回一堆碎片切太大了一个块里塞了太多无关内容向量化之后互相干扰检索精度也下降。当时我做了三组对比这里直接给结果策略参数达标率问题表现固定256 token重叠2052%常见于大段落语义被拦腰截断检索结果零碎上下文里关键信息不完整固定600 token重叠8067%整体均衡长段落完整短段落有点浪费按标题语义切分以三级标题为边界块上限1000 token71%效果最好但也要求源文档本身结构规范最后一组方案改动了更多先用标题层级做逻辑分组如果某小节内容太长再按固定长度切。这样每一块基本对应一个独立主题检索命中时的信息密度最高。另外不要只依赖一种切法。现实中的文档很杂条款类适合大块切问答类适合小块切。你可以按文档类型设定不同的切块规则在元数据里标记类型检索时再决定优先取哪种块。这个思路比全局统一参数要先进得多。还有一点重叠overlap不是越大越好。重叠是为了让跨块语义不丢失但重叠过大会让相邻块的内容大量重复检索时可能返回五个块但其实内容几乎一样。我的经验是从80到150 token开始你的如果低于50效果通常不理想。3.3 Embedding和向量库的选型参考中文场景下Embedding模型的选型直接决定检索质量的下限。我当时做过一批实测对比用了40条测试问题用召回率衡量效果数据大概是这样的模型维度中文效果说明BGE-M31024很好开源、多语言、支持稀疏与稠密检索混合成本为零中文场景首选text-embedding-3-small1536良好OpenAI也好用但要花钱适合不想管部署的团队M3E-base768良好中文专项训练的早期方案速度够用但效果略逊BGE-M3通用英文模型如MiniLM384差中文效果明显拉胯个人非常不推荐我的建议很直接预算允许就选BGE-M3用开源的不丢人效果是实打实的。部署一个Embedding模型不需要GPUCPU跑就已经很快了几百兆的模型而已。向量库层面我当时的排序和后来给团队的建议基本一致数据量在百万片段以下直接上FAISS或者Chroma。少一个组件就少一个故障点项目初期不需要自建向量数据库。考虑未来多租户和权限过滤用pgvector搭配PostgreSQL最合适省一套基础设施。数据规模到了千万级别或者需要毫秒级海量并发再考虑Milvus这类专业向量数据库。千万别为了用Milvus而用Milvus。我见过有人数据才几万条就上了四节点的分布式向量库纯属给运维添堵。4. 检索增强生成里最容易被低估的两件事召回质量与Prompt护栏RAG的核心命门就两个拷出来的材料准不准召回质量和模型的作答稳不稳Prompt设计。这两件事看起来谁都会做但踩坑的人前赴后继。4.1 向量检索的我以为和实际上一开始我以为向量检索很智能输入投诉了三天没人管怎么办就能自动找到投诉升级处理流程那一章。实测发现向量检索的语义匹配能力被严重高估了——它对换词表达、专业术语简称、数字范围的敏感度都很差。比如手册里写一级投诉响应时限15分钟用户问的是客户炸了得多久回应向量检索很可能把最相关的片段排到第8名开外。TopK取得不够大时正确答案根本进不了上下文。这就是第一个经验TopK不能拍脑袋定死。我当时基准设5后来根据评测集调到10搭配上下文长度裁剪效果好了不少。另外一个很多人没意识到的问题相似度阈值设得太激进了。向量检索返回的相似度分数在0到1之间如果问题完全属于手册覆盖范围返回片段分数通常高于0.45如果问的是无关问题分数可能只有0.3。低于阈值宁可告诉用户这个问题我暂时无法回答也不要硬答。这是最便宜的一层护栏。4.2 混合检索与重排效果提升最直接的组合拳我前面提到的翻车问题后来是用混合检索治好的。做法很简单同时跑两路检索——一路是向量检索找语义相近的内容另一路是BM25关键词检索找精确匹配的内容比如24小时三级审批V3.2这类硬信息。然后把两路结果合并根据得分做加权排序。这个优化做起来不难收益却非常直接。尤其是处理操作手册这类术语密度高、数字多的文档BM25能弥补向量检索在精确匹配上的天然短板。如果还想再进一步可以在合并排序后加一层重排Rerank。经典的方案是用Cross-Encoder模型把每个候选片段和用户问题拼在一起让模型算相关性精度更好但延迟也会明显上升。小项目里我的经验是先用混合检索效果不够再加重排不要一上来就上全套。重排模型推荐开源的BGE-Reranker系列部署简单实测有效。检索链路最终调到什么程度算合格我个人习惯用一个很土的验收指标把评测集里每个问题对应的标准答案段落保证在检索结果前3位出现命中率至少80%。达不到这个标准后面Prompt写得再好也白搭——巧妇难为无米之炊。4.3 Prompt不是写作文结构、示例与护栏设计很多新手把Prompt写成一堆客套话什么你是一个专业助手请用礼貌的语气帮助用户解决问题。这类废话对模型输出质量的影响几乎为零。真正起作用的是以下四个要素角色和边界明确告诉模型你是公司内部知识库问答助手只能依据提供的资料回答。这能有效降低越界答题。严格的引用约束要求如果资料中没有答案必须直接说明无法回答禁止编造。这是对抗幻觉最有用的指令但光说不做也不行最好再给一个错误示范。来源标注要求回答末尾标注基于的文档来源和页码。一旦答错排查和追责都方便更重要的是能反向定位是检索问题还是生成问题。Few-shot示例给模型一两条结构完美的回答示例比写十句请认真负责地回答有效得多。要知道模型的学习能力在这个层面非常敏感一个标准答案的样子胜过一堆形容词。我还遇到过一个特别典型的坑某个业务问题本身包含了两层意图比如投诉升级后客户要求赔偿这个流程要多久模型只答了一半。后来在Prompt里要求如果问题涉及多个流程环节必须分点逐项回答这个问题才改善。Prompt的调试必须靠评测集驱动的失败案例来反推不能拍脑袋想到什么加什么。另外一个容易被忽略的细节是上下文裁剪。当你用混合检索拿到Top10片段时全部塞进Prompt会超长也浪费token。我的做法是先硬截断掉明显低分的片段再保留总分靠前但总token数不超过上下文的实际限制比如4096并留出足够空间给回答输出。如果前5个片段已经占了3000 token硬塞10个就是自杀式设计。5. 从本地能跑到上线可用模型服务化、缓存观测与成本清单Demo人人都能做差距在把东西端出去。这一章讲的都是没人带你、你自己绝对容易忽略的硬功夫。5.1 模型服务化的正确姿势我当时把大模型服务包了一层FastAPI用Docker容器化部署到内部服务器。核心流程是用vLLM起一个OpenAI兼容接口的模型服务吞吐比原版推理框架高很多。应用层单独起一个服务负责检索、拼接Prompt、调用模型接口。两个服务只通过HTTP通信互不干扰。模型更新时只换容器应用逻辑不用动。这里有一条经验值得单独提出来如果不是对延迟极度敏感优先用vLLM开一个共享服务而不是每个应用单独拉一个模型加载到GPU上。因为一次模型加载就要占十几GB显存多个应用各拉一份是对GPU资源的极大浪费。早年间我见过团队同时跑了三个模型实例每张卡都顶着上限后来统一收敛到一个共享网关才喘过气来。如果你的模型不用那么大想压在消费级显卡上可以考虑量化方案。AWQ、GPTQ这类4bit量化能把7B/13B模型压到6-8GB显存质量损失在可接受范围内。但这里有个前提量化后的模型必须在评测集上重新测一遍有些任务的输出质量会掉得很明显不能只看显存占用觉得能跑就行。5.2 响应体验的隐形功臣缓存与并发策略上线第一周我就发现一个问题80%的高频提问集中在20个常见问题上。用户问完了不满意改几个字再问一遍本质是同一道题。每次都要重新走检索、重新调大模型等于白白烧钱。解决办法是加缓存。我当时做了两层精确缓存完全相同的问题直接返回历史答案秒开。语义缓存把新问题向量化与缓存里的历史问题进行相似度匹配高于0.95就复用缓存答案。这个优化能把重复提问的响应时间从5秒压到300毫秒月度API成本直接降了小一半。缓存有个容易踩的坑是业务更新。手册内容更新后命中旧缓存的答案会过时。我的解决办法是给缓存打上数据版本号和有效期手册更新时强制失效。另外涉及时效性比较强的问题比如当前处理进度绝对不能走缓存要在Prompt里加时间戳并用代码逻辑跳过。并发这块小项目直接用FastAPI异步接口加信号量控制模型服务请求数量就够了。先用ab工具或Locust压一下接口水平确认你的应用层能扛多久。很多新手一上来就买一堆GPU实例做负载均衡其实瓶颈大概率在检索和模型服务先把这两处链路摸清了再说。5.3 这个项目一个月到底花多少钱成本这块我直接说结论。当时用7B级模型自己有卡加一个Embedding模型主要开销是GPU电费和服务器维护如果完全走商业API则可以按token精确估算。以API方案举例假设一个月有4万次问答每次平均输入2000 token含检索上下文、输出300 token。那么月消耗大概是输入8000万token输出1200万token。按当前常见定价算大模型费用每月在几百到一千元人民币区间。检索和Embedding的开销小到可以忽略。也就是说一个小体量的内部AI问答工具月成本是可控的没必要一上来就花十几万搭集群。成本优化最有价值的方向永远是减少无效请求缓存解决重复提问知识外问题直接拒答不调模型长上下文中可以压缩掉无用片段。这三招做完通常能省30%以上。5.4 上线前必须回答的三个安全提问我习惯在项目上线前问自己三个问题回答不了就不上数据合规性这份手册能不能被模型服务访问模型是私有部署还是云端API内部敏感数据绝对不能混进外部托管的模型服务。当时我们内部手册走的是内网部署的开源模型这台机器不开放外网访问。幻觉冲击力如果模型瞎编了一条规则最坏的结果是什么对于操作手册这类对准确性要求很高的场景我在Prompt里强制要求答案必须逐字引用资料原文并标注来源页码宁可回答保守一些也不能让它自由发挥。日志可追踪每一次回答能不能追溯到哪几段上下文、哪个Prompt版本、哪个模型版本我把这些信息全塞进了结构化日志和数据库表里用户反馈答错了可以一条条追回去。没有这个能力后面做任何优化都等于盲改。这三个问题里第二个最容易被人忽略。很多人只看答对了多少不看答错的后果有多严重。对医疗、法务、设备操作这类场景答错一次可能造成的损失是巨大的。6. 复盘与扩展绕过我踩过的坑走微调还是Agent最后这部分我不打算做总结了就聊点实在的这个项目做完后我复盘出的经验以及想继续往下走的人下一步该往哪边走。6.1 踩坑记录五件让我折腾到凌晨的事PDF表格错乱那页时限一览表我抠了一下午才弄干净。后来wd这些坑的有效手段是对表格型页面用OCR结构化提取不要指望纯文本解析。切块边界切断了修条件手册里如客户要求出具书面证明则须在2个工作日内完成被切到两个块里检索命中率极低。用语义切块替换固定长度之后才好转。向量库默认端口冲突Chroma默认端口和公司另一个服务撞了排查了三个小时。建议所有组件启动时改掉默认端口并写进部署文档。评估集第一版太干净我自己编的问题和真实用户问法差距很大第一次测出来效果很好发给业务同事一测发现全翻车。后来评估集全部改用同事的真实聊天记录和工单标题再也不自己编问题了。Prompt越改越胖每次失败就加一句指令最后Prompt长达两页效果反而下降。痛定思痛把Prompt拆成主干、护栏、示例三个部分每部分单独做A/B测试稳定了再加进来。每一个坑单看都不大但串起来足以消耗掉好几个人日。数据管线、评测集、Prompt版本管理这三件事放在项目第一天做和放到上线前做工作量和心态完全不同。6.2 从RAG到Agent什么情况下值得往前走做完了知识库问答不少人会问下一步是不是直接上Agent我的看法是先把单轮RAG的准确率和稳定性做扎实再考虑Agent的自动规划和多步执行。Agent的价值在于能拆解复杂任务比如帮我统计这个月不同类型投诉的比例并生成一段分析——这需要规划步骤、查数据、写报告。但Agent的复杂性也随之而来模型自己要决定调用哪些工具、步骤对不对、失败了怎么恢复。这些问题在工程上比RAG难了一个量级。我的决策标准很简单如果业务场景主要是查资料问答RAG足够就不要上Agent。如果确实需要多步推理或工具调用比如查数据库、发通知、操作业务系统再考虑Agent框架。如果要用Agent先从单步工具的可靠性验证开始让模型调用一个工具测试它在100种问题下的调用准确率不到90%就不适合做多步编排。微调也是一样的逻辑先用RAG和Prompt解决能解决的问题。只有当模型本身的能力上限成为瓶颈时——比如你希望它按特定风格回复、处理特定领域的复杂推理——才值得花成本微调。RAG解决知道什么微调解决怎么答、能不能推两者不是取代关系。6.3 给后来者的一句实话做完这个项目最深的体会是AI工程从零开始的门槛比想象中低天花板比想象中高。门槛低在你不需要先读完全部论文才能动手两周就能做出一个有用的工具天花板高在从能跑到好用之间有数据质量、检索策略、评估体系、服务治理这一大串工程问题等着你。我个人的建议始终是那句朴素的话先让一个真实的问题被你的AI系统解决掉再考虑优化它。你会在解决第一个问题的过程中发现所有真正值得学的东西。这个项目做完后我又陆续给它加了权限过滤、多轮对话和基于反馈的自动重检。每一次扩展都从新的问题出发而不是从我应该用某个新框架出发。这种问题驱动的工作方式比任何学习路线图都可靠。
AI工程从零开始：用RAG构建企业内部知识库问答助手
1. 从零开始不是从Transformer开始先辨清AI工程的学习地图先说个我经常遇到的场景。今年有好几个朋友来问我说自己想转行做AI买了深度学习教材准备从反向传播、Transformer结构开始啃问我这个路线对不对。我的回答通常让他们意外你要是想做AI工程师最不该花大量时间的就是从零手推Transformer。不是说原理不重要而是从零开始学AI工程和从零开始研究AI算法是两条完全不同的路。很多人把这两件事搞混了结果学了三个月数学发现自己连一个能跑起来的应用都没做出来挫败感极强。1.1 算法工程师和AI工程师干的是完全不同的两件事打个比方。算法工程师研究的是怎么让模型更聪明。他们关心的是这个模型结构能不能改一改训练数据要不要再加大Loss函数是不是可以设计得更好他们的交付物是更好的模型权重和证明这个模型有效的实验报告。AI工程师关心的是怎么让模型在真实环境里持续稳定地干活。他们的交付物是一个别人真能打开用、在业务里创造价值的系统。同样一个模型算法工程师交到AI工程师手里之后要考虑的是模型怎么部署并发大了怎么办用户问的问题不在知识库里怎么答有没有幻觉改了一个Prompt会不会影响其他问答每个月光调模型API要烧多少钱所以AI工程里的从零开始本质是从零开始搭建一套能让AI模型稳定产出价值的工程系统而不是从零开始推导Attention机制。前者是工程问题后者是科研问题。1.2 真正的从零是走完一条端到端链路我见过太多所谓的AI项目半途而废原因惊人的一致卡在不知道下一步该干什么。会调一个ModelScope上的开源模型但不知道数据怎么弄知道LangChain能串流程但文档看了两章就开始犯困。其实把一个AI应用落地拆到最粗也就五步明确问题这个应用解决谁的什么痛点答错了损失有多大。准备数据知识从哪来怎么清洗怎么切分怎么向量化。构建核心链路检索还是生成走RAG还是微调Prompt怎么写。评估与迭代怎么量化回答得好不好怎么发现模型在哪些问题上翻车。部署与运维服务怎么起并发怎么扛日志怎么查成本怎么控。只要这五步完整走通一遍——哪怕做了一个功能极其简单的小工具——你就已经具备了从零开始做AI工程的骨架。后面所有的进阶都是往这个骨架上填肌肉。如果你现在刚开始我建议你用两周时间把上面这条链路走通一遍走的越笨越好先别追求花哨。1.3 学习顺序建议让第一个项目在两周内落地我整理一下给新人的建议顺序这和我当年自学时的路线不同——当年顺序反了走了不少弯路。第一周找一个足够窄的问题准备几十份真实文档搭一个最小RAG链路跑通提问-检索-生成-回答全过程。工具链直接用现成的开源Embedding模型加一个向量库加一个LLM API。第二周建立评估集找30到50个真实问题把每次回答记录下来逐条看失败原因调整切分策略和Prompt。做完这两件事你对AI工程的体感会比啃三个月理论强得多。后续带着实际项目中遇到的瓶颈去补理论。比如发现检索效果差就去学Embedding和重排原理发现模型回答稳定性差就去研究Prompt工程和模型微调的边界。让项目问题当老师这是我最推荐的路径。2. 第一个闭环把一个200页的内部手册变成问答助手理论说了不少接下来我用一个我自己做过的真实项目来走一遍完整链路。这个项目的需求特别简单公司内部有一本差不多200页的《客户服务操作手册》新人培训期总是翻不着东西——文档是PDF搜索靠CtrlF目录还经常过期。我给它做成一个问答助手让它能回答某某业务类型的标准处理时效是多久遇到投诉升级的流程是什么这类问题。这个小项目我后来反复推荐给想入门AI工程的人因为它的复杂度刚刚好有点真实业务价值不会大到失控又足够覆盖全链路。2.1 为什么选择RAG而不是微调当时我第一个念头绝对不是训练一个模型。200页操作手册哪怕把它微调进一个7B模型里风险也非常大手册内容经常更新微调一次成本高、周期长而且微调模型很容易在事实性问题上胡编。你要的是一个随时能更新知识的系统不是一个背熟了某版教材的学生。所以选了RAG检索增强生成Retrieval-Augmented Generation。核心思路一句话每次回答问题前先从文档库里把最相关的几个片段检索出来把这些片段连同问题一起交给大模型生成答案。模型不依赖记忆回答而是看着资料回答这就把答案过时和胡编的风险降低了非常多。你不需要让模型提前记住你的手册你只需要让它在回答的瞬间查得到、查得准。2.2 最小闭环拆解五个环节依次打通这个项目我没有用现成全家桶框架因为当时想的是把每个环节都摸清楚——后来证明这个决定极其正确。整体长这样文档加载把PDF逐页解析成文本手动抽查了目录、表格、页眉页脚有没有被正确识别。文本切块按固定长度切块每个块大约600 token块与块之间重叠80 token。向量化用开源的Embedding模型把每块文本转成一串向量存进向量库。检索用户提问时把问题也转成向量在向量库里做相似度搜索取前5个最相关片段。生成把检索到的片段和用户问题塞进一个结构化的Prompt模板由大模型生成回答。下面是当时核心的检索函数我简化了框架代码保留最直接的逻辑def retrieve_and_answer(query: str, top_k: int 5) - dict: # 1. 把用户问题转成向量 query_vec embedding_model.encode(query, normalize_embeddingsTrue) # 2. 在向量库里做相似度搜索 hits vector_db.search(query_vec, top_ktop_k) # 3. 拼装上下文这里有个细节控制检索片段的总长度 context_parts [] for hit in hits: context_parts.append( f[来源{hit[source]}第{hit[page]}页]\n{hit[text]} ) context \n\n---\n\n.join(context_parts) # 4. 组装Prompt并调用模型 prompt build_prompt(queryquery, contextcontext) answer llm.chat(messages[{role: user, content: prompt}]) return {answer: answer, context: context_parts}这里有个细节我想特别说一下检索结果的排序逻辑不能只看得分。很多向量库默认按距离排序但如果你做了多路召回比如同时用了关键词和向量一定要自己定义合并策略。我后来在这个小项目里就因为这个栽过跟头后面会细说。五个环节全部打通大约花了一个周末。第一个完整回答生成出来的时候说实话有点激动——它答对了标准时效是24小时这句这在以前得翻十几页PDF才找得到。2.3 评估基线跑通之前先想好怎么算有效这个项目起步时最容易犯的错误是我自己差点犯的Demo能出答案就觉得大功告成。实际上能出答案和能稳定出对答案之间差着十万八千里。我做了一个最原始的评估集找业务同事要了40条真实的用户问题覆盖手册里各个章节比如客户投诉三次以上怎么办退款审批链路上有几个节点。然后人工给每一条标了答案出处和预期要点。用这套评估集跑一遍记录下来每个问题答得好不好作为基线。评判标准也简单粗暴三个等级达标核心要点答对了人也看得懂。及格方向没错但漏了关键细节。翻车答错或答非所问。第一轮测下来达标率大概只有三成。一半以上的问题翻车原因集中在两类一是检索出来的上下文里压根没有正确答案检索失败二是上下文里有答案但模型没提取出来生成失败。这两类问题后面去修的方向完全不同所以没有评估集就调优等于闭着眼开车。3. 数据管线的细节盲区文档清洗、切块粒度与Embedding选型说句得罪人的话大部分AI项目做不好不是模型选得不好而是数据管线太糙。RAG这个技术看着简单真正把文档变成可检索片段这一步做好的人十个里面没有一个。3.1 PDF解析常见的三种坑PDF大概是这个世界上最不适合做文本提取的格式。我当时用的解析工具看着挺美真正跑起来就露馅了。表格乱序手册里有个业务流程时限一览表解析出来完全成了天书数字都挤在一行里。这是PDF处理中最常见的坑——表格和分栏布局的还原依赖工具能力。最后我单独把这类表格截图、用OCR提取成结构化文本再按原始表头重新拼接才解决。页眉页脚污染每页顶部都在重复客户服务操作手册V3.2切块之后有五六块内容是纯页眉检索时白白占掉上下文槽位。清洗阶段要把这些高频重复内容筛掉一个简单的办法是统计全文中出现次数最多的片段手动确认后全局删除。文字错位页边距和特殊字符偶尔导致句子断行比如标准时效是2\n4小时检索到了也影响大模型理解。清洗时要加一道连字符和断行处理把孤零零的数字与下一行拼起来。如果你处理的是Word文档一般比PDF好很多但也要注意批注、修订模式和目录页——历史版本的修订痕迹混进知识库检索出来是会误导模型的。3.2 切块策略决定检索上限的第一道关卡切块Chunking是整个数据管线里最考验经验的一个环节。切太碎了语义被切断检索返回一堆碎片切太大了一个块里塞了太多无关内容向量化之后互相干扰检索精度也下降。当时我做了三组对比这里直接给结果策略参数达标率问题表现固定256 token重叠2052%常见于大段落语义被拦腰截断检索结果零碎上下文里关键信息不完整固定600 token重叠8067%整体均衡长段落完整短段落有点浪费按标题语义切分以三级标题为边界块上限1000 token71%效果最好但也要求源文档本身结构规范最后一组方案改动了更多先用标题层级做逻辑分组如果某小节内容太长再按固定长度切。这样每一块基本对应一个独立主题检索命中时的信息密度最高。另外不要只依赖一种切法。现实中的文档很杂条款类适合大块切问答类适合小块切。你可以按文档类型设定不同的切块规则在元数据里标记类型检索时再决定优先取哪种块。这个思路比全局统一参数要先进得多。还有一点重叠overlap不是越大越好。重叠是为了让跨块语义不丢失但重叠过大会让相邻块的内容大量重复检索时可能返回五个块但其实内容几乎一样。我的经验是从80到150 token开始你的如果低于50效果通常不理想。3.3 Embedding和向量库的选型参考中文场景下Embedding模型的选型直接决定检索质量的下限。我当时做过一批实测对比用了40条测试问题用召回率衡量效果数据大概是这样的模型维度中文效果说明BGE-M31024很好开源、多语言、支持稀疏与稠密检索混合成本为零中文场景首选text-embedding-3-small1536良好OpenAI也好用但要花钱适合不想管部署的团队M3E-base768良好中文专项训练的早期方案速度够用但效果略逊BGE-M3通用英文模型如MiniLM384差中文效果明显拉胯个人非常不推荐我的建议很直接预算允许就选BGE-M3用开源的不丢人效果是实打实的。部署一个Embedding模型不需要GPUCPU跑就已经很快了几百兆的模型而已。向量库层面我当时的排序和后来给团队的建议基本一致数据量在百万片段以下直接上FAISS或者Chroma。少一个组件就少一个故障点项目初期不需要自建向量数据库。考虑未来多租户和权限过滤用pgvector搭配PostgreSQL最合适省一套基础设施。数据规模到了千万级别或者需要毫秒级海量并发再考虑Milvus这类专业向量数据库。千万别为了用Milvus而用Milvus。我见过有人数据才几万条就上了四节点的分布式向量库纯属给运维添堵。4. 检索增强生成里最容易被低估的两件事召回质量与Prompt护栏RAG的核心命门就两个拷出来的材料准不准召回质量和模型的作答稳不稳Prompt设计。这两件事看起来谁都会做但踩坑的人前赴后继。4.1 向量检索的我以为和实际上一开始我以为向量检索很智能输入投诉了三天没人管怎么办就能自动找到投诉升级处理流程那一章。实测发现向量检索的语义匹配能力被严重高估了——它对换词表达、专业术语简称、数字范围的敏感度都很差。比如手册里写一级投诉响应时限15分钟用户问的是客户炸了得多久回应向量检索很可能把最相关的片段排到第8名开外。TopK取得不够大时正确答案根本进不了上下文。这就是第一个经验TopK不能拍脑袋定死。我当时基准设5后来根据评测集调到10搭配上下文长度裁剪效果好了不少。另外一个很多人没意识到的问题相似度阈值设得太激进了。向量检索返回的相似度分数在0到1之间如果问题完全属于手册覆盖范围返回片段分数通常高于0.45如果问的是无关问题分数可能只有0.3。低于阈值宁可告诉用户这个问题我暂时无法回答也不要硬答。这是最便宜的一层护栏。4.2 混合检索与重排效果提升最直接的组合拳我前面提到的翻车问题后来是用混合检索治好的。做法很简单同时跑两路检索——一路是向量检索找语义相近的内容另一路是BM25关键词检索找精确匹配的内容比如24小时三级审批V3.2这类硬信息。然后把两路结果合并根据得分做加权排序。这个优化做起来不难收益却非常直接。尤其是处理操作手册这类术语密度高、数字多的文档BM25能弥补向量检索在精确匹配上的天然短板。如果还想再进一步可以在合并排序后加一层重排Rerank。经典的方案是用Cross-Encoder模型把每个候选片段和用户问题拼在一起让模型算相关性精度更好但延迟也会明显上升。小项目里我的经验是先用混合检索效果不够再加重排不要一上来就上全套。重排模型推荐开源的BGE-Reranker系列部署简单实测有效。检索链路最终调到什么程度算合格我个人习惯用一个很土的验收指标把评测集里每个问题对应的标准答案段落保证在检索结果前3位出现命中率至少80%。达不到这个标准后面Prompt写得再好也白搭——巧妇难为无米之炊。4.3 Prompt不是写作文结构、示例与护栏设计很多新手把Prompt写成一堆客套话什么你是一个专业助手请用礼貌的语气帮助用户解决问题。这类废话对模型输出质量的影响几乎为零。真正起作用的是以下四个要素角色和边界明确告诉模型你是公司内部知识库问答助手只能依据提供的资料回答。这能有效降低越界答题。严格的引用约束要求如果资料中没有答案必须直接说明无法回答禁止编造。这是对抗幻觉最有用的指令但光说不做也不行最好再给一个错误示范。来源标注要求回答末尾标注基于的文档来源和页码。一旦答错排查和追责都方便更重要的是能反向定位是检索问题还是生成问题。Few-shot示例给模型一两条结构完美的回答示例比写十句请认真负责地回答有效得多。要知道模型的学习能力在这个层面非常敏感一个标准答案的样子胜过一堆形容词。我还遇到过一个特别典型的坑某个业务问题本身包含了两层意图比如投诉升级后客户要求赔偿这个流程要多久模型只答了一半。后来在Prompt里要求如果问题涉及多个流程环节必须分点逐项回答这个问题才改善。Prompt的调试必须靠评测集驱动的失败案例来反推不能拍脑袋想到什么加什么。另外一个容易被忽略的细节是上下文裁剪。当你用混合检索拿到Top10片段时全部塞进Prompt会超长也浪费token。我的做法是先硬截断掉明显低分的片段再保留总分靠前但总token数不超过上下文的实际限制比如4096并留出足够空间给回答输出。如果前5个片段已经占了3000 token硬塞10个就是自杀式设计。5. 从本地能跑到上线可用模型服务化、缓存观测与成本清单Demo人人都能做差距在把东西端出去。这一章讲的都是没人带你、你自己绝对容易忽略的硬功夫。5.1 模型服务化的正确姿势我当时把大模型服务包了一层FastAPI用Docker容器化部署到内部服务器。核心流程是用vLLM起一个OpenAI兼容接口的模型服务吞吐比原版推理框架高很多。应用层单独起一个服务负责检索、拼接Prompt、调用模型接口。两个服务只通过HTTP通信互不干扰。模型更新时只换容器应用逻辑不用动。这里有一条经验值得单独提出来如果不是对延迟极度敏感优先用vLLM开一个共享服务而不是每个应用单独拉一个模型加载到GPU上。因为一次模型加载就要占十几GB显存多个应用各拉一份是对GPU资源的极大浪费。早年间我见过团队同时跑了三个模型实例每张卡都顶着上限后来统一收敛到一个共享网关才喘过气来。如果你的模型不用那么大想压在消费级显卡上可以考虑量化方案。AWQ、GPTQ这类4bit量化能把7B/13B模型压到6-8GB显存质量损失在可接受范围内。但这里有个前提量化后的模型必须在评测集上重新测一遍有些任务的输出质量会掉得很明显不能只看显存占用觉得能跑就行。5.2 响应体验的隐形功臣缓存与并发策略上线第一周我就发现一个问题80%的高频提问集中在20个常见问题上。用户问完了不满意改几个字再问一遍本质是同一道题。每次都要重新走检索、重新调大模型等于白白烧钱。解决办法是加缓存。我当时做了两层精确缓存完全相同的问题直接返回历史答案秒开。语义缓存把新问题向量化与缓存里的历史问题进行相似度匹配高于0.95就复用缓存答案。这个优化能把重复提问的响应时间从5秒压到300毫秒月度API成本直接降了小一半。缓存有个容易踩的坑是业务更新。手册内容更新后命中旧缓存的答案会过时。我的解决办法是给缓存打上数据版本号和有效期手册更新时强制失效。另外涉及时效性比较强的问题比如当前处理进度绝对不能走缓存要在Prompt里加时间戳并用代码逻辑跳过。并发这块小项目直接用FastAPI异步接口加信号量控制模型服务请求数量就够了。先用ab工具或Locust压一下接口水平确认你的应用层能扛多久。很多新手一上来就买一堆GPU实例做负载均衡其实瓶颈大概率在检索和模型服务先把这两处链路摸清了再说。5.3 这个项目一个月到底花多少钱成本这块我直接说结论。当时用7B级模型自己有卡加一个Embedding模型主要开销是GPU电费和服务器维护如果完全走商业API则可以按token精确估算。以API方案举例假设一个月有4万次问答每次平均输入2000 token含检索上下文、输出300 token。那么月消耗大概是输入8000万token输出1200万token。按当前常见定价算大模型费用每月在几百到一千元人民币区间。检索和Embedding的开销小到可以忽略。也就是说一个小体量的内部AI问答工具月成本是可控的没必要一上来就花十几万搭集群。成本优化最有价值的方向永远是减少无效请求缓存解决重复提问知识外问题直接拒答不调模型长上下文中可以压缩掉无用片段。这三招做完通常能省30%以上。5.4 上线前必须回答的三个安全提问我习惯在项目上线前问自己三个问题回答不了就不上数据合规性这份手册能不能被模型服务访问模型是私有部署还是云端API内部敏感数据绝对不能混进外部托管的模型服务。当时我们内部手册走的是内网部署的开源模型这台机器不开放外网访问。幻觉冲击力如果模型瞎编了一条规则最坏的结果是什么对于操作手册这类对准确性要求很高的场景我在Prompt里强制要求答案必须逐字引用资料原文并标注来源页码宁可回答保守一些也不能让它自由发挥。日志可追踪每一次回答能不能追溯到哪几段上下文、哪个Prompt版本、哪个模型版本我把这些信息全塞进了结构化日志和数据库表里用户反馈答错了可以一条条追回去。没有这个能力后面做任何优化都等于盲改。这三个问题里第二个最容易被人忽略。很多人只看答对了多少不看答错的后果有多严重。对医疗、法务、设备操作这类场景答错一次可能造成的损失是巨大的。6. 复盘与扩展绕过我踩过的坑走微调还是Agent最后这部分我不打算做总结了就聊点实在的这个项目做完后我复盘出的经验以及想继续往下走的人下一步该往哪边走。6.1 踩坑记录五件让我折腾到凌晨的事PDF表格错乱那页时限一览表我抠了一下午才弄干净。后来wd这些坑的有效手段是对表格型页面用OCR结构化提取不要指望纯文本解析。切块边界切断了修条件手册里如客户要求出具书面证明则须在2个工作日内完成被切到两个块里检索命中率极低。用语义切块替换固定长度之后才好转。向量库默认端口冲突Chroma默认端口和公司另一个服务撞了排查了三个小时。建议所有组件启动时改掉默认端口并写进部署文档。评估集第一版太干净我自己编的问题和真实用户问法差距很大第一次测出来效果很好发给业务同事一测发现全翻车。后来评估集全部改用同事的真实聊天记录和工单标题再也不自己编问题了。Prompt越改越胖每次失败就加一句指令最后Prompt长达两页效果反而下降。痛定思痛把Prompt拆成主干、护栏、示例三个部分每部分单独做A/B测试稳定了再加进来。每一个坑单看都不大但串起来足以消耗掉好几个人日。数据管线、评测集、Prompt版本管理这三件事放在项目第一天做和放到上线前做工作量和心态完全不同。6.2 从RAG到Agent什么情况下值得往前走做完了知识库问答不少人会问下一步是不是直接上Agent我的看法是先把单轮RAG的准确率和稳定性做扎实再考虑Agent的自动规划和多步执行。Agent的价值在于能拆解复杂任务比如帮我统计这个月不同类型投诉的比例并生成一段分析——这需要规划步骤、查数据、写报告。但Agent的复杂性也随之而来模型自己要决定调用哪些工具、步骤对不对、失败了怎么恢复。这些问题在工程上比RAG难了一个量级。我的决策标准很简单如果业务场景主要是查资料问答RAG足够就不要上Agent。如果确实需要多步推理或工具调用比如查数据库、发通知、操作业务系统再考虑Agent框架。如果要用Agent先从单步工具的可靠性验证开始让模型调用一个工具测试它在100种问题下的调用准确率不到90%就不适合做多步编排。微调也是一样的逻辑先用RAG和Prompt解决能解决的问题。只有当模型本身的能力上限成为瓶颈时——比如你希望它按特定风格回复、处理特定领域的复杂推理——才值得花成本微调。RAG解决知道什么微调解决怎么答、能不能推两者不是取代关系。6.3 给后来者的一句实话做完这个项目最深的体会是AI工程从零开始的门槛比想象中低天花板比想象中高。门槛低在你不需要先读完全部论文才能动手两周就能做出一个有用的工具天花板高在从能跑到好用之间有数据质量、检索策略、评估体系、服务治理这一大串工程问题等着你。我个人的建议始终是那句朴素的话先让一个真实的问题被你的AI系统解决掉再考虑优化它。你会在解决第一个问题的过程中发现所有真正值得学的东西。这个项目做完后我又陆续给它加了权限过滤、多轮对话和基于反馈的自动重检。每一次扩展都从新的问题出发而不是从我应该用某个新框架出发。这种问题驱动的工作方式比任何学习路线图都可靠。