最近被问得最多的问题，不是“LLM原理是什么”，也不是“某某大模型又刷了多少分”，而是相当实际的一句：LLM在产品和项目里到底怎么落地，怎么才能不变成玩具，真正产生价值。
这个问题的背后，其实是一大批从“能跑通Demo”到“能不能上线”的困惑。我过去一年里，在各种项目里把LLM从模型选型、RAG搭建、Agent编排到垂域数据准备，完整地折腾过好几轮，踩坑不少，也沉淀了一些方法论。这篇就把这些经验整理出来，围绕“LLM落地”这个核心，聊聊场景判断、技术选型、数据准备、部署推理、评测体系这些关键环节，以及实操里那些文档上不会写的细节。
需要说明的是，我在文章里提到的很多参数、方案和流程，是基于我自己的项目实践和行业常见做法的合理补充，不一定照搬到每个场景都最优，但至少能给你一条从0到1的可靠路径。
1. 先想清楚：你的场景真的需要LLM吗，还是只需要一个关键词匹配
很多团队拿到LLM之后，第一反应是“赶紧找个场景塞进去”。但落地一家公司的真实教训往往是：用LLM解决一个不该用LLM解决的问题，比不用LLM更糟。因为LLM会引入延迟、成本、不可控的输出，如果原本用正则、分类模型甚至一张哈希表就能解决，硬上LLM就是把简单问题复杂化。
1.1 场景适配性判断：稳定可控比“聪明”更重要
我习惯用三个维度去筛场景：输入是否开放、答案是否要求确定、错误代价是否可承受。
如果输入是用户自由输入的短文本，比如客服对话、评论、工单描述，这类开放式输入用关键词或正则很难覆盖全面，适合引入LLM。反过来，如果输入是结构化参数，比如表单字段、数据库记录，LLM反而画蛇添足，直接查表更快更稳。
答案的确定性是另一个关键。LLM本质是概率生成模型，同样的问题两次回答可能不同。如果业务要求稳定输出固定格式的JSON、SQL、代码片段，你需要强力的输出约束和校验，而不是直接拿原始文本去用。如果不追求唯一正确答案，比如生成营销文案、概括长文档、头脑风暴，那LLM的“发散性”反而是优势。
错误代价要提前算清楚。LLM出错不是“有没有”的问题，而是“概率有多高”的问题。在金融、医疗这种错误代价极高的领域，不能假设LLM不出错，必须在应用层做兜底。错误代价低的场景，比如写周报、起标题、内容润色，用户自己会判断，容错空间大得多。
1.2 一张决策表帮你快速判断该不该上LLM
我整理了一张最简单的决策表，项目评审的时候直接对照打分，省了很多扯皮：
| 评估维度 | 适合使用LLM的情况 | 不适合使用LLM的情况 |
|---|---|---|
| 输入类型 | 自由文本、多语言、非结构化内容 | 结构化字段、固定枚举、有序参数 |
| 输出要求 | 生成式、摘要式、改写式、开放式问答 | 精确计算、固定格式存储、强事务逻辑 |
| 错误容忍度 | 有较宽容忍度，可人工修正 | 必须100%准确，错误会直接造成损失 |
| 频率和成本 | 低频调用，或高价值任务 | 超高并发、毫秒级响应、单次调用成本敏感 |
| 数据情况 | 有大量文档、知识库、非结构化数据待处理 | 数据已经结构化且逻辑清晰稳定 |
这张表的重点不是让你机械打分，而是逼团队在立项前提清楚：这个需求本质是什么，现有技术能不能做到，LLM带来的增量是否值得付出成本和不确定性。
1.3 需求拆解：把“我要用LLM”转成具体的用户任务
判断完场景之后，还要做一步需求拆解。我见过太多项目死在“需求太大、目标模糊”上，比如“做一个智能助手”。你要把它拆成具体的用户任务，比如“帮用户从产品手册里找到某个配置项的含义”“帮客服把用户投诉分类并生成处理建议”。每个任务都要能回答三件事：输入是什么，输出是什么，质量怎么算合格。
这一步决定了后面所有技术选型。任务拆得越细，技术方案越容易落地。如果一个任务既能用RAG做，也能用微调做，还能用纯Prompt做，说明你还没拆到位——真正拆解清楚的确定性任务，技术路径通常已经清晰一大半了。
2. 技术架构选型：RAG、微调、Agent到底怎么选怎么搭
确定场景之后，紧接着就是技术选型。这是LLM落地里最容易纠结的一环，本质上是在回答一个问题：知识从哪里来，能力从哪里来，逻辑从哪里来。
2.1 RAG增强：当前落地最稳的知识注入方式
RAG（检索增强生成）是目前垂域落地的首选方案。它的核心思路很简单：不把知识塞进模型参数里，而是把知识放在外部知识库（向量数据库），用户提问时先去检索相关资料，再把检索结果连同问题一起交给LLM生成答案。
为什么RAG是首选而不是微调？因为知识更新太频繁了。产品手册三个月升级一次、政策文件随时出新，如果用微调，每次更新都要重新训练，时间和成本都扛不住。RAG只需要重新切片、灌库，分钟级完成更新，而且可以溯源——答案引用了哪篇文档，用户可以点开核对，这对企业场景的信任度极其重要。
RAG落地有几个实操关键点。切片策略直接决定检索质量，我实践下来的经验是：优先按语义段落切片，而不是按固定字数硬切，还要保持段落间的标题上下文，避免切片后丢失“这个章节在讲什么”的背景。Embedding模型选择不能盲目追求大模型，中文场景BGE系列、m3e、bge-m3这类中文优化的模型效果往往更好，而且需要和切片长度匹配。检索策略上，关键词检索（BM25）和向量检索（语义）的混合检索往往比单纯向量检索效果好，很多项目实测Hybrid Search能把召回率提升20%到30%。
2.2 Agent与工作流：从“回答问题”升级到“完成任务”
如果说RAG解决的是“知识从哪里来”，Agent解决的是“事情怎么做”。落地场景里，Agent不是让模型自主瞎逛，而是给它一个明确的任务边界和一个可编排的工作流。
以我落地的“智能工单处理助手”为例：收到用户工单后，先调用分类模型判断工单类型，再根据不同类型触发不同的处理流程——查询类走RAG检索FAQ，故障类走故障树排查，投诉类走情绪识别和升级策略。每个步骤都是确定性逻辑，LLM只负责其中需要理解自然语言的部分，比如从工单里抽取关键实体、判断用户情绪、生成回复草稿。这样设计的好处是每个环节可测试、可回退、可观测，而不是把整个流程丢给一个不可控的模型。
Agent框架我分成两层看：编排层和执行层。编排层负责流程控制，可以用LangGraph、Dify这类工具，也可以用代码硬编码；执行层负责调用模型和工具，比如Function Call。落地初期，我建议先用最笨的硬编码流程把业务跑通，再逐步抽象成可配置的工作流，不要一上来就上高度自由式的Agent，否则排查问题时你会疯掉的。
2.3 垂域微调：什么时候真的需要动模型参数
RAG解决知识问题，但如果你的场景对输出风格、格式、逻辑有严格要求，且数据量足够，微调才有价值。比如让模型生成特定风格的舆情报告、按固定格式输出法律文书，这类“学会了就不会变”的领域能力，微调能提供更稳定的表现。
但是微调门槛比大多数人想的高。首先是数据准备，垂域数据要经过清洗、去重、格式化、质量筛选，至少需要几千条高质量样本，而且最好是“输入-期望输出”配对数据。其次，微调的效果下限很低，数据处理不好反而会损害模型的通用能力。很多团队上来就微调，结果模型学到的是数据里的噪声和错误格式，上线效果比基座模型还差。
我的建议是：优先用RAG加Prompt解决能解决的问题，把微调留给那些“规则稳定、数据充足、通用能力实在无法满足”的场景，并且在微调前后都要用一套固定评测集做对比，用数据证明微调确实带来了收益，而不是靠体感。
2.4 框架选型：LangChain、Dify还是自己写
框架选型是另一个人人都会踩的坑。坦白说，框架解决的是开发效率问题，而不是业务效果问题。业务效果取决于你的数据、Prompt和评测，跟用了什么框架关系不大。
我见过三个梯队的用法。第一梯队是零代码/低代码平台，比如Dify、FastGPT，适合快速验证和业务人员自助搭应用，你只需要配置模型、添加知识库、拖拽工作流，就能得到一套带界面的应用。第二梯队是LangChain、LlamaIndex这类开发框架，适合需要深度定制和代码集成的团队，灵活性高但学习成本不小，而且版本升级快，API经常变化，踩坑成本不可忽视。第三梯队是自己写，如果你的核心链路不复杂，比如就一个“检索+拼接+生成”的流程，直接写代码可能比引入框架更可控、更好维护。
我的取舍原则是：快速验证用Dify这类平台，正式进生产环境后，核心链路尽量用自己维护的代码或最少量的框架，把每一步抓在自己手里。曾经一个项目里LangChain升级之后某个Retriever的加载行为变了，线上检索效果莫名其妙下降，排查了半天才发现是框架行为变更，从那以后我就对重度使用框架这件事格外谨慎。
3. 垂域数据准备：决定落地效果上限的隐形工程
很多人以为LLM落地最核心的是模型，实际项目中花时间最多的其实是数据。模型决定能力下限，数据决定效果上限。垂域数据准备的过程，才是把通用模型变成垂域系统的最关键环节。
3.1 非结构化数据的清洗、切分与结构化
企业数据大多是PDF、Word、PPT、扫描件，看起来多，真要用起来才发现全是坑。PDF有表格、有页眉页脚、有多栏排版；PPT里大量信息在图形和备注里；扫描件需要OCR识别，而OCR结果的错别字率会直接影响后续检索效果。
我的处理流程一般是：先做格式转换，把PDF和Word转成纯文本或Markdown，注意保留标题层级和表格结构；然后做清洗，去除页眉页脚、页码、无关水印、重复内容，修正OCR错别字；再做切片，优先按文档结构切片，保持段落完整，一个片段在500到800字之间是较理想的长度；最后做结构标注，把标题、时间、章节信息保留下来作为元数据，方便后续检索时做过滤和排序。
这个环节最容易被低估的是表格数据处理。LLM在二维表格内容上的理解能力天然弱于文本，直接按行切分会导致上下文断裂，按整表处理又可能超出上下文长度。我实践下来相对好用的方式是：把表格转成“文本化描述”，比如把“产品参数表”转成“某产品的分辨率是1920x1080，刷新率是144Hz”这样的描述性句子，再去做切片和向量化，检索效果明显好于直接处理原表格。
3.2 评测集构建：没有评测，就没有改进方向
数据准备里最容易忽视但又极度重要的，是评测集的构建。没有评测集，你可能辛辛苦苦调了两周，却说不清效果到底变好了还是变坏了。
我运营LLM应用时，会同时维护三套评测数据。第一套是核心场景评测集，针对产品上线时的核心任务，准备200到500条真实用户输入和期望输出，覆盖典型问题、边界问题、刁钻问题。第二套是回归评测集，专门用来防止“改好一个问题，弄坏一片问题”，每次改Prompt、换模型、调切片参数之后，都要跑一遍确保历史能力没退化。第三套是Bad Case集，线上用户反馈里那些回答质量差的case，要持续收集并定期加入评测集。
评测方式也有讲究，纯靠人眼打分不可持续，纯靠LLM打分又不可完全信任。我试过比较稳妥的“双轨制”：客观题目（有标准答案的）用规则和LLM双重校验，主观题目（润色、概括、改写类）用LLM打分加上人工抽检兜底。评测指标的量化也要提前定义清楚，比如检索阶段的召回率、命中率，生成阶段的事实一致性、格式合规率、用户反馈满意度，这些指标上线后都是能直接指导优化的依据。
3.3 数据飞轮：从线上反馈持续反哺知识库
数据准备绝不是一次性工作。落地之后，线上用户会源源不断地产生新的问题、新的反馈、新的文档。如果知识库不更新，系统效果会随着时间逐渐变差，这就是我常说的“AI系统也会过时”。
我在项目里会搭一个简单的“数据飞轮”流程：线上用户的“没帮助”反馈、无法回答的问题、人工客服的修正结果，定期回流到数据层。经过人工审核清洗后，优质的新知识点补充进知识库，高频问题进入Prompt示例或评测集，反复出现且RAG解决不了的问题，考虑是否要微调。这套流程看起来不性感，但恰恰是LLM产品能持续保持效果的关键。
4. 部署、推理与成本控制：让模型稳定跑起来的实战细节
前面聊的都是“模型怎么变聪明”，这一章聊的是“模型怎么跑得稳、跑得省”。部署和推理是LLM落地里最容易被低估的工程环节，很多项目Demo漂亮，一上并发就崩，一算成本就亏。
4.1 API调用还是私有化部署，关键看数据合规和调用量
接API还是私有化部署，这是落地决策里绕不开的问题。判断标准主要有三个：数据是否涉密、调用量是否够大、网络链路是否可控。
如果数据敏感，比如金融、医疗、政务领域的业务数据，私有化部署是合规刚需，没有太多商量余地。如果调用量不大，比如每天几千次，直接用API往往更划算，因为自己部署GPU的一次性投入和维护成本都不低。如果业务依赖毫秒级响应，比如实时风控，本地部署在延迟上更有保障，省去了公网往返的时间。
我见过很多团队在项目初期就雄心勃勃地自建GPU集群，结果一个月调用量只有几万次，算下来单次成本比API贵了十几倍。我的建议是：先用API把业务跑通、验证价值，等调用量确实上来了，再逐步迁移到私有化部署，这个策略在成本和风险上好太多了。
4.2 推理优化：量化、批处理与并发策略
一旦决定私有化部署，推理优化的空间远比想象中大。首先是模型量化，把模型从FP16压到INT4或INT8，显存占用直接下降一半以上，推理速度大幅提升，而效果损失在现代量化方案下通常小到可以接受。我用AWQ和GPTQ量化7B到14B的模型，在实际业务里几乎没有感知到质量差异。
其次是批处理，也叫Continuous Batching，在vLLM这类推理框架里，把多个并发请求动态拼成一个Batch交给GPU推理，吞吐量能提升数倍。同样是A100上跑13B模型，做了批处理优化之后，每秒处理的请求数明显翻番，这就是为什么我一直强调生产环境一定用推理框架而不仅仅是原生的transformers库。
再就是并发策略，要把同步和异步分开设计。用户看到的“打字机效果”是流式输出，底层用SSE推给前端；但批量处理任务，比如夜间批量生成摘要、批量分类工单，可以走异步队列，错峰执行，避免和在线请求争抢GPU资源。显存不够的时候，优先缩小最大并发数，而不是强行降低batch size，这样单请求延迟更稳定。
4.3 成本核算：别让模型吃掉你的利润
成本核算是LLM落地里最实际的环节。我常用的粗算公式很简单：总成本等于模型推理成本加数据准备成本加运维成本。
模型推理成本，用单次调用平均时长乘以单Token成本再乘以调用量来估算。这里有个容易漏的坑：RAG方案里的Embedding成本，以及大Context下Prompt部分的Token消耗，往往占了大头。我曾经看到一个项目，用户只问了一个10个字的问题，但因为拼接了4个检索片段，单次调用消耗的Prompt Token就到了一千多，日调用一万次，光Token钱就是一个不小的数字。应对方法很直接：Prompt精简、检索片段按需截断、对超大文档做重排序之后再取Top N。
数据准备成本很多人不算，但它才是隐性大头。人工标注评测集、整理清洗知识库、写后处理逻辑，这些都是在烧人力。运维成本则是GPU的折旧、电费、带宽和人工维护。把这些都量化之后，你会发现很多场景根本不适合上LLM，或者需要大幅简化方案才能算得过来账。
5. 端到端落地实操流程：从Demo到上线的完整路径
前面讲了很多理论和选型，这一章给一条可以照着走的实操路径。我从多个项目的经验里总结出一条相对稳妥的路线，分六个阶段，每个阶段都有明确的退出条件。
5.1 第一阶段：需求定义与场景验证（1-2周）
这个阶段的目标不是写代码，而是把需求和验收标准定清楚。列出候选场景，拆成具体用户任务，标注输入输出和质量标准。比如“知识库问答”这个任务，输入是用户问题，输出是答案加引用来源，质量标准是“答案与知识库内容一致，引用来源正确，不能编造”。
然后做一轮快速可行性验证，用现成的API、100条样例数据，手工写Prompt跑一跑，看效果大概处在什么水平。这个阶段的目的是“验尸”：如果连用最强模型加上手工精心构造的Prompt都搞不定，那这个场景就别做了，或者需要换一个技术思路。
5.2 第二阶段：数据准备与评测基线（2-3周）
确认场景可行后，立即开始垂域数据准备和评测集构建。清洗非结构化数据，搭建知识库；准备200条左右的核心评测集；用当前最优的模型和最简单的Prompt模板跑出“基线成绩”。这个基线值非常重要，后续所有优化都要和它比，用数据说话，而不是用感觉。
5.3 第三阶段：技术方案实现（3-6周）
进入正式的开发环节。实现RAG功能，包括切片、向量化、检索、重排序、答案生成；实现Agent工作流，把多步任务编排起来；接入推理部署，保证接口稳定和并发可控。
这个阶段最容易犯的错是追求“大而全”。我见过一个团队在RAG还没调通的时候就开始做多Agent协作、自动规划，结果系统复杂到根本没法排查问题。正确的顺序是：先让单链路稳定跑通，再叠加复杂度。
5.4 第四阶段：Prompt调优与Bad Case定向优化（持续）
系统能跑通之后，真正的效果优化才刚开始。打开线上的真实流量，把Bad Case一条条过。分析每个Bad Case是败在检索（没召回相关内容）、理解（没明白问题）还是生成（回答了但格式不对），然后定向优化Prompt、调整切片策略、增加后处理规则。
这里有一个调试的技巧：任何一次修改，只改一个变量。改切片大小就只改切片大小，改Prompt就只改Prompt，改完后跑全量评测集，对比基线分数。一次改多个变量，出了问题连是谁导致的都分不清。
5.5 第五阶段：上线、灰度与监控（1-2周）
上线采用灰度策略，先开放10%的流量，观察延迟、成本和用户反馈，确认稳定再逐步放量。监控指标至少要覆盖：调用量、平均延迟、Token消耗、错误率、用户反馈“有帮助/没帮助”比例。
日志记录要提前设计好。我通常会记录用户问题、检索到的文档片段、最终答案、模型响应时长、用户的反馈动作，这些数据既是排查问题的重要抓手，也是后续数据飞轮的燃料。
5.6 第六阶段：持续运营与模型迭代（长期）
落地不是上线就结束，后面才是真正长期的工作。定期回流线上Bad Case，周期性更新评测集，优化知识库内容，跟踪模型厂商的新版本发布，评估是否值得升级。LLM技术迭代非常快，半年一个大版本是很正常的节奏，但升级绝不能盲目——一定要用评测集验证新版确实更好，才能切换。
6. 常见问题与排查技巧实录
最后分享一些我在实际项目中遇到的典型问题和排查思路，这些内容在官方文档里基本找不到，但遇到时真的很要命。
6.1 检索效果差：召回了一堆无关内容，怎么办
先判断问题出在哪个环节。最简单的方法是“裸看检索结果”：把用户问题直接拿到知识库里搜一遍，看返回的前几条文档是不是真的相关。如果不相关，多半是Embedding模型不适合你的数据领域，或者切片方式破坏了语义完整性。如果相关但生成的答案还是差，问题出在Prompt拼接或生成环节。
一个很隐蔽的坑是检索顺序和拼接顺序不一致。有些框架返回的检索结果按相似度排序，但拼接进Prompt时换了个顺序，或者把不相关的片段强行塞进去，导致模型被噪声干扰。排查时把实际发出去的Prompt完整打印出来看一眼，很多时候问题一眼就能发现。
6.2 幻觉问题：模型一本正经地胡说八道
幻觉是LLM落地的头号敌人，但“完全没有幻觉”在很多场景下不现实，现实的目标是把幻觉概率压低到业务可接受的范围内。我的经验是三层防线：检索层提高召回质量，确保正确的知识被召回；生成层在Prompt里强约束“只能根据提供资料回答，资料中没有的内容要明确说不知道”；输出层做引用溯源，要求答案必须标注来源编号，没有来源支撑的内容视为无效。
如果这三层都做了还有明显幻觉，可以考虑引入一个后置校验器，用另一个模型或者规则对答案进行事实性核查。虽然会增加一次调用成本，但在知识密度要求高的场景，这笔成本值得花。
6.3 延迟太高：用户打字都没你回复慢
延迟优化先定位瓶颈。一般有两个重灾区：一个是模型推理本身慢，解决方法是量化、换小模型、上推理框架开批处理；另一个是RAG链路里检索耗时长，尤其是数据量大时，向量检索加混合检索加重排序每一步都在加时间。解决方法是缓存、提前过滤、简化重排序。
另外注意流式输出，不要让用户干等到完整回答生成完才开始显示，让第一个字尽快上屏，用户的体感延迟会好很多。
6.4 常见问题速查表
| 症状 | 可能原因 | 排查思路 |
|---|---|---|
| 回答与知识库内容不符 | 检索未召回正确内容、Prompt约束不足 | 裸看检索结果，检查Top N文档相关性 |
| 回答格式不稳定 | 输出约束缺失、温度参数过高 | 使用结构化输出、降低temperature到0.2以下 |
| 系统提示词总是被忽略 | Prompt过长、指令冲突 | 精简Prompt，把核心指令前置 |
| 调用成本快速上升 | Context过长、无效Token多 | 精简Prompt、限制检索片段长度、加缓存 |
| 并发下延迟暴涨 | 批处理未开、显存不足 | 换推理框架开Continuous Batching、量化模型 |
| 更新知识库后效果反而变差 | 新旧数据冲突、脏数据进入 | 建立数据审核机制，新数据先小范围验证 |
| 同一问题回答每次都不一样 | 温度过高、检索结果不稳定 | 降低温度、固定检索Top N、增加缓存 |
这些问题是LLM落地里最常见的“新手村”关卡，每一关都不难，但没有经验的人会各踩一遍。把这些排查思路存成团队的内部手册，遇到问题先从表里对照一遍，能省下大量无头苍蝇式排查的时间。
我个人在实际操作中最深的体会是：LLM落地的技术门槛其实在快速降低，框架越来越成熟，模型能力越来越强，真正拉开差距的恰恰是那些“脏活累活”——数据清洗、评测集维护、Bad Case分析、成本核算。这些工作不性感，但决定了系统能不能从Demo走向用户。拿捏住“先保证可控，再追求智能”这条主线，你离一次成功的LLM落地就不远了。
