做 AI 应用这些年我见过太多团队在第一版 LLM Demo 上栽跟头。日报里写着“大模型驱动智能助手”实际跑两周就卡在文档解析、上下文超限、回答幻觉这些细节上。LLM 真正落地到产品从来不是把某个商用 API 接进来就完事而是把模型塞进现有业务链条后还能稳定、可控、便宜地跑起来。这篇内容围绕 LLM 在产品和项目里的落地路径聊聊我从方案选型、RAG 搭建、框架取舍到评测调优踩过的坑适合正在做智能问答、知识库助手、Agent 类产品或者打算给公司内部系统接入大模型的团队参考。1. 落地路径与方案选型思路1.1 三种典型形态Prompt 直出、RAG 增强、垂域微调刚接触 LLM 的团队最容易犯的错是拿到一个模型就想着“全场景一把梭”。真正要落地第一步不是写代码而是先确定业务到底适合哪种技术形态。我一般把落地方式分成三类各有各的适用边界。第一种是 Prompt 直出适合系统提示词足够覆盖业务规则的场景。比如做邮件分类、意图识别、文本润色、代码生成辅助这类任务输入输出短、判断逻辑清晰模型靠自身能力就能完成不需要外部知识。优点是上线最快成本最低缺点是模型能力是多少就是多少超出能力范围后无法补救。第二种是 RAG 增强检索这是目前企业知识库问答、客服辅助、内部文档检索最主流的方式。核心思路是先把业务知识切成向量块存入向量数据库用户提问时先检索出相关片段再拼进 Prompt 让模型基于这些片段作答。它能解决模型不知道企业内部知识的问题还能在回答后面附上引用来源。热词里反复出现的“RAG增强LLM”本质上就是为了解决模型知识陈旧和幻觉问题。第三种是垂域微调适合特定领域术语密集、输出格式高度固定的场景比如法律文书生成、医疗诊断辅助、金融研报结构化抽取。微调成本高需要准备几千条高质量标注数据还要有训练和评估的环境但它能把模型“调教”成某个领域的专家回答风格和术语使用会更贴合业务。怎么判断选哪条路我有一个比较实用的判断顺序如果业务知识经常变动选 RAG如果输出格式和领域规范极其严格选微调如果两者都有优先“RAG 少量示例”并行等数据积累够了再考虑微调。绝大多数场景先用 RAG 扛住等用户反馈和标注数据累积到一定程度再补一轮低成本微调是性价比最高的路径。1.2 为什么多数业务线优先走 RAG 而不是微调业务方跟我聊 LLM 落地时十个里有八个第一句话就是“我们能不能微调一个自己的模型”。我的回答通常是先别急你大概率用不上微调至少一开始用不上。微调最大的问题是迭代周期长。一次微调从数据清洗、标注、训练到评测顺利的话也要一两周不顺利的话调参调一个月都有可能。而业务知识每周都在变培训资料更新、产品功能变化、客服话术调整这些动态内容根本赶不上微调的节奏。RAG 就没有这个烦恼知识库更新就是替换文档、重新切片、重新向量化几分钟内就能让模型“看到”最新内容。另一个关键点是可追溯性。RAG 生成回答时可以引用原始文档来源用户在系统里点了“查看引用”能看到答案出自哪份文件、哪个章节信任感完全不同。微调模型则是一个黑盒它就是凭“记忆”回答出错了你根本不知道它依据的是什么。在很多有合规要求的行业比如金融、医疗、法律“必须能追溯到依据”就是硬门槛光这一点就把微调挡在门外了。成本也是实打实的。微调要准备训练环境、存储数据、跑多次实验人力投入和 GPU 开销都不是小数目。RAG 的推理链路里检索是传统技术生成部分用现成 API 或开源模型成本结构更可控。初期用一个通用模型加索引好的知识库已经能满足大部分问答需求完全没有必要一开始就上微调。1.3 已落地项目里 RAG 链路的通用架构这里直接给出一套我实践下来比较稳的 RAG 架构很多“已经落地的大模型项目”核心结构都是这一套。整体分成五个环节数据接入、切片清洗、向量化、检索排序、生成回答。数据接入环节处理各种格式的源文件PDF、Word、Markdown、HTML、甚至扫描件 OCR。切片清洗是把长文档拆成合适大小的 chunk处理掉页眉页脚、重复内容、表格等特殊结构。向量化是用 embedding 模型把每段文本转成向量存进 Milvus、Weaviate 这类向量数据库。检索排序是用户提问时把问题也转成向量做相似度检索再用 Rerank 模型在召回结果里重排选出最相关的片段。生成回答环节把检索结果、用户问题、系统提示词组装成 Prompt交给 LLM 输出最终答案。这套链路每一步都有优化的空间。比如切片大小切太大检索精度会下降切太小会丢失上下文比如 embedding 模型选哪种通用模型和垂域模型的效果差距能到 10 个百分点以上比如重排环节缺失只靠向量相似度召回经常把“相关但没用”的片段排到前面。这些细节我后面展开讲它们才是决定项目到底能不能在业务里长期跑下去的关键。2. 核心设计上下文管理、提示词与输出约束2.1 提示词不是写几句话术是一份接口说明很多团队把提示词工程理解成“给 AI 写一段客气话”这是大错特错。在一个工程化产品里提示词承担的职责是明确角色、交代任务、限定范围、定义输入变量、约束输出格式。它的本质是一份给模型看的接口说明必须像设计 API 一样去设计。我常用的一套结构化模板大致长这样你是一个企业制度问答助手。请只依据下面提供的资料回答问题不要使用资料以外的知识。 如果资料中没有相关内容请明确回应“当前资料中未找到相关信息”。 【参考资料】 {retrieved_context} 【用户问题】 {user_question} 要求 1. 用简洁的中文回答控制在150字以内。 2. 回答必须对应资料原文并且在末尾列出引用来源的文档标题和页码。 3. 如果问题涉及多个方面请分点作答。这个模板里角色定义让模型知道行为边界限定“只依据资料”能显著降低幻觉“未找到相关信息”的兜底给了模型一个“合理拒答”的出口而不是硬编答案输出格式约束保证了产品展示层的稳定。真正跑生产后发现提示词里明确写出“如果……请回应……”这类兜底分支是减少胡编乱造最有效的方式之一。提示词还有一个容易踩的坑往里面塞太多个 few-shot 示例。示例多了会占大量上下文空间而且模型容易模仿示例的语气和长度导致输出偏离预期。实践经验是示例数量控制在 3 到 6 个每个示例都选最有代表性的边界情况而不是平均情况。比如要约束输出 JSON就放一个“不完整输入导致输出占位字段”的示例比放十个正常示例管用得多。2.2 token 成本计算与上下文塞选策略大模型产品的成本结构跟传统软件完全不同。传统软件每请求成本趋近于零大模型则是每请求都烧钱而且烧多少取决于你往上下文里塞了多少内容。有些项目上线后才发现成本超出预算追根溯源就是 Prompt 越堆越长把成千上万的 token 每次请求都送给模型。成本估算其实很简单商用 API 按 token 计费1 个中文汉字大约对应 1.5 到 2 个 token成本等于输入 token 数乘以单价加上输出 token 数乘以单价。举个例子一个知识库问答产品Prompt 里固定指令 200 token检索召回 4 段文本每段 500 token用户问题平均 100 token那么单次请求输入就是 2300 token。按某主流模型输入约 0.03 元每千 token 计算单次输入成本大约 0.07 元输出按 0.09 元每千 token 算每次回答 200 token 是 0.018 元。单看一次不贵但一天一万次调用就是小一千元的开支月度成本立刻变成业务要掂量的事。控制成本的关键是“上下文塞选”。我把送入模型的内容分成三类固定指令、动态检索内容、会话历史。固定指令是系统提示词必须精简去掉所有不影响回答质量的修饰词。动态检索内容要控制召回数量和单段长度设置相似度阈值低于阈值的片段坚决不送进模型。会话历史最容易被忽视多轮对话里把所有历史消息都送进去上下文会迅速膨胀正确做法是只保留最近 N 轮同时做摘要压缩用一句话概括更早的对话。还要考虑缓存。很多大模型平台支持 prompt 缓存如果固定指令和知识库内容不变命中缓存后成本能下降一大截。我自己在项目里会把静态知识库内容放在 Prompt 的固定前缀区域配合缓存机制长上下文场景下成本至少省三分之一。2.3 输出工程化JSON、function calling 与工具选择器把模型输出喂给前端页面直接展示这只是最基础的用法。真正到业务流程里模型输出经常要进数据库、触发下游系统、驱动工具执行这时候输出格式的稳定性就变得极其重要。最理想的输出形式是 JSON。让模型返回结构化 JSON然后程序解析字段再做后续处理。但模型输出 JSON 有一个著名的不稳定问题偶尔会多一个逗号、少一个引号或者把注释也带出来JSON.parse 直接抛异常。工程上的解法是三重保险第一提示词里给出 JSON Schema 示例明确字段名和类型第二用大模型平台自带的 JSON 输出模式比如 OpenAI 的 response_format 参数第三代码层面做容错解析失败时做一次轻量修复比如去除多余换行、补全缺失引号再解析一次还不行才走失败重试。function calling 则是更高级的出参方式。模型不直接输出用户看到的答案而是输出“我应该调用哪个工具、参数是什么”程序执行工具后把结果交还给模型组织最终回答。这个模式是 Agent 类产品的基石。比如用户问“帮我查一下订单状态”模型判断需要调用订单查询工具输出一个规范化的函数调用请求程序执行后拿到订单数据再让模型基于真实数据回答用户既准确又可控。工具多了以后还有一个新问题该选哪个工具。LangChain 里的 tool selector 解决的就是这个事。它把工具名称和描述收集起来让模型根据用户意图做一次工具选择而不是把所有工具的结果都塞给模型。减少上下文压力也减少工具调用的噪音。我在实际项目里会把高频工具的使用意图写成很详细的描述比如“当用户提到退款、退货、售后问题时使用此工具”模型选工具的准确率会明显提升。3. 工程框架选型自研、LangChain 与低代码平台3.1 先判断要不要用框架刚开始做 LLM 应用时团队里经常争论要不要上 LangChain 这类框架。我的看法是框架不是必需品它只是帮你省掉一些样板代码同时也会引入一层抽象调试起来反而更绕。小型项目或验证原型完全可以直接用 HTTP 调用模型 API自己拼接 Prompt、解析结果代码量并不大。等到要处理复杂链路比如多步检索、工具调用、条件分支、记忆管理时再用框架不迟。从“落地”的角度看选框架的本质是选团队熟悉的技术栈和后期可维护性。你的团队如果全是 Python 背景LangChain、LlamaIndex 生态完善开发效率高如果是 Java 或 Go 为主维护一套 Python 微服务可能增加运维负担不如用各家的官方 SDK 直接开发。我自己踩过的坑是为了“业界最佳实践”引进一个全家桶框架结果出了问题不知道是业务代码的问题还是框架内部的问题排查链路拉得特别长。3.2 LangChain 与 Dify 的适用场景对比LangChain 和 Dify 是两种完全不同的路线。LangChain 是一个 Python/TypeScript 的开发框架提供 Chain、Agent、Retriever 等抽象适合工程师从代码层面高度自定义流程。Dify 是一个低代码 LLMOps 平台提供可视化编排界面适合产品、运营同学拖拽搭建应用也适合快速搭建内部工具。放到实际项目里我是这么选的如果要做 ToB 交付、需要深度定制、要嵌入现有业务系统选 LangChain因为别人拿过去可以二次开发如果团队以业务人员为主、要快速上线智能客服或知识库内部工具选 Dify因为它把大量工程细节比如知识库管理、Prompt 编排、日志追踪都封装好了。这里补充一个 Dify 里设置 LLM 的实操思路。Dify 支持配置多种模型供应商你在“设置”里填模型 API 的 Key 和 Base URL就能接入不同的模型。配置时最关键的是选对模型规格聊天场景选对话模型向量化选 Embedding 模型两者不能混用。如果用开源自建模型做了 OpenAI 兼容接口Dify 也支持填入兼容地址只要协议一致就能跑通。这个灵活性让 Dify 成为一个很不错的“模型网关”团队可以随时在管理台切换底座模型不影响上层应用逻辑。为了说得更清楚我用一个表格把两个框架的关键差异列出来对比项LangChainDify定位开发框架低代码平台适合人群工程师产品/运营/工程师定制程度高代码控制一切中受平台能力边界限制上手速度慢需理解抽象概念快拖拽即可知识库支持需集成向量库和分片逻辑内置完整知识库管理日志追踪需自行接入内置可观测性面板生产部署自己维护服务平台化部署或私有化选 LangChain 还是 Dify本质上是用“灵活性”换“开发效率”来权衡。很多已经落地的大模型项目尤其是企业内部工具反而选 Dify 居多因为它把维护成本压到了最低业务人员自己就能调整问答效果不用次次找研发提需求。3.3 快速搭一个企业内部知识问答的参考链路这里给一个参考的搭建过程需求是“企业制度问答助手”希望员工输入问题后系统能根据公司制度文档回答并且标注参考出处。第一步准备文档把各种制度 PDF、Word 统一转成 Markdown 或纯文本保证后续切片质量。第二步切片按语义段落切分控制每块在 300 到 500 字左右保留章节标题作为上下文前缀。第三步向量化选一个合适的中文 Embedding 模型把切片转成向量后存入向量数据库同时把原始文本和元信息标题、页码一并存好。第四步搭建应用用 Dify 创建聊天助手类型应用选择知识库作为数据源编写系统提示词打开引用来源开关。第五步测试拿 50 到 100 个典型员工问题跑一遍看回答准确率和引用是否正确针对不达标的问题调整切片粒度或提示词。第六步上线接入企业微信或内部系统把应用链接嵌到员工门户。整个过程快的团队一天就能跑通一个内测版这正是低代码平台给业务带来的价值。但如果要做对外客户服务的助手还涉及多轮对话管理、情绪识别、服务质检、工单联动那就需要更偏代码层面的定制LangChain 或其轻量自研方案会更顺手。4. 效果评测与调优从“能跑”到“好用”4.1 没有评测集一切优化都是拍脑袋大量 LLM 项目死在“感觉还行”四个字上。Demo 演示时问题少、场景简单模型看起来聪明一上生产用户什么问题都敢问效果立刻崩。所以项目一启动就应该同步搭评测集不要等做完才来想怎么测。评测集怎么建拉上业务方一起把真实用户可能问的问题梳理出来至少 200 条起步覆盖高频问题、边界问题、模糊问题、恶意问题四类。每条问题配上标准答案和引用来源答案不唯一时也要明确哪些答案是可接受的。没有评测集后面每次改代码、换模型、调参数你都不知道效果是变好了还是变差了只能靠感觉这在工程上等于裸奔。有了评测集之后每次改动跑一遍离线评测对比新旧结果。这个流程坚持下来团队对“改这个参数会带来什么影响”会有非常直观的认知。对比测试时最好并排看旧答案和新答案不要只看分数文字类答案的细微语义差异分数不一定能反映出来。4.2 关键指标召回率、相关性、幻觉率与拒答率不同阶段关注不同指标。检索阶段关注召回率和排序相关性重点看系统能不能把真正相关的知识片段找回来并排到前面。生成阶段关注答案的相关度、幻觉率、拒答率重点看模型有没有严格基于检索内容作答有没有编造不存在的信息以及遇到知识库外的问题时能不能得体地拒答。落地时可以设置这样一套参考指标核心问答准确率不低于 90%来源引用准确率不低于 95%幻觉率控制在 5% 以内拒答率不超过 10%。这些数字没有行业金标准但能作为一个团队内部的质量门禁。低于门禁不上线而不是“领导说可以就推”。还有一类容易被忽略的指标是多轮交互体验。用户追问“那退款呢”单轮评测里根本测不出来系统需要理解“那”指代的是上一轮聊的订单问题。多轮评测要设计连续提问的用例验证系统在上下文延续、话题切换、澄清追问上的表现。4.3 调优三板斧数据清洗、切片调整、检索重排评测结果出来后优先动哪里我的顺序永远是先看数据、再看检索、最后才动 Prompt 和模型。数据问题永远在前面。数据清洗听起来基础但影响极大。很多企业内部文档带着目录、页眉、重复声明直接切片送入向量库检索时会被这些噪声干扰。清洗阶段要统一格式、去掉无用信息、合并重复内容。还有一个常见的脏数据问题同一件事在不同文档里说法不一致。这种冲突数据在检索时极容易让模型给出矛盾答案数据准备阶段就要人工标记或合并。切片策略也值得反复调。切片大小直接决定检索粒度我用过一个简单的对比把制度文档切分成 200 字的短块检索出的结果片段小而精准但缺少前后文改成 800 字的长块检索出的结果背景信息充足但混入了无关内容后相关性下降。折中做法是“父块子块”策略用小块命中检索返回时附带大块的上下文内容兼顾精度和完整性。垂域 LLM 数据准备阶段这个策略几乎成了标配。检索重排是最后一个高收益优化点。向量相似度是粗排和真实语义相关度之间存在差距。引入 Rerank 模型做二次排序把向量检索召回的 Top 20 片段精排到 Top 5准确率通常会有明显提升。这是目前效果最好、也可以说是最“值得花钱”的环节尤其是知识库内容多、相似内容密集的场景不加 Rerank 和加了是两个体验。5. 常见问题与排查技巧实录5.1 问题速查表现象、原因、对策把日常运维中的高频问题整理成一张速查表方便团队对照处理问题现象可能原因排查与对策回答内容与知识库不符检索未召回正确内容检查切片和向量化质量调整相似度阈值引入 Rerank引用了不存在的来源元信息在向量化时丢失确保原始文档标题、页码随向量一起存储并在生成时传给模型上下文长度爆了会话历史或检索片段过多设置滑动窗口策略历史消息做摘要压缩限制检索片段数量模型输出 JSON 解析失败输出格式约束不严提示词中补充 JSON Schema启用 JSON 模式代码层做容错修复同一问题回答不稳定模型采样参数过高把 temperature 调低到 0.2 以下增大确定性多轮对话答非所问上下文记忆处理不当检查历史消息拼接加入对话态理解模块成本超预算Prompt 中无效内容过多精简固定指令应用 prompt 缓存控制检索片段长度这个表不是一次列完就完事我建议团队每周开一次效果复盘会把这一周线上遇到的新问题补进去持续维护。落地的过程本质就是“找问题—修问题—检效果—”的循环表越厚系统越稳。5.2 一个真实排查案例知识库问答答案引用错位之前做过一个内部知识库问答系统上线两周后收到反馈回答内容是对的但引用来源文档标题显示得不对。排查的时候我先查了数据链路发现切片时把文档章节标题作为元信息存了但标题文本和正文字段在向量化后的字段映射设置错了导致模型拿到的元信息是上一章的内容。这个问题的根子在于数据处理时字段没有对齐。解决办法是在切片入库时专门跑一个校验脚本检查每条记录的标题、正文、页码是否一致不一致就报错。这类问题如果不在数据侧拦截靠模型侧怎么调 Prompt 都解决不了。很多 LLM 项目跑得不好不是模型不行是进模型的数据链路脏了脏数据进脏答案出。另一个案例是用户反馈系统“回答太官方”。查日志发现问题在系统提示词要求“风格正式”导致模型所有回答都端起来了。后来把提示词里加了一句“用口语化、朋友式的口吻回答”体验立刻改善了。提示词调优这种小事效果往往比换一个大模型更明显。5.3 日志、追踪与可观测性是救命稻草LLM 系统的调试比传统系统更依赖日志因为模型的输出不确定问题复现难度极高。没有日志用户报一个问题你连模型当时看到了什么、回答了什么都查不到只能靠猜。日志追踪系统上线前就必须有不要等出了问题再补。记录内容主要有五类完整的输入 Prompt、模型原始输出、检索返回的文本段和排序分数、token 消耗和成本统计、模型参数配置。这些信息记录成结构化 JSON存到可查询的后端存储里支持按用户、问题、时间维度检索。我在实际项目里靠这套日志定位过无数问题哪些是用户问题歧义哪些是检索失效哪些是模型幻觉一查便知。还有一个建议是给线上系统加“用户反馈”入口每个回答下面放“有帮助 / 没帮助”按钮让用户帮我们标注效果。反馈数据积累到一定量拉出来就是一份免费的高质量评测集。这个习惯帮我们做了很多原来要人工标注才能完成的评测工作。最后的小心得说了这么多方法其实 LLM 落地的本质拼的是工程基本功数据处理是否干净、评测指标是否明确、日志链路是否完整。模型本身的能力差距远没有工程细节积累差距来得大。我自己做过好几个大模型项目最深的体会是项目从一开始就建立评测集、记录日志、明确谁能改 Prompt上线后就越稳迭代也越顺。别被“大模型什么都能干”这句话迷惑真正管用的还是那些笨办法多测、多看日志、多和用户聊问题。你在这个过程里攒下的经验才是项目能不能持续跑下去的真正护城河。