这几年做AI应用落地我反复被问到同一个问题大模型应用开发的完整流程到底是什么问的人里有刚转行过来的前端工程师、有做数据分析出身的研究生、也有不少已经在公司里顶着“AI负责人”头衔、但手里只有几个API Key的朋友。大家的困惑其实都差不多——大模型开发听起来很高大上可真要动手第一步做什么、第二步做什么好像没人给过一条清晰的路线。这篇文章想做的就是把这条路线摊开来讲。我不会去讲怎么从零训练一个基座大模型——那个方向门槛高、成本大绝大多数团队压根不需要走这条路。我要讲的“大模型应用开发流程”指的是在一个已经成熟的基座模型之上利用提示词工程、知识检索、模型微调、工作流编排这些手段把一个实际的业务问题用大模型能力解决掉、并且达到可上线状态的过程。打个比方不是造发动机是造车。如果你正准备入门大模型应用开发或者已经做了几个Demo但总觉得离“生产可用”还差一口气这篇文章值得你认真看一遍。里面所有的方法和参数都是我在真实项目里验证过、踩过坑之后总结下来的。1. 先搞清楚大模型应用开发究竟在开发什么很多新手一上来就懵是因为压根没分清“训练大模型”和“开发大模型应用”这两件事。这两个概念的差别比想象中大得多。1.1 一条分界线造发动机还是造车基座大模型是花了巨额算力、用了海量语料训练出来的通用能力载体类似一台已经点火的发动机。普通开发者在上面做应用基本不会去动发动机本身而是考虑怎么把这台发动机装进车里、配上方向盘和轮胎、再加上导航系统让一个普通司机也能开得又快又稳。这里说的“开发大模型应用”核心任务就是三层第一层是把已有的通用模型能力调用起来第二层是围绕具体的业务场景做定向增强比如给它喂私有知识、规范它的输出格式、把它和其他系统连接起来第三层则是全流程的工程化保障包括数据准备、效果评估、成本控制、内容安全策略、性能优化这些杂活。任何一层没做到位应用都很难真正落地。从入门到精通本质上就是把这三大层逐层做扎实的过程。你不需要会手写Transformer的前向传播但你必须清楚怎么用提示词把模型的潜力逼出来你不需要能复现一次全量微调但你要能判断什么时候该微调、什么时候不该微调以及微调需要准备多少数据、跑完怎么评估效果。这些技能才是大模型应用开发者真正被人付钱的原因。1.2 三条主流技术路线的选型逻辑在我经手的项目里绝大多数应用走的无非是下面三条路纯提示词工程只靠精心设计的Prompt让模型给出理想回答。适合逻辑简单、不依赖新增知识、对格式和风格有一定要求的场景。优点是没有额外基础设施成本和数据标注成本改起来也快一个Prompt就能完成需求迭代。检索增强生成RAG先把私有知识库切块、向量化、存进向量数据库用户提问时先检索出相关内容再把这些内容塞进上下文让模型参考作答。适合知识密集型场景比如企业知识库问答、客服助手、政策法规解读、故障排查助理。模型微调Fine-tuning拿一定量的高质量“输入-输出”样本继续训练基座模型让它学会某种特定风格、某个专业领域的表达方式或者某个固定流程的操作逻辑。适合需要模仿特定口吻、遵循特定格式模板、或是在某个窄领域内提升稳定性的场景。这三条路不是互斥的一个成熟项目经常组合使用。我常跟团队里的人说一个判断口诀能用提示词解决的不要上RAG能用RAG解决的不要上微调。因为复杂度是递增的后面的方案引入的变量和成本都更高。后面我会详细讲每一条路怎么做以及它们之间的衔接方式。2. 项目启动需求拆解、模型选型与架构设计很多人的第一步是选模型但我的经验恰恰相反。第一步应该是把业务问题彻底搞明白否则后面每一步都可能返工。2.1 把业务问题翻译成“输入-输出-约束”大模型应用本质上是一个封装好的函数它在给定的输入条件下通过模型推理产生输出同时受到一系列约束条件的限制。所以需求拆解的核心动作就是把你手头的业务问题翻译成清晰的“输入-输出-约束”三元组。举个例子。某公司想做一个内部规章制度问答助手。表面需求是“员工问什么它都能答上来”。但往下拆一层就会发现问题远没这么简单输入员工的自然语言提问可能包含口语化表达、部门名称缩写、甚至错别字还可能需要支持语音转文字后的文本输入。输出答案内容要基于该公司的真实规章制度不允许编造如果规章制度里没有相关内容需要明确说“制度中未找到对应说明”而不是强行回答答案长度要适中不能把整部制度原文长篇抛出来。约束回答时效要快内部工具超过10秒体验就很差涉及薪酬福利这类敏感问题时需要有边界意识系统要能区分“问题与制度完全无关”的场景并直接拒绝回答。这一层拆完项目的轮廓就出来了。你会发现“做一个问答助手”这个模糊想法被还原成了一套有输入接口、有输出规范、有异常分支、有边界条件的系统约束。后面选模型、设计提示词、搭检索链路全都是为了让这套约束稳定成立。2.2 模型选型的四个真实考量我一个朋友之前选型时只盯着“效果最好”这一个维度结果把方案做成了一台昂贵的重型跑车——效果确实不错但每调用一次的成本顶得上同类方案的二十倍。这就是选型只看一项指标的典型翻车现场。我的选型标准一般包含四个维度按重要程度排序第一是输出质量。这里的质量不是指“看起来牛不牛”而是指在你的特定任务上稳不稳定。判断方法很朴素拿20个有代表性的问题在几个候选模型上各跑一遍人工看一眼输出的准确率和风格契合度。这一步没法偷懒不能只看宣传评测的数字。第二是成本结构。成本不只是单次调用价格而是吞吐量乘以单次价格。你得估算每天的调用量级再核算一个月下来的总成本。有些模型虽然单次价格便宜但推理速度慢为了满足并发你可能得多开实例综合成本反而更高。第三是数据合规。业务数据能不能出内网如果不能就只能在私有化部署的开源模型里选如果能上云则可以考虑闭源API。现在很多企业把数据安全红线划得非常明确模型再强过不了这一关就没有意义。第四是生态兼容性。包括服务是否支持流式输出、工具调用是否有现成的SDK社区资料多不多。一个生态成熟的模型能帮你省掉大量开发过程中的绕路时间。选型的产出不只是一个模型名而是一份短名单。我习惯选两个模型做并行验证一个效果最优作为追求上限的方案一个性价比最高作为兜底方案。等到评估体系建立后用真实业务数据做最终裁定。2.3 一个最小可用架构长什么样需求拆完了、模型也定了接下来要落地一套架构。大模型应用的最小可用架构通常包含这么几条链路用户请求 → 输入预处理重写/判断意图 → 提示词组装含检索结果注入 → 模型推理 → 输出后处理格式校验/内容安全过滤 → 返回配套基础设施至少要有向量数据库用于RAG场景的知识检索、缓存层用于重复问题的快速命中顺便降成本、日志记录记录每次请求的输入、输出、耗时、Token消耗这是后续排查问题的底气所在。很多新手一上来就把架构设计得很复杂上了好几个中间件、拆了十几个微服务。实际上对一个MVP阶段的应用来说一个单体服务加上一条数据库连接就足够了。架构越简单出问题越容易定位。等流量和场景真正涨起来再考虑拆分不迟。记住一个原则架构是为业务体量服务的不是为简历服务的。3. 核心环节落地提示词、知识检索与微调这三块是大模型应用开发的核心主战场也是大多数人花时间最多的地方。3.1 提示词工程的四层实战操作提示词工程看起来人人都能做但要做得稳定可靠需要有一套成体系的方法。我一般会把提示词拆成四个层次来写。第一层角色与背景设定。明确告诉模型它现在是谁、在什么场景下工作。这一层的价值在于激活模型在特定语境下的先验知识。比如做制度问答就给模型设定为“你是某公司人力资源部的政策解释助理只依据给定的制度条例回答问题”。第二层任务目标与流程说明。用最直白的语言告诉模型需要完成什么任务如果任务复杂则在提示词中明确执行步骤。比如先判断问题是否与制度相关再检索对应条款最后给出结论。给模型明确步骤能大大减少它自由发挥的概率。第三层输出格式与表达约束。扎实的工程经验是把你要的格式用例子写清楚模型照着做的成功率远高于用文字描述。下面是一个我在项目里用过多次的提示词模板骨架你是{角色设定}。 背景{业务背景信息} 任务{需要模型完成的具体任务} 要求 1. 只能基于以上提供的参考内容回答不得引用参考内容之外的知识 2. 如果参考内容中没有相关信息直接回复“未找到相关内容” 3. 回答控制在200字以内分条列出 4. 不要输出JSON以外的任何内容。 参考内容 {检索结果/知识片段} 用户问题{用户输入}第四层边界与兜底措施。这是新手最常忽略的一层。包括模型不知道答案时该怎么说、遇到恶意问题该怎么办、问题与任务无关时如何回应。没有这层约束模型往往会在知识盲区上开始“一本正经地编造细节”这是大模型应用上线后最让人头疼的问题之一。写完之后一定要反复测测试时不仅看正确答案更要在边界问题上跑一遍。我的习惯是准备30条左右的测试用例其中正常问题、模糊问题、越界问题各占三分之一这样测完心里才有底。另外提示词的改写要留档每次改动记录一下哪次效果变差能及时回滚。3.2 知识检索RAG的链路细节RAG是让大模型应用真正具备“私有知识”能力的关键方案。它解决的核心痛点是模型训练时没见过你的公司制度、你的产品参数、你的私有文档你再怎么改提示词模型也说不出它不知道的内容。而RAG的思路是每次回答问题前先把相关资料“查出来”再让模型看着材料说。原理上不复杂但做起来有很多细节。文本切块策略。知识文档不是一股脑塞进数据库的。你先把文档拆成小块每一块就是一个检索单元。切块的大小直接影响检索效果块太大检索出来的内容太泛模型找不到重点块太小语义不完整检索召回的信息支离破碎。我的经验是普通制度文档按段落切一段一个条目技术手册按章节结构切保持语义完整性具体块大小结合Token上限来定一般每一块控制在300到500字之间比较稳妥。在切块这个环节还要注意一个问题不要把一段完整的话拦腰截断。有些机械的切法会把一个连续的说明文字从中间劈开检索出来之后模型看到的都是半截话回答自然语无伦次。所以切块逻辑里最好做一次“完整性校验”看到块尾不是句子结束符就往后延伸到句号。向量化与检索。每个文本块通过嵌入模型转成向量存进向量数据库。用户提问时同样转成向量再用余弦相似度或内积找到最接近的若干块。这里有两个关键参数值得展开说说。一个是Top-K也就是召回多少条相关片段。取值太小容易漏掉关键信息取值太大又会对模型造成干扰把不相关的内容也塞进上下文。我做知识库问答时一般先从K4开始试再根据评测结果上下调整。另一个是相似度阈值低于阈值的检索结果说明匹配度太低这时候宁可让系统报“未找到”也不要硬把无关内容喂给模型。这个阈值要靠测试数据来标定没有放之四海皆准的数字。重排序。如果知识库规模很大或者检索结果经常出现“看着相关、实际不相关”的情况可以在向量检索之后再加一个重排序环节。重排序的精髓是向量检索只是一个初筛它擅长语义匹配但不擅长精细判断重排序模型则能更准确地判断“这段内容对当前问题有没有直接帮助”。经过重排之后只保留最靠前的3到5条喂给模型回答质量会有明显提升。代价是多一次模型调用延迟我的原则是知识库条目超过一万条时建议加上。上下文组装问题。需要注意检索结果和用户问题之间通常还要做一个“压缩”处理。原始文档块往往带着大量无关前缀后缀直接塞进提示词会白白浪费Token还会稀释模型对关键信息的注意力。我习惯在组装前做一次清洗去掉无意义标题、去除重复内容、把关键句段提取出来。这一步属于脏活累活但收益非常直接——很多效果问题排查到最后发现不是模型不行是喂进去的材料太脏。3.3 微调不是万能药但用对了很香微调是这三条路线里门槛最高的一条但我还是要先说一句可能会得罪人的话大部分场景用不着微调。看到某个任务效果不满意第一反应应该是调提示词第二反应是优化检索两条路都走不通了再考虑微调。这是成本逻辑决定的——一次微调要准备数据、要花训练钱、还得维护一套专门的模型版本如果这些成本换不来显著的效果提升那这步棋就不划算。但有些场景确实非微调不可。我在一个内容分析项目里遇到过这样的情况基座模型本身文字功底极强但让它按特定公文格式输出一段综合分析时十个输出里有五个格式错乱提示词怎么约束都压不住。后来用了两百条人工整理的标准格式样本做了微调格式准确率从不到五成直接拉到九成以上。这就是微调的典型价值——当模型能力没问题、但风格或格式稳定不住的时候用数据帮它强化肌肉记忆。微调的数据准备是最关键的环节我踩过最大的坑是拿低质量数据硬凑。微调的本质是“让模型照着样本学”样本烂模型就学烂而且这种烂是全局性的会污染模型原有的泛化能力。所以每一条训练样本都要保证输入是真实用户会说的话输出是正确的、高质量的参考答案。数量上两百条通常是个底线质量高的话几百条就很见效果质量不行几万条也只是在巩固错误。另外要提醒一点微调之后必须做回退验证。基座模型本身是很强的通用能力体微调训练不好的话可能把原有能力“冲淡”。所以微调前后的模型要在同一套评测集上做对比既要看目标任务指标涨了多少也要看通用能力指标有没有掉。如果涨的少掉的多说明训练配置出问题了得调整。4. 从“能跑”到“能用”评估体系与性能优化很多人做出Demo之后很兴奋但一到上线就犯怵因为Demo环境里看着不错的模型放到真实流量里状况百出。这个落差的核心原因是没有建立一套自己的评估体系。4.1 搭建一套够用的效果评估基准评估体系不是说“我觉得它答得挺好”就行。它要能量化地回答三个问题这个应用在核心任务上行不行、在边界情况上扛不扛得住、一段时间之后效果有没有退化。我的做法分三步。第一步建评测集。从真实业务数据里抽一批有代表性的问题按难度和类型分层整理最少也要一百条。这个评测集就是测试试卷后面所有改动都在这张试卷上打分。第二步定指标。客观题看准确率判断模型答案和标准答案是否能对齐主观题看人工评分评估相关性、完整度、格式达标率还必须有安全合规率指标——不碰红线、不输出不该输出的东西。第三步跑回归。每改一次提示词、每换一次检索配置都在评测集上完整跑一遍对比分数变化。没有这套基准你根本说不清楚这次改动是变好了还是变坏了。还有一个细节很多人会忽视评估集需要持续更新。真实用户的提问方式会变化产品功能也会迭代。我建议每个月从线上日志里抽一些新问题补充进去避免评测集和真实世界发生偏离。4.2 性能与成本优化的几个杠杆应用上线之后延迟和账单就成了日常关注焦点。这里分享四个我常用的优化杠杆按性价比排序。第一个杠杆是结果缓存。用户的问题往往有很高的重复率尤其是客服、问答这类场景前十的高频问题可能占了整体流量的四成。这些重复问题完全可以命中缓存不用再调用模型推理。我在一个知识问答项目里加了缓存以后整体推理调用量下降了约三成这个优化半小时就能落地。第二个杠杆是模型分级路由。并不是所有请求都需要调用满血版大模型。简单问题、机械问题交给小模型的性价比极高只有复杂问题才让大模型出手。做法是在入口处加一个意图分类模块判断问题复杂度然后分流到不同规模的模型。这个方案能大幅度降本但前提是你得先有足够的数据来判断哪些问题适合走小模型。第三个杠杆是流式输出。把模型推理结果按token逐个推送给前端用户首字到达时间从几秒压缩到几百毫秒体感提升极其明显。这个方案不改变总耗时但大幅改善了等待焦虑属于投入小、收益大的优化。第四个杠杆是上下文瘦身。很多应用会把历史对话全部塞给模型时间一长Token消耗飞涨。实际对话里大部分历史早就没有参考价值了。我习惯做滑动窗口只保留最近几轮关键内容再配合摘要机制把更早的历史压成一小段概括。这么做对成本、对回答质量都有正向作用。5. 常见问题排查与避坑实录这个环节最想分享的是排查问题的一整套思路它比具体某个问题的答案更有长期价值。5.1 一套通用排查思路先分层定位大模型应用的问题有个特点表面症状一样内在病根可能完全不同。比如“模型回答得不对”可能是提示词写得不清可能是检索结果太差可能是模型本身能力不足也可能是输入数据就错了。如果一上来就直接改提示词大概率是瞎猫碰死耗子。我的排查思路是分层定位法。把整个应用链路拆成几个独立层输入层、检索层、提示词层、模型层、输出层然后一层一层隔离验证。遇到问题先复现拿到具体的错误案例然后逐层“绕过”绕过检索层直接给模型喂正确答案看它能不能答对绕过模型层直接看检索结果和输入原文确认数据链路上有没有问题。哪一层能稳定复现问题问题就在哪一层。举一个真实经历过的例子。有个客服问答项目上线后用户反馈说“同一个问题隔几天回答就变了”。看着像是模型随机性的问题但排查后发现答案变化来自知识库里的文档被重新上传了一次新的切块方式把原有语义块切碎了导致检索召回了错误片段。从现象看是模型输出不稳定实际原因是数据链路变更。如果没有分层定位的思路这个问题可能要花一周才能找到源头。5.2 高频问题速查表这里把我在多个项目里反复遇见的共性问题整理成一个速查表高频现象可能原因排查方向与解决建议回答内容明显与事实不符甚至编造信息检索召回不相关、知识库缺失、提示词未加兜底约束先检查Top-K和相似度阈值确认相关文档是否已入库在提示词里明确“无相关内容时禁止编造”答案正确但格式经常乱输出约束描述不清晰在提示词中附带输出格式示例减少文字描述必要时考虑微调模型答非所问跑题严重提示词中任务目标含混、上下文夹杂过多无关内容把任务指令前置删减无关背景信息检查注入的检索片段是否和问题匹配请求响应很慢上下文过长、模型过重、没有流式输出压缩历史对话做滑动窗口评估是否可以用更小的模型处理该请求开启流式输出提升体感相同问题结果波动大模型温度参数过高、检索结果排序不稳定降低temperature参数通常问答场景温度设在0到0.3之间比较稳上线一段时间后效果变差线上用户提问分布变化、知识库更新未做回归每月更新评测集覆盖新问题建立版本回滚机制Token消耗比预期高很多上下文堆积过长、检索内容重复冗余开启缓存压缩历史清洗检索片段减少冗余信息还有一个容易被忽视的“冷知识”日志一定要好好记。每个请求至少记录用户输入原文、最终提示词全文、模型输出、响应耗时、Token用量、检索命中的文档ID。哪天线上出问题了这些日志就是你还原现场的唯一依据。没有日志系统的项目出了问题只能靠猜而靠猜解决问题的成功率大家心里都有数。再补一条经验关于提示词版本管理。大模型应用的迭代链路里提示词是最频繁改动的东西也是最大的风险源。我的做法是把每一条提示词都纳入专门的目录管理文件命名带日期和版本号改动后先在评测集跑回归再上小流量灰度。曾经有一次团队里有人为了修一个小问题直接改了线上的提示词结果影响了一大片正常回答。从那以后凡是改动提示词必定走评审流程。这条规矩看起来麻烦但它在关键时刻能救命。写在最后做了这么多年大模型应用落地我最深的体会是大模型开发的门槛正在降低真正拉开差距的不是谁用的模型更大、更先进而是谁能把流程做扎实。模型的调用方式越来越标准化但需求拆解的深度、提示词打磨的耐心、检索链路细节的把控、评估体系的严谨程度才是决定一个应用能不能真正被用户使用、能不能长期稳定运行的关键变量。如果你现在正准备启动一个大模型应用项目我建议你不要急着写第一行代码先按这篇文章的思路把需求和选型想清楚把评测集建起来再开始动手。很多走过的弯路本质上都是前面省掉的功夫在后面加倍补了回来。希望这篇文章能帮你少走几步弯路。