这两年 LLM 大语言模型几乎成了产品和项目里的“万能补丁”好像任何功能不塞一个“智能”进去就落伍了。但真到了落地阶段很多团队会发现模型选型、提示词调优、知识库检索、Agent 工具链……每一个环节都能让上线时间翻倍。这篇文章我想把自己实际带项目时踩过的坑和验证过的做法拿出来聊聊尤其是 RAG 增强、Dify / LangChain 这类工具怎么用以及那些文档里不会写的细节。适合正在做 LLM 产品化或者准备把大模型接进现有系统的研发、产品和架构同学参考。1. 落地前先把问题定义清楚LLM 产品化整体思路1.1 LLM 到底能解决什么问题很多人一上来就问“我要接哪个大模型”其实更应该先问“这个产品里LLM 是核心还是配件”。LLM 真正的强项是语义理解、内容生成、信息抽取、总结归纳以及在给定资料基础上的推理问答。它的弱项也很明显不可完全信任、会幻觉、无法保证实时数据、成本随调用量线性增长。我习惯把落地场景先归个类智能客服 / 知识问答用户用自然语言提问系统从知识库中检索资料并生成答案。文档分析合同、报表、论文等长文本的自动摘要、信息提取、结构化输出。内容生成营销文案、代码生成、翻译、改写这类场景对准确性要求相对宽松。流程自动化 Agent让模型理解任务、拆解步骤、调用工具或 API 完成操作比如订会议室、生成工单、查询订单。数据清洗与抽取把非结构化文本转成结构化字段比如从简历里抽姓名、工作年限、技能标签。分类之后你会发现不是所有场景都需要“最强模型”。比如做文本分类、实体抽取用小模型反而更快更便宜只有需要复杂推理、多轮对话或者生成质量要求高的地方才值得上大参数模型。这一步想不清楚后面所有选型都会摇摆。1.2 从原型到产品两条路线怎么选落地路线基本就两条一条是直接调用商业大模型 API。优点是没有 GPU 和推理运维负担效果通常最好迭代快缺点是数据要发给第三方服务合规敏感的行业受限成本不可控还需要考虑供应商绑定问题。另一条是私有化部署开源模型。用 Llama、Qwen、DeepSeek 这类权重开放的模型部署在自己的 GPU 或内网环境。优点是数据安全可控推理成本在规模大了以后会更低缺点是要有人懂推理部署、显存规划、推理加速而且小参数量开源模型的能力确实和顶尖商业 API 有差距。还有一条混合路线我最近越来越推荐对外交互和复杂推理走商业 API内部检索和数据处理全放在本地敏感数据不出去。比如做一个客服助手用户问题先本地做意图识别和服务路由只有需要深层推理的时候才调用大模型 API。既控制成本又守住合规底线。选型时建议列一个决策矩阵重点看五个维度数据敏感程度、预期并发量、团队运维能力、预算范围、效果要求。没有绝对正确只有适合当下阶段的选择。2. 四个核心环节拆解模型、提示词、RAG 与 Agent2.1 模型选型决策闭源 API、开源私有化怎么选具体到模型选择先看上下文长度、参数量、推理速度和价格。上下文长度决定了你能喂给模型多少资料。早期大模型只有 4K、8K 上下文现在主流模型普遍 128K 以上但不要被参数迷惑——上下文长不等于真的能“记住”所有内容很多模型在长上下文后段会出现“迷失在中间”的问题重要信息必须放在开头或结尾。如果是调用商业 API国内现在可选百度文心、阿里通义、智谱 GLM、DeepSeek 等国外有 OpenAI、Anthropic、Google。每条线的优势不同我一般会做一个标准评测集把团队整理的代表性问题统一过一遍看效果而不是看宣传。评测集至少 20 到 50 个问题覆盖正确表达、模糊表达、边界问题、无答案情况。如果走私有化可以从 Qwen 和 DeepSeek 系列开始试。目前中文场景下7B 到 14B 的模型已经能处理不少任务Agent 或复杂推理场景最少 32B 以上最好上 70B 级别。显存估算有个经验公式1B 参数的 FP16 权重大约占 2GB 显存量化到 INT4 大约 0.6GB 到 0.8GB。比如 7B 模型 FP16 就要 14GB 显存加上激活值开销单卡 A10G / 4090 比较勉强建议直接上 24GB 以上的卡。别只看权重大小推理框架 KV Cache 占的显存往往比权重还多。框架方面Dify 和 LangChain 是现在讨论最多的。LangChain 偏开发库适合写代码、深度定制链路Dify 偏产品化平台能可视化搭应用、管理知识库、发布 API适合快速验证。两者不冲突我见过不少项目先用 Dify 做 MVP后期再抽一部分逻辑用 LangChain 写服务。2.2 提示词工程从“会聊天”到“按格式交付”提示词是成本最低但最容易被忽略的优化点。你不需要把它当成写作文而是当成接口协议设计。我常用的提示词结构是五段式角色你是什么负责什么。任务用户输入后你要完成什么。约束不能做什么比如“只能基于资料回答不要编造”。输入用户输入的内容格式。输出回答的结构、长度、格式如果是 JSON 就给示例。举个例子做知识库问答时我会在系统提示词里写你是一个企业内部知识库助手。请根据参考资料回答用户问题。如果参考资料没有相关内容直接回复“资料库中暂无相关信息”不要自行推测。回答末尾用[1][2]标注引用来源编号。这里的关键不是“礼貌”而是“确定性”。模型很难理解“尽量准确”这种模糊指令但能理解“如果没有就回答没有”。很多模型参数也直接影响提示词效果。比如 temperature 控制随机性知识问答场景建议调到 0 到 0.3内容创作可以到 0.7 到 1.0。top_p 是一种采样方式一般保持默认或和 temperature 配合使用不建议两者同时往高调。max_tokens 不是越长越好设太短会截断答案设太长会浪费延迟和成本最好按业务回答最大长度预留 20% 余量。2.3 RAG 增强落地分块、向量检索与重排的调参细节RAG 是目前把 LLM 接到私有知识库最主流的方式。原理不复杂把文档切分、向量化存入向量库用户提问时把问题向量化在库里检索最相似的若干片段把片段拼接进 Prompt让模型基于这些片段回答。但这个流程每一步都有坑。首先是分块。切太长检索粒度粗还可能包含无关信息切太短语义不完整模型看不到上下文。我的经验是通用文档用 400 到 600 token 的分块大小overlap 50 到 100 token代码或高密度结构化文档可以更小表格类内容尽量按表格结构整块切。overlap 的意义是避免关键句正好被切到两段中间宁可重复检索也不能丢信息。其次是 embedding 模型选择。中文场景下bge-m3、text-embedding-da-002、通用的 m3e 都有可用表现。如果没有特殊原因直接用 Dify 或云厂商内置的 embedding 接口最省事。但要注意检索向量和文档向量必须用同一个模型换模型必须重新全量向量化这个坑我踩过。然后是检索策略。很多向量库支持混合检索稀疏检索关键词匹配 稠密检索语义向量再做 RRF 融合。如果只用向量检索很多包含精确编号、专有名词的文档反而搜不到因为向量表示会“平滑”掉这些细节。Dify 里可以选“混合检索”建议默认开启。最后是重排Rerank。向量检索返回 Top 50用 rerank 模型精排后取 Top 3 到 5 拼进 Prompt。我一开始觉得重排是锦上添花实际上它对最终回答质量影响非常大。一个 bge-reranker 模型做重排能把命中率提升 10 到 20 个百分点。预算允许的话这个环节别省。2.4 Agent 工具调用让 LLM 学会选工具而不是乱说Agent 是 LLM 落地的另一个热点核心是 Function Calling / Tool Calling。模型输出一个结构化调用指令代码负责执行工具再把结果返回给模型继续处理。LangChain 里常见的 Tool Selector 就是干这个的让模型根据用户意图从多个工具里选一个或几个。做好工具调用有三个要点工具描述必须清清楚楚。模型是靠 description 决定调用哪个工具如果你的工具描述写“查询天气”那用户问“今天适合出门吗”模型可能不会关联到天气工具如果写成“查询指定城市实时天气返回温度、湿度、风力可支持穿衣建议判断”效果立刻不一样。参数设计要简单。工具的参数越少模型越容易正确填充。能传字符串别传嵌套对象能自动补齐就别让模型猜。比如查询订单只需要订单号就不要设计成一个包含订单号、用户ID、查询时间的 JSON。一定要加确认回流机制。工具返回结果可能是空的、异常的不能直接让模型硬编。要在提示词里要求如果工具返回无结果必须明确告知用户“查询失败”而不是编造一个结果。另外涉及修改类操作比如发邮件、改订单状态要在代码层做权限校验不能只靠模型自觉。3. 实操记录用 Dify 搭一个可复用的知识库问答助手3.1 准备工作与环境配置这里我以一个真实项目为例给企业内部做一个制度问答助手文档包括规章 PDF、Word 和少量 Markdown。我们用 Dify 社区版实现整个过程只需一台能跑 Docker 的服务器不需要自己写模型接口。Dify 提供一个可视化的工作流编排界面内置模型管理、知识库、Agent 和日志功能。部署很简单从官方仓库拿 docker compose 文件执行git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动后访问服务器 IP 的 80 端口首次进入设置管理员账号。如果你是第一次用也可以直接用 Dify 云端版省去部署环节。但内部数据敏感的话还是自己部署更安心。部署完成后先把模型供应商配置好。Dify 的“设置 - 模型供应商”里可以添加 OpenAI、通义、智谱、DeepSeek 等。我这次用 DeepSeek 做推理模型Embedding 用本地容器化部署的 bge-m3避免文档内容出内网。3.2 Dify 里的 LLM 怎么设置模型参数一次调明白在 Dify 中创建应用前先确认模型是否接入成功。进入应用编排页后你会看到系统提示词和模型参数设置。这里有几个关键选项模型选择你接入的推理模型。如果多个模型建议为知识问答、摘要抽取、分类分别选择不同模型不要一个模型打天下。Temperature知识库问答设为 0 到 0.3。这个项目里我设为 0.2让回答更保守。Top P保持 0.8 或默认。Max Tokens这里会根据回答长度调整。制度问答多数回答在一两百字内我会设 500留足余量。记忆轮次多轮对话需要开启但记忆会消耗上下文长度。我设为 6 轮避免长时间会话把上下文塞满。Dify 里不同模型供应商还会带“思维链”或“思考过程”开关。如果不需要让用户看到推理过程一定要关掉否则回答前面会多一大段“嗯这个问题我需要这样分析……”。后面第 4 节我会专门说这个问题。3.3 知识库处理与检索调参知识库是 Dify 的强项。创建“知识库”后上传文档Dify 会自动识别并分段。我更推荐手动设置分段模式分段长度设为 450 token分段重叠设为 50 token。对于规章、制度这类文本这种参数能保证每段有完整的条款上下文。Embedding 模型选择完成后点“索引”按钮Dify 会把所有分段向量化。这一步如果文档很多需要一点耐心。索引完成后进入应用的“上下文”设置关联这个知识库。检索调参有两个核心参数TopK决定取回多少个分段。我在这类问答场景中设为 4既不会漏关键内容也不会给模型太多干扰。Score 阈值相似度低于多少直接丢弃。默认 0.5 偏宽松容易带进无关内容设为 0.7 又可能漏掉有效片段。建议先用 0.5 跑一批问题观察命中情况后再逐步上调到 0.6 左右。同时打开“混合检索”大部分不敏感场景都用得上。如果你发现某个问题检索不到可以先在知识库页面直接用测试检索框查一遍看对应分段是否存在、相似度多少尽快定位是分段问题还是阈值问题。3.4 应用编排与发布Dify 应用类型推荐选“Chatflow”而非普通“Chatbot”因为 Chatflow 可以显式编排处理流程。我这里搭了一个简单工作流开始节点接收用户问题。知识检索节点关联知识库输出检索片段。LLM 节点把系统提示词、检索片段、用户问题一起交给模型生成回答。结束节点直接返回回答正文。这一步的好处是你可以单独调每一步的输入输出方便排查问题。提示词里我加了硬性要求必须基于检索结果回答没有相关资料时明确说明“暂无相关信息”不要编造条款。应用保存并发布后Dify 会生成一个 WebApp 链接可以分享给团队内部试用。也可以发布成 API方便接到企业微信或钉钉机器人。调用 API 的核心参数是query和user示例curl -X POST https://your-dify.example.com/v1/chat-messages \ -H Authorization: Bearer app-xxxxxxxx \ -H Content-Type: application/json \ -d { inputs: {}, query: 年假可以累计到下一年吗, response_mode: blocking, user: test-user-1, conversation_id: }返回中的answer字段就是最终回答。这个 API 接口兼容 OpenAI 的消息格式二次开发对接非常方便。4. 常见问题与效果调优从踩坑到排查4.1 让模型不输出思考过程三种有效方法有段时间“模型输出思考过程”是大家遇到最多的吐槽。尤其是 DeepSeek R1 混用后很多项目 API 会返回reasoning_content回答正文前多出一大段“推理过程”产品上非常难看。这里分三种情况解决第一种调用 API 时在请求参数里关闭。不同模型命名不同比如有的供应商提供thinking: false有的支持reasoning_effort: none。这是最干净的做法但需要确认所选模型和接口是否支持。第二种在框架或平台层过滤。OpenAI SDK 返回的消息对象中reasoning_content字段通常在message里代码里可以这样处理resp client.chat.completions.create( modeldeepseek-reasoner, messagesmessages, ) msg resp.choices[0].message content getattr(msg, content, None) if not content: content str(msg.reasoning_content or ).strip() print(content)这里先把reasoning_content视为额外字段只取content作为展示内容。如果调试时发现content为空你可能要把 reasoning 内容继续传给模型进行“提取摘要”。第三种Dify 平台里直接在模型供应商配置中取消“模型在输出前先输出思考过程”或类似开关如果模型本身不支持关闭Dify 的响应字段里不会展示推理内容通常需要你自定义代码节点过滤掉。我在 Dify 里实测使用 Qwen 和 DeepSeek 的推理模型时旧版会出现思考过程展示问题升级到最新版并选择正确的 chat 模型非 reasoner 版一般就解决了。如果只是提示词层面也可以加一句“直接给出最终答案不要输出思考步骤”但这个方法不稳定尤其模型在内部还是先推理再生成时。所以最靠谱的还是参数和字段过滤双管齐下。4.2 回答幻觉严重、引用错乱怎么排查知识库问答最常见的“翻车现场”是资料里明明没有这个答案模型却说有而且说得头头是道。问题大概率出在检索和提示词两个环节。先排查检索。打开 Dify 里的日志看问题实际检索到哪些片段或者用知识库测试检索直接搜索。如果根本没有相关片段那模型只能编这种情况下不是模型能力问题是文档没进库、切片不合理或者阈值太高。如果检索到了片段但回答完全没用上那问题在提示词系统提示词里没有强制要求“只能基于资料回答”。再排查引用。要避免回答里出现无中生有的“根据资料”可以在提示词中强制要求引用编号请仅使用上方参考资料回答。每个回答末尾用[序号]标注依据顺序对应参考资料的编号。禁止使用编号之外的资料。如果模型依然混用多个片段可以在工作流里增加一个“重排”步骤只给模型留下最相关片段。内容量少的时候还可以把检索结果原封不动放进回答的开发环境日志里肉眼比对片段与最终答案很快能看出是哪一步的问题。4.3 检索不到或重复检索相似度阈值的坑“检索不到”和“检索出一堆无关内容”往往同时出现。我把常见情况列一下阈值设得太高相关片段相似度低于 0.7 被丢弃。建议先用较低阈值看整体召回分布再逐步提高。TopK 太小只取前 2 条正确答案排在第 3。建议先取 5再用重排精排。文档分段不合理一个条款被切成两半导致两段都不完整。调整 chunk_size 和 overlap观察召回句子是否完整。查询表述差异大用户说“请假规则”文档里写的是“休假管理办法”。靠向量检索不一定能跨这种同义词距离可以尝试混合检索加同义词扩展或在知识库里给文档加别名标签。还有一个细节重复检索时如果设置了随机采样或者 embedding 模型不是确定性推理同一个问题可能返回不同结果。Embedding 一般是确定性的但如果向量库使用了近似最近邻检索HNSW 等结果会有微小波动。不要因为一次测试好就下结论多跑几遍。4.4 并发、成本与延迟的取舍LLM 应用上线后性能和成本问题会迅速超过效果问题。这里有几个实用技巧第一成本预先算。以某 API 为例假设一个回答平均输入 1500 tokens输出 300 tokens每一百万 token 输入 2 元、输出 8 元那么一次请求成本大约是(1500/1M)*2 (300/1M)*8 0.003 0.0024 0.0054元。每天一万次请求就是 54 元看起来不多但一个月就是 1600 多元。如果不控制上下文长度和无效调用成本很容易翻倍。第二用缓存。很多供应商支持 prompt 前缀缓存系统提示词和长文本知识库片段是重复输入的开启缓存后价格能降一半以上。Dify 和 LangChain 也都有缓存层可以在代码里缓存相同输入的响应。第三做模型路由。简单问题走小模型复杂问题走大模型。我见过一个客服项目80% 的常规问题用 7B 本地模型就能回答只有 20% 疑难问题才回源到大 API整体成本下降 60% 以上。第四异步化处理非实时场景。比如批量生成摘要、批量标签抽取不需要同步等待用任务队列异步处理能摊平高峰压力也不会被单次超时拖垮。5. 一些落地心得与避坑建议5.1 落地最大的阻力往往是“期望管理”技术在没有被业务方理解之前再好的演示都会变成“又一个玩具”。我踩过最大的坑是给老板演示了一个看似无所不能的 Agent结果对方直接要求全公司系统接入。实际上那个 demo 只覆盖了 20% 场景。现在我会在项目启动前就建一个评测集把业务方关心的真实问题列进去标注好“标准答案”或“判定规则”。每次模型或流程改动后统一跑一遍对比新旧效果。有了这个评测基线至少不会出现“我觉得变好了业务说变差了”的玄学争论。评测集不用大25 个左右的高质量问题就能发现大多数回归问题。5.2 小步快跑先做窄场景再扩展如果让我给一个最低可行的落地建议选择一个部门内部、高频、知识边界清晰、错误容忍度相对高的场景比如 IT 支持问答、人事政策问答、销售资料助手。这类场景不需要打通线上交易系统不像推荐或风控那样敏感非常适合第一个 LLM 应用。窄场景跑通后再逐步增加 Agent 能力、对接内部系统。我见过不少团队一上来就想做“全流程智能助手”最后被权限、数据质量、接口协调拖住三个月出不了版本。先窄后宽这个节奏一定要稳。5.3 把用户反馈变成绩效数据飞轮LLM 应用上线不是结束而是开始。Dify 的日志功能可以看到每轮对话的输入输出和 token 消耗但如果只看日志而不做反馈收集优化方向会很随机。我会在产品界面上加“有帮助 / 无帮助”按钮把负反馈样本自动落库每周挑 top 5 的 badcase 人工分析是检索没召回还是模型没遵守指令还是知识库本身信息过时。逐个修复后重新跑评测集。这个循环坚持几个月效果提升通常比换更大模型明显得多。毕竟大模型的参数你改不了但知识库质量和提示词完全是你可以控制的。我自己的体会是LLM 落地 70% 的工作量不在模型而在数据整理、评测机制和工程链路把这些基础打牢后面换任何模型都能很快跟得上。