先说一个我最近特别深的感触AI全栈开发绝对不是“会调API 会写前端 会写后端”那么简单的三件套。它更像是一条横跨需求拆解、模型选型、RAG搭建、Agent编排、模型部署、效果评估和线上监控的完整链路。你可以在某一段上深耕但如果你想把一个AI应用从想法真正落到生产环境每一段都得趟一遍。这篇文章我想以“AI全栈开发最佳实践”为主线把我从几个真实项目里沉淀下来的方法、参数和踩坑记录完整拆给你看。不管你是正在转型的Web开发、刚上手的AI应用开发还是已经在做AI Agent但总觉得工程化缺口气的团队这篇应该都能给你一些直接能用的东西。1. 先搞清楚AI时代的“全栈开发”到底多了什么我先说个观察。过去我们聊全栈开发默认是“前端 后端 数据库 部署运维”一个人能把MVVM页面、RESTful接口、MySQL索引、Nginx反向代理这些串起来就算很能打了。但到了AI应用这个阶段事情变了。传统的全栈技能仍然是底盘但在它之上新长出来一层东西你要懂模型能力边界知道什么任务该用多大参数的模型你要会做提示词工程但不只是写几句好话让模型听话你要搭RAG流程涉及文档切分、向量召回、重排序你要设计Agent的工具调用和权限边界你还得处理模型部署、推理加速、限流降级、成本监控。这一整套才是AI全栈开发的全貌。我见过不少团队代码写得很干净但一接大模型就懵要么是拿到需求直接写prompt上线后被用户问几句就露馅要么是把模型部署在GPU裸奔没有QPS概念一压测就超时要么是Agent的工具调用没有任何限制模型一个幻觉就调了不该调的接口。这些问题的根源都是只看到了AI全栈里某一个亮点没有把整条链路当成一个系统来设计。所以我把AI全栈开发的实践路径拆成四个核心模块来聊需求侧判断什么该用模型、什么不该用模型应用侧提示词、RAG、Agent编排的工程化落地部署侧模型推理、AI Infra和成本控制质量侧测试、监控和持续迭代下面每一块我都会给出具体步骤、参数参考以及我实际踩过的坑。这篇文章不会讲怎么从零训练一个模型那是一个更重的领域AI全栈开发的核心场景是把现成的模型能力转化成稳定的产品。2. 需求拆解与选型不是所有问题都要上大模型我见过最贵的浪费就是把GPT级别的模型用在一个“if/else”就能解决的问题上。有一次一个业务方找我说要做一个“智能合同审核”要求大模型判断合同里有没有“付款条款”。我看了他们已有的合同格式发现所有付款条款都有固定标题用正则匹配就能搞定准确率100%而且延迟是零。后来我们只在前端加了一个规则引擎整个项目从两周缩到半天。这不是段子而是AI全栈开发里最容易被忽略的一个环节需求拆解。你要先回答一个问题——这个任务的核心是“理解并生成”还是“检索并匹配”我自己的决策框架是这样的问题类型典型特征推荐方案例子规则可解条件明确、格式固定正则 / 条件分支合同条款是否存在、日期抓取分类/抽取可解标签集合固定、文本结构稳定传统NLP / 小模型 / 分类接口工单分类、敏感词过滤语义理解 多步推理开放式问题、需要综合多段信息回答大模型API / 开源模型部署文档问答、竞品分析摘要自主执行复杂任务需要调用多个工具、多轮规划LLM Agent编排框架自动生成报告、多系统数据汇总在确认“确实需要大模型”之后才轮到模型选型。这里有三条路径商业模型API开发最快效果通常最好适合验证期和中小流量产品。按token付费功能迭代快多模态、长上下文这些能力接上就能用。开源模型私有化部署适合数据不能出域、隐私要求高、需要深度定制或者长期token消耗非常大的场景。开源模型 云托管推理平台相当于API的无服务器版本没有自建GPU的运维成本又保留了一定的模型自由度。选型时我一般会列一个对比维度用真实业务数据来测而不是只看跑分上下文长度需求如果你的业务需要读完一整份50页的合同API模型会舒服很多开源模型的上下文虽然也在拉长但长文本下的召回率和生成稳定性还要实测延迟要求交互式Agent可能需要5秒内返回离线批量分析可以接受60秒成本结构API按token计费自托管要考虑GPU折旧、电力、运维人力数据合规哪些内容绝对不能发给第三方API这里我强烈建议一个动作不要拿着需求说明书去选型而是先抽取10条最典型的真实输入用两三个候选模型跑一遍手工评估输出质量、延迟和token开销。这个过程我们叫spike基本半天到一天时间能帮你省掉后面数周的返工。3. 从原型到工程化AI应用开发的完整链路选完模型之后很多人会直接冲进prompt调试但我建议先把应用的输入输出接口定清楚。这一步做不好后面换模型、调参数全乱套。3.1 先定义接口再定义prompt我做的第一个AI项目上来就写了一段又长又花哨的prompt结果前端、后端、模型三层接口全是人肉约定。后来才发现AI应用的接口设计比普通CRUD更重要因为模型输出是开放式的必须有明确的协议来约束。我的做法是先定义外部API的请求和响应结构再倒推prompt需要输出什么格式。比如做一个文档问答助手响应结构大概是{ answer: 根据合同第3条付款周期为30天。, sources: [ { doc_id: contract_2024_001, chunk_id: 15, page: 3, text: 乙方应在验收完成后30天内支付全款。 } ], confidence: high }有了这个契约prompt里就可以明确要求“必须输出JSON对象格式为{answer, sources, confidence}如果无法回答answer字段必须为‘无法从文档中获知’。”这样下游解析稳定不会出现模型自由发挥的情况。3.2 提示词工程的“结构化复利”很多提示词教程都在教“怎么写得更像人话”但工程上的提示词其实是半结构化的配置文件。我习惯把提示词拆成五个板块角色、任务目标、输入上下文、输出约束、示例。尤其是示例几个few-shot往往比长篇规则有效得多。这里有个我踩过的坑示例必须覆盖“边界情况”。比如你想让模型知道“找不到答案时直接承认”你就要在示例里故意放两条查不到的内容而不是只给它看标准答案。否则模型倾向于编造这是我们做知识库问答时最头疼的“幻觉”问题之一。3.3 RAG链路别只做“向量化 相似度检索”文档问答类应用基本都会上RAG但RAG的坑比想象多。一个标准的RAG链路是文档加载文本切分向量化召回排序/重排组装上下文生成回答很多Demo只做到“切分 - 向量化 - topK召回”就以为完事了。实际上召回质量受两大因素影响切分策略和重排策略。切分参数我最常用的参数是chunk_size512chunk_overlap100但这只是起点。如果文档是技术手册小节之间语义跳跃大建议按标题结构切分如果是合同条款按“条”切分远好于固定字符数。切分后的每一块最好保留文档元数据来源、页码、标题路径这样后面能做到可溯源的引用。向量化模型开源常见的embedding模型足够应对中文场景但要注意它的最大输入长度。有些模型最长只有512个token超过会被截断你的chunk切再合理也没用。重排召回后别直接把topK塞给大模型先过一道重排模型效果会稳定很多。重做的时候把初召回数量加大比如召回20条重排后取前5条能显著减少噪声。给一个可以直接抄的查询侧骨架用OpenAI兼容接口接本地服务from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) def rerank(query: str, documents: list[str], top_k: int 5): # 这里可以接一个rerank服务的HTTP接口 resp requests.post(http://localhost:8890/rerank, json{ query: query, documents: documents, top_k: top_k }) results resp.json() return [doc[index] for doc in results[results]] def answer(query: str, top_k_docs: list[dict]): context \n\n.join([ f[{i}](来源:{doc[source]}) {doc[text]} for i, doc in enumerate(top_k_docs) ]) prompt f你是企业内部知识库助手。请严格根据下方资料回答问题。 如果资料中没有答案请直接说“无法从现有文档中获知答案”不要编造。 资料 {context} 问题 {query} 请以JSON格式输出{{answer: ..., sources: [...]}} resp client.chat.completions.create( modelqwen2.5-14b-instruct, messages[{role: user, content: prompt}], temperature0.2, max_tokens512, response_format{type: json_object} ) return resp.choices[0].message.content这里有几个工程细节temperature0.2是为了让问答任务尽量稳定而不是让模型更有“创意”response_format{type: json_object}很多开源模型也支持JSON约束输出能极大降低解析报错率上下文里保留“来源”字段模型才会在sources里带上出处3.4 Agent编排工具调用的边界比能力更重要如果说RAG是AI应用的“知识层”那么Agent就是“行动层”。AI Agent的爆火不是没有原因的它让模型从“回答问题”走向“完成任务”。但Agent的工程化难点不在怎么让模型调用工具而在怎么让模型“安全地”调用工具。我做Agent项目时的配置顺序是列出任务可能需要的工具清单为每个工具编写严格的JSON Schema声明明确每个工具的权限级别设定调用上限和人工确认节点给一个工具声明示例{ type: function, function: { name: send_email, description: 发送邮件给指定收件人。仅允许发送给公司内部员工。, parameters: { type: object, properties: { to: { type: string, pattern: ^[a-zA-Z0-9._%-]company.com$, description: 收件人邮箱必须为公司内部邮箱 }, subject: {type: string, maxLength: 100}, content: {type: string, maxLength: 2000} }, required: [to, subject, content] } } }注意description里直接写了“仅允许发送给公司内部员工”配合正则校验相当于在prompt层面和代码层面做了双重约束。Agent应用永远不要只依赖模型“听不听话”而是在工具API侧做彻底的权限校验。另外我给所有Agent应用都加了“步骤上限”默认最多5轮工具调用循环。防止模型在某些任务里进入死循环token像水一样烧掉。3.5 工作流编排什么时候串行什么时候并行有些AI应用是单次请求比如“请总结这份合同”有些则是多阶段任务比如“先拉取数据再生成图表再发送报告”。后者需要工作流编排。我个人的原则是能编排就别让Agent自由发挥。Agent适合工具选择多、决策路径不固定的场景如果业务流程固定比如“上传文件 - 解析 - 审核 - 反馈”就用传统的工作流引擎把每一段串起来在关键节点调用LLM能力而不是把整个流程控制权交给模型。这样定位问题也容易得多——哪一步挂了看日志就知道不需要让模型去“复盘”自己刚才干了什么。4. 模型部署与AI Infra把模型真正跑起来的那点事模型部署是AI全栈开发和传统Web开发差异最大的一块。很多后端老手第一次碰到“显存不够”“并发一高就OOM”时都会懵。这一节我重点讲推理部署、显存估算和成本控制。4.1 先算清楚显存再决定买什么卡很多人第一反应就是“上最好的GPU”但实际上不同规格的模型对显存的需求差异非常大。估算公式很简单模型权重大小 ≈ 参数量(10亿) × 精度字节数。我整理了一个常用的参考表模型规模半精度(F16)权重大小推理最低显存(含KV Cache估算)典型部署方式1.5B约3GB6-8GB单卡消费级显卡7B约14GB16-20GB单卡24GB14B约28GB32-40GB单卡48GB或双卡72B约144GB160GB以上多卡A100/H100集群如果是个人开发机跑7B、14B模型用4bit量化可以大幅降低显存占用。比如14B模型4bit量化后权重只有8GB左右一张24GB的卡就能跑起来效果损失在可接受范围内。我的经验对话、写作类任务4bit量化影响比较小代码生成、数学推理类任务会明显感到输出质量下降。4.2 推理服务用vLLM或Ollama别再写裸推理脚本了我见过有人直接用Transformers写模型推理不过对于生产环境有几个高并发问题一个请求一个请求排队GPU利用率上不去也不能处理批量调度。后来我全换成了vLLM它是目前比较成熟的开源推理服务框架支持Continuous Batching、PagedAttention、与OpenAI兼容的API接口接入成本很低。启动方式大概是这样vllm serve qwen2.5-14b-instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --served-model-name qwen2.5-14b-instruct启动之后应用侧就直接用OpenAI SDK把base_url指到这台机器的http://localhost:8000/v1前面给出的完整链路就能接上了。--gpu-memory-utilization 0.9这个参数也是我踩坑之后才注意到的。默认值会让模型只预留很少的KV Cache空间并发一高就报显存不足。后来我调到0.85到0.9之间相同显存下吞吐能提升不少。4.3 API网关、限流和成本控制模型服务上线后还要过“API网关”这一关。如果应用同时接了多个模型服务比如一个负责对话、一个负责向量化、一个负责重排它们各自的负载和限流策略又不一样直接用原始服务地址对外部暴露非常危险。我的做法是在模型服务前面加一层统一网关负责四件事统一鉴权外部请求只认网关的AK/SK不直接碰模型服务限流降级按用户、按接口维度配置QPS和并发限制缓存对于相同或近似请求可以做语义缓存命中后直接返回此前结果能省不少token灰度切换新模型版本上线时先切5%流量观察有问题再回滚成本方面我有两个习惯一是每次请求都记录token消耗按用户、按功能模块汇总这样每天能看清钱烧在哪二是对常见问题做“静态答案缓存”答案更新频率低的问题没必要每次都调用模型。需要重点提醒的是模型服务是状态相关的服务和普通Web服务的健康检查逻辑不太一样。不能只看进程活没活着还要看显存是否被打满、平均首token延迟是否漂移。我一般是每分钟检查一次/metrics超过阈值就摘掉节点并发告警。5. AI应用的测试、监控与持续迭代很多团队的AI应用上线后第一版效果不错第二周就变差了。这不是模型“变笨了”而是缺少了一套针对AI应用的质量保障体系。5.1 LLM应用测试和传统测试的差异传统后端测试断言很明确输入A输出B校验B是否等于B。但大模型的输出是开放式、概率性的你没法断言“模型这句话一定对”。所以AI应用的测试体系要分两层一层测工程逻辑一层测模型效果。测试类型测什么方法单元/集成测试接口解析、权限校验、链路异常普通pytest用例mock模型返回回归评估模型输出质量是否达标离线评估集 人工打分线上监控真实用户的输出质量日志分析 用户反馈打标成本监控token消耗是否异常按用户、按功能聚合5.2 离线评估集AI应用质量的压舱石我强烈建议从项目第一天起就建一个评估集。不需要很大50条高质量样本就能发挥巨大作用。每一条样本长这样{ query: 合同里的付款周期是多久, expected_points: [验收完成后30天], expected_sources: [contract_2024_001], difficulty: easy }之后每次改prompt、换模型、调切分参数都拿这套评估集跑一遍用脚本比对模型输出里是否包含expected_points中的关键点以及sources是否对得上。这种自动化回归能拦住绝大多数“改好了A问题带崩了B问题”的情况。我还用过一种更细的评估方式让模型当裁判用另一个模型给输出打分。但注意这种“LLM-as-a-judge”只适合做初筛关键业务还是得过人工这一关。5.3 线上监控盯住这几个指标就够了线上监控不需要一开始就铺很大我认为核心指标就这些请求成功率模型服务本身挂了还是网关限流了首token延迟 / 完整响应时间首token延迟更能反映用户体感空回复率 / 拒答率如果“无法回答”的比例异常升高可能是RAG召回全面失效平均每请求token数突然暴涨往往意味着提示词上下文拼接有问题用户反馈在对话流里加入“有帮助 / 无帮助”按钮成本低数据价值极高我还在日志里额外打了一个字段retrieved_chunk_score用来记录重排后最高分是多少。如果连续大量请求的最高分都很低说明知识库里没有对应内容应该触发“知识库补档”的提醒而不是等用户来抱怨。5.4 持续迭代的正确姿势AI应用上线只是开始。我的迭代流程是这样的收集线上badcase和用户反馈人工分析问题归类是检索不到、上下文丢失、模型理解错误还是知识库本身没有针对类别做修复检索问题改切分/召回/重排生成问题调prompt或换模型知识库问题补文档每轮修复后跑离线评估集确保没有回归灰度上线对比线上指标每一个循环大概1-2天比传统开发要快很多。这是AI应用开发最需要习惯的节奏小步快跑持续校准。6. 一次AI全栈项目的真实时间线复盘最后我用一个真实项目把前面所有内容串起来。这是一个企业内部的合同问答助手需求是用户上传一份合同AI需要回答关于合同条款的问题并且答案必须能回指到合同原文。整个项目从启动到上线用了5周人员只有我和一个兼职前端。第1周做的是需求澄清和spike。我们把业务方给的一百多份真实合同跑了一遍发现大部分是带标准模板的采购合同也有少数非常规的补充协议。这个发现直接影响了切分策略标准模板按条款切分补充协议按段落切分。这一周我们完成了模型选型和评估集初版20条。第2周搭RAG链路。文档上传、切分、向量化、召回、生成全流程跑通。前端只做了一个极简的聊天界面用于内部测试。这一周踩了一个印象深刻的坑向量化模型的输入长度是512token我们嵌入了大量超长chunk导致后面检索效果奇差。定位问题的过程就是看retrieved_chunk_score发现很多查询的召回分数都很低然后逐步排查到切分长度设置。第3周做Agent增强。业务方提了个新需求如果合同里有金额单价想直接问“这批货总价多少”系统要自动判断合同里是否有计算公式。这个需求单靠RAG做不好因为要结合表格甚至是附件。我们给Agent加了一个“表格抽取”工具模型在判断“直接从文本中找不到”之后调用工具再带着结构化数据生成结论。第4周部署上线。当时我们评估过直接接商业API和自己部署开源14B模型的成本。最后选择了自托管量化的方案原因是合同数据不能出域。我们在内网GPU机上用vLLM部署了量化版模型并在前面加了一层网关做限流和计费统计。这一周的主要工作其实是压测和调参QPS从最开始的2提升到15首token平均延迟压到了1.5秒。第5周做质量闭环。我们把线上badcase导出来逐条分析发现一个规律真正的问题大多数不在生成环节而在召回环节——相关条款没有被检索出来。我们把初召回从10条提到20条再引入重排模型效果就有了明显提升。最终离线评估集上的通过率从78%提升到了93%。这个项目走下来我最大的感受是AI全栈开发真正难的不是哪个单点技术而是整条链路的均衡。RAG做得再好部署高并发不行Agent写得再聪明没有评估集兜底提示词写得再漂亮知识库里没有对应内容——任何一个短板都会拖垮整个应用。最后分享两个个人习惯。第一我始终保留着一个本地脚本能一键把某个输入跑完“检索 - 重排 - 生成 - 评分”全流程改任何模块后都在跑一遍让自己心里有数。第二我每天会固定看一眼线上token消耗报表如果某个功能召回率下降或token异常飙升往往不是模型问题而是上游文档或者生产环境数据变动了。保持这种“全链路敏感度”大概就是AI全栈开发最核心的素养了。
先说一个我最近特别深的感触AI全栈开发绝对不是“会调API 会写前端 会写后端”那么简单的三件套。它更像是一条横跨需求拆解、模型选型、RAG搭建、Agent编排、模型部署、效果评估和线上监控的完整链路。你可以在某一段上深耕但如果你想把一个AI应用从想法真正落到生产环境每一段都得趟一遍。这篇文章我想以“AI全栈开发最佳实践”为主线把我从几个真实项目里沉淀下来的方法、参数和踩坑记录完整拆给你看。不管你是正在转型的Web开发、刚上手的AI应用开发还是已经在做AI Agent但总觉得工程化缺口气的团队这篇应该都能给你一些直接能用的东西。1. 先搞清楚AI时代的“全栈开发”到底多了什么我先说个观察。过去我们聊全栈开发默认是“前端 后端 数据库 部署运维”一个人能把MVVM页面、RESTful接口、MySQL索引、Nginx反向代理这些串起来就算很能打了。但到了AI应用这个阶段事情变了。传统的全栈技能仍然是底盘但在它之上新长出来一层东西你要懂模型能力边界知道什么任务该用多大参数的模型你要会做提示词工程但不只是写几句好话让模型听话你要搭RAG流程涉及文档切分、向量召回、重排序你要设计Agent的工具调用和权限边界你还得处理模型部署、推理加速、限流降级、成本监控。这一整套才是AI全栈开发的全貌。我见过不少团队代码写得很干净但一接大模型就懵要么是拿到需求直接写prompt上线后被用户问几句就露馅要么是把模型部署在GPU裸奔没有QPS概念一压测就超时要么是Agent的工具调用没有任何限制模型一个幻觉就调了不该调的接口。这些问题的根源都是只看到了AI全栈里某一个亮点没有把整条链路当成一个系统来设计。所以我把AI全栈开发的实践路径拆成四个核心模块来聊需求侧判断什么该用模型、什么不该用模型应用侧提示词、RAG、Agent编排的工程化落地部署侧模型推理、AI Infra和成本控制质量侧测试、监控和持续迭代下面每一块我都会给出具体步骤、参数参考以及我实际踩过的坑。这篇文章不会讲怎么从零训练一个模型那是一个更重的领域AI全栈开发的核心场景是把现成的模型能力转化成稳定的产品。2. 需求拆解与选型不是所有问题都要上大模型我见过最贵的浪费就是把GPT级别的模型用在一个“if/else”就能解决的问题上。有一次一个业务方找我说要做一个“智能合同审核”要求大模型判断合同里有没有“付款条款”。我看了他们已有的合同格式发现所有付款条款都有固定标题用正则匹配就能搞定准确率100%而且延迟是零。后来我们只在前端加了一个规则引擎整个项目从两周缩到半天。这不是段子而是AI全栈开发里最容易被忽略的一个环节需求拆解。你要先回答一个问题——这个任务的核心是“理解并生成”还是“检索并匹配”我自己的决策框架是这样的问题类型典型特征推荐方案例子规则可解条件明确、格式固定正则 / 条件分支合同条款是否存在、日期抓取分类/抽取可解标签集合固定、文本结构稳定传统NLP / 小模型 / 分类接口工单分类、敏感词过滤语义理解 多步推理开放式问题、需要综合多段信息回答大模型API / 开源模型部署文档问答、竞品分析摘要自主执行复杂任务需要调用多个工具、多轮规划LLM Agent编排框架自动生成报告、多系统数据汇总在确认“确实需要大模型”之后才轮到模型选型。这里有三条路径商业模型API开发最快效果通常最好适合验证期和中小流量产品。按token付费功能迭代快多模态、长上下文这些能力接上就能用。开源模型私有化部署适合数据不能出域、隐私要求高、需要深度定制或者长期token消耗非常大的场景。开源模型 云托管推理平台相当于API的无服务器版本没有自建GPU的运维成本又保留了一定的模型自由度。选型时我一般会列一个对比维度用真实业务数据来测而不是只看跑分上下文长度需求如果你的业务需要读完一整份50页的合同API模型会舒服很多开源模型的上下文虽然也在拉长但长文本下的召回率和生成稳定性还要实测延迟要求交互式Agent可能需要5秒内返回离线批量分析可以接受60秒成本结构API按token计费自托管要考虑GPU折旧、电力、运维人力数据合规哪些内容绝对不能发给第三方API这里我强烈建议一个动作不要拿着需求说明书去选型而是先抽取10条最典型的真实输入用两三个候选模型跑一遍手工评估输出质量、延迟和token开销。这个过程我们叫spike基本半天到一天时间能帮你省掉后面数周的返工。3. 从原型到工程化AI应用开发的完整链路选完模型之后很多人会直接冲进prompt调试但我建议先把应用的输入输出接口定清楚。这一步做不好后面换模型、调参数全乱套。3.1 先定义接口再定义prompt我做的第一个AI项目上来就写了一段又长又花哨的prompt结果前端、后端、模型三层接口全是人肉约定。后来才发现AI应用的接口设计比普通CRUD更重要因为模型输出是开放式的必须有明确的协议来约束。我的做法是先定义外部API的请求和响应结构再倒推prompt需要输出什么格式。比如做一个文档问答助手响应结构大概是{ answer: 根据合同第3条付款周期为30天。, sources: [ { doc_id: contract_2024_001, chunk_id: 15, page: 3, text: 乙方应在验收完成后30天内支付全款。 } ], confidence: high }有了这个契约prompt里就可以明确要求“必须输出JSON对象格式为{answer, sources, confidence}如果无法回答answer字段必须为‘无法从文档中获知’。”这样下游解析稳定不会出现模型自由发挥的情况。3.2 提示词工程的“结构化复利”很多提示词教程都在教“怎么写得更像人话”但工程上的提示词其实是半结构化的配置文件。我习惯把提示词拆成五个板块角色、任务目标、输入上下文、输出约束、示例。尤其是示例几个few-shot往往比长篇规则有效得多。这里有个我踩过的坑示例必须覆盖“边界情况”。比如你想让模型知道“找不到答案时直接承认”你就要在示例里故意放两条查不到的内容而不是只给它看标准答案。否则模型倾向于编造这是我们做知识库问答时最头疼的“幻觉”问题之一。3.3 RAG链路别只做“向量化 相似度检索”文档问答类应用基本都会上RAG但RAG的坑比想象多。一个标准的RAG链路是文档加载文本切分向量化召回排序/重排组装上下文生成回答很多Demo只做到“切分 - 向量化 - topK召回”就以为完事了。实际上召回质量受两大因素影响切分策略和重排策略。切分参数我最常用的参数是chunk_size512chunk_overlap100但这只是起点。如果文档是技术手册小节之间语义跳跃大建议按标题结构切分如果是合同条款按“条”切分远好于固定字符数。切分后的每一块最好保留文档元数据来源、页码、标题路径这样后面能做到可溯源的引用。向量化模型开源常见的embedding模型足够应对中文场景但要注意它的最大输入长度。有些模型最长只有512个token超过会被截断你的chunk切再合理也没用。重排召回后别直接把topK塞给大模型先过一道重排模型效果会稳定很多。重做的时候把初召回数量加大比如召回20条重排后取前5条能显著减少噪声。给一个可以直接抄的查询侧骨架用OpenAI兼容接口接本地服务from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) def rerank(query: str, documents: list[str], top_k: int 5): # 这里可以接一个rerank服务的HTTP接口 resp requests.post(http://localhost:8890/rerank, json{ query: query, documents: documents, top_k: top_k }) results resp.json() return [doc[index] for doc in results[results]] def answer(query: str, top_k_docs: list[dict]): context \n\n.join([ f[{i}](来源:{doc[source]}) {doc[text]} for i, doc in enumerate(top_k_docs) ]) prompt f你是企业内部知识库助手。请严格根据下方资料回答问题。 如果资料中没有答案请直接说“无法从现有文档中获知答案”不要编造。 资料 {context} 问题 {query} 请以JSON格式输出{{answer: ..., sources: [...]}} resp client.chat.completions.create( modelqwen2.5-14b-instruct, messages[{role: user, content: prompt}], temperature0.2, max_tokens512, response_format{type: json_object} ) return resp.choices[0].message.content这里有几个工程细节temperature0.2是为了让问答任务尽量稳定而不是让模型更有“创意”response_format{type: json_object}很多开源模型也支持JSON约束输出能极大降低解析报错率上下文里保留“来源”字段模型才会在sources里带上出处3.4 Agent编排工具调用的边界比能力更重要如果说RAG是AI应用的“知识层”那么Agent就是“行动层”。AI Agent的爆火不是没有原因的它让模型从“回答问题”走向“完成任务”。但Agent的工程化难点不在怎么让模型调用工具而在怎么让模型“安全地”调用工具。我做Agent项目时的配置顺序是列出任务可能需要的工具清单为每个工具编写严格的JSON Schema声明明确每个工具的权限级别设定调用上限和人工确认节点给一个工具声明示例{ type: function, function: { name: send_email, description: 发送邮件给指定收件人。仅允许发送给公司内部员工。, parameters: { type: object, properties: { to: { type: string, pattern: ^[a-zA-Z0-9._%-]company.com$, description: 收件人邮箱必须为公司内部邮箱 }, subject: {type: string, maxLength: 100}, content: {type: string, maxLength: 2000} }, required: [to, subject, content] } } }注意description里直接写了“仅允许发送给公司内部员工”配合正则校验相当于在prompt层面和代码层面做了双重约束。Agent应用永远不要只依赖模型“听不听话”而是在工具API侧做彻底的权限校验。另外我给所有Agent应用都加了“步骤上限”默认最多5轮工具调用循环。防止模型在某些任务里进入死循环token像水一样烧掉。3.5 工作流编排什么时候串行什么时候并行有些AI应用是单次请求比如“请总结这份合同”有些则是多阶段任务比如“先拉取数据再生成图表再发送报告”。后者需要工作流编排。我个人的原则是能编排就别让Agent自由发挥。Agent适合工具选择多、决策路径不固定的场景如果业务流程固定比如“上传文件 - 解析 - 审核 - 反馈”就用传统的工作流引擎把每一段串起来在关键节点调用LLM能力而不是把整个流程控制权交给模型。这样定位问题也容易得多——哪一步挂了看日志就知道不需要让模型去“复盘”自己刚才干了什么。4. 模型部署与AI Infra把模型真正跑起来的那点事模型部署是AI全栈开发和传统Web开发差异最大的一块。很多后端老手第一次碰到“显存不够”“并发一高就OOM”时都会懵。这一节我重点讲推理部署、显存估算和成本控制。4.1 先算清楚显存再决定买什么卡很多人第一反应就是“上最好的GPU”但实际上不同规格的模型对显存的需求差异非常大。估算公式很简单模型权重大小 ≈ 参数量(10亿) × 精度字节数。我整理了一个常用的参考表模型规模半精度(F16)权重大小推理最低显存(含KV Cache估算)典型部署方式1.5B约3GB6-8GB单卡消费级显卡7B约14GB16-20GB单卡24GB14B约28GB32-40GB单卡48GB或双卡72B约144GB160GB以上多卡A100/H100集群如果是个人开发机跑7B、14B模型用4bit量化可以大幅降低显存占用。比如14B模型4bit量化后权重只有8GB左右一张24GB的卡就能跑起来效果损失在可接受范围内。我的经验对话、写作类任务4bit量化影响比较小代码生成、数学推理类任务会明显感到输出质量下降。4.2 推理服务用vLLM或Ollama别再写裸推理脚本了我见过有人直接用Transformers写模型推理不过对于生产环境有几个高并发问题一个请求一个请求排队GPU利用率上不去也不能处理批量调度。后来我全换成了vLLM它是目前比较成熟的开源推理服务框架支持Continuous Batching、PagedAttention、与OpenAI兼容的API接口接入成本很低。启动方式大概是这样vllm serve qwen2.5-14b-instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --served-model-name qwen2.5-14b-instruct启动之后应用侧就直接用OpenAI SDK把base_url指到这台机器的http://localhost:8000/v1前面给出的完整链路就能接上了。--gpu-memory-utilization 0.9这个参数也是我踩坑之后才注意到的。默认值会让模型只预留很少的KV Cache空间并发一高就报显存不足。后来我调到0.85到0.9之间相同显存下吞吐能提升不少。4.3 API网关、限流和成本控制模型服务上线后还要过“API网关”这一关。如果应用同时接了多个模型服务比如一个负责对话、一个负责向量化、一个负责重排它们各自的负载和限流策略又不一样直接用原始服务地址对外部暴露非常危险。我的做法是在模型服务前面加一层统一网关负责四件事统一鉴权外部请求只认网关的AK/SK不直接碰模型服务限流降级按用户、按接口维度配置QPS和并发限制缓存对于相同或近似请求可以做语义缓存命中后直接返回此前结果能省不少token灰度切换新模型版本上线时先切5%流量观察有问题再回滚成本方面我有两个习惯一是每次请求都记录token消耗按用户、按功能模块汇总这样每天能看清钱烧在哪二是对常见问题做“静态答案缓存”答案更新频率低的问题没必要每次都调用模型。需要重点提醒的是模型服务是状态相关的服务和普通Web服务的健康检查逻辑不太一样。不能只看进程活没活着还要看显存是否被打满、平均首token延迟是否漂移。我一般是每分钟检查一次/metrics超过阈值就摘掉节点并发告警。5. AI应用的测试、监控与持续迭代很多团队的AI应用上线后第一版效果不错第二周就变差了。这不是模型“变笨了”而是缺少了一套针对AI应用的质量保障体系。5.1 LLM应用测试和传统测试的差异传统后端测试断言很明确输入A输出B校验B是否等于B。但大模型的输出是开放式、概率性的你没法断言“模型这句话一定对”。所以AI应用的测试体系要分两层一层测工程逻辑一层测模型效果。测试类型测什么方法单元/集成测试接口解析、权限校验、链路异常普通pytest用例mock模型返回回归评估模型输出质量是否达标离线评估集 人工打分线上监控真实用户的输出质量日志分析 用户反馈打标成本监控token消耗是否异常按用户、按功能聚合5.2 离线评估集AI应用质量的压舱石我强烈建议从项目第一天起就建一个评估集。不需要很大50条高质量样本就能发挥巨大作用。每一条样本长这样{ query: 合同里的付款周期是多久, expected_points: [验收完成后30天], expected_sources: [contract_2024_001], difficulty: easy }之后每次改prompt、换模型、调切分参数都拿这套评估集跑一遍用脚本比对模型输出里是否包含expected_points中的关键点以及sources是否对得上。这种自动化回归能拦住绝大多数“改好了A问题带崩了B问题”的情况。我还用过一种更细的评估方式让模型当裁判用另一个模型给输出打分。但注意这种“LLM-as-a-judge”只适合做初筛关键业务还是得过人工这一关。5.3 线上监控盯住这几个指标就够了线上监控不需要一开始就铺很大我认为核心指标就这些请求成功率模型服务本身挂了还是网关限流了首token延迟 / 完整响应时间首token延迟更能反映用户体感空回复率 / 拒答率如果“无法回答”的比例异常升高可能是RAG召回全面失效平均每请求token数突然暴涨往往意味着提示词上下文拼接有问题用户反馈在对话流里加入“有帮助 / 无帮助”按钮成本低数据价值极高我还在日志里额外打了一个字段retrieved_chunk_score用来记录重排后最高分是多少。如果连续大量请求的最高分都很低说明知识库里没有对应内容应该触发“知识库补档”的提醒而不是等用户来抱怨。5.4 持续迭代的正确姿势AI应用上线只是开始。我的迭代流程是这样的收集线上badcase和用户反馈人工分析问题归类是检索不到、上下文丢失、模型理解错误还是知识库本身没有针对类别做修复检索问题改切分/召回/重排生成问题调prompt或换模型知识库问题补文档每轮修复后跑离线评估集确保没有回归灰度上线对比线上指标每一个循环大概1-2天比传统开发要快很多。这是AI应用开发最需要习惯的节奏小步快跑持续校准。6. 一次AI全栈项目的真实时间线复盘最后我用一个真实项目把前面所有内容串起来。这是一个企业内部的合同问答助手需求是用户上传一份合同AI需要回答关于合同条款的问题并且答案必须能回指到合同原文。整个项目从启动到上线用了5周人员只有我和一个兼职前端。第1周做的是需求澄清和spike。我们把业务方给的一百多份真实合同跑了一遍发现大部分是带标准模板的采购合同也有少数非常规的补充协议。这个发现直接影响了切分策略标准模板按条款切分补充协议按段落切分。这一周我们完成了模型选型和评估集初版20条。第2周搭RAG链路。文档上传、切分、向量化、召回、生成全流程跑通。前端只做了一个极简的聊天界面用于内部测试。这一周踩了一个印象深刻的坑向量化模型的输入长度是512token我们嵌入了大量超长chunk导致后面检索效果奇差。定位问题的过程就是看retrieved_chunk_score发现很多查询的召回分数都很低然后逐步排查到切分长度设置。第3周做Agent增强。业务方提了个新需求如果合同里有金额单价想直接问“这批货总价多少”系统要自动判断合同里是否有计算公式。这个需求单靠RAG做不好因为要结合表格甚至是附件。我们给Agent加了一个“表格抽取”工具模型在判断“直接从文本中找不到”之后调用工具再带着结构化数据生成结论。第4周部署上线。当时我们评估过直接接商业API和自己部署开源14B模型的成本。最后选择了自托管量化的方案原因是合同数据不能出域。我们在内网GPU机上用vLLM部署了量化版模型并在前面加了一层网关做限流和计费统计。这一周的主要工作其实是压测和调参QPS从最开始的2提升到15首token平均延迟压到了1.5秒。第5周做质量闭环。我们把线上badcase导出来逐条分析发现一个规律真正的问题大多数不在生成环节而在召回环节——相关条款没有被检索出来。我们把初召回从10条提到20条再引入重排模型效果就有了明显提升。最终离线评估集上的通过率从78%提升到了93%。这个项目走下来我最大的感受是AI全栈开发真正难的不是哪个单点技术而是整条链路的均衡。RAG做得再好部署高并发不行Agent写得再聪明没有评估集兜底提示词写得再漂亮知识库里没有对应内容——任何一个短板都会拖垮整个应用。最后分享两个个人习惯。第一我始终保留着一个本地脚本能一键把某个输入跑完“检索 - 重排 - 生成 - 评分”全流程改任何模块后都在跑一遍让自己心里有数。第二我每天会固定看一眼线上token消耗报表如果某个功能召回率下降或token异常飙升往往不是模型问题而是上游文档或者生产环境数据变动了。保持这种“全链路敏感度”大概就是AI全栈开发最核心的素养了。
