我先说个真实感受现在聊“LLM使用方法”已经不太适合继续停留在“怎么注册账号、怎么点对话框”这个层面了。从 2024 年下半年到现在大语言模型早就从聊天玩具变成了生产工具团队里真正拉开差距的不是谁手里模型更贵而是谁更清楚模型的工作机制、谁更会传参、谁更懂怎么把它嵌进业务流程。这篇就从一个常年调模型、部署模型、给模型“擦屁股”的从业者视角把 LLM 的使用方法掰开揉碎讲一遍。你不用有算法背景能看懂代码、肯动手试就能跟上。严格说起来LLM 本身就是一个深度学习模型没什么可争议的但我更愿意把它理解成一台“概率打字机加知识压缩器”。你输入一段文字它按 token 一个个往后预测生成你想要的下一段。问题在于这台机器的脾气、边界、成本、坑都比传统软件多得多。这篇文章我尽量不讲空话把你一定会遇到的东西都过一遍Token 怎么算、上下文怎么管理、提示词怎么写、RAG 怎么搭、GraphRAG 和本体是怎么回事、本地部署和 ONNX 什么时候用、LLM 网关解决什么问题、单元测试怎么给模型写、还有那个让我熬夜排查的报错 provider rejected the request schema or tool payload 到底是什么情况。1. 理解LLM的核心从Token到注意力1.1 TokenLLM的“文字零件”也是计费单位Token 是 LLM 处理文本的最小单位它既不是字母也不是完整单词更不是“汉字”这种你熟悉的字词边界。一个 token 大约是 0.75 个英文单词、0.5 到 1 个汉字具体取决于模型的分词器Tokenizer。你可能会好奇为什么我要花精力理解 token因为每个模型的上下文窗口有上限比如 8K、32K、128K这个上限按 token 计不是按字数计。更重要的是云服务商按 token 收费输入输出都算钱你不理解 token就根本没法控制成本。我建议你实际去查一次 token 数别靠感觉估。大多数模型厂商的 API 文档里都提供 Tokenizer 工具你把一段中文原文粘进去它会告诉你要拆成多少个 token。比如“我需要生成一份债务风险预警报告”这句话你可能觉得 15 个字不多但拆成 token 后往往是 20 到 30 个因为中文的分词粒度和英文完全不同。这不只是计费问题还会影响你的上下文长度设置。我在实际项目里踩过最痛的坑就是把系统提示词写太长业务还没开始2000 个 token 已经没了导致后面的对话内容被硬生生截断。1.2 Q/K/V为什么说“Key是我是谁、Query是我想找什么、Value是我能给什么”你打开 LLM 的开源实现或者看 Transformer 架构文章时一定会碰到 Q、K、V 这三个字母。很多人把注意力机制背下来就过了但我更建议你用业务场景去理解它。在一个注意力计算过程中每个 token 都生成三个向量Query查询、Key键、Value值。翻译成人话就是当前这个 token 想知道“谁跟我有关系”这是 Query别的 token 会拿出自己的 Key 说“我在这我是这样的事物”一旦匹配上真正被取出来用的内容其实是 Value也就是那个 token 携带的实际信息。热搜里有一条总结特别精辟Key 是“我是谁”Query 是“我在找什么”Value 是“我能提供什么”。我在做知识库问答时这套理解非常有用。比如你问“医院上个月的应付账款逾期率是多少”你的 Query 会去匹配知识库中相关文本的 Key匹配到“应付账款”、“逾期率”这些概念后实际参与生成回答的是那些片段里的 Value——具体数字、时间范围、计算口径。如果你后续要做 RAG 的检索优化你本质上就是在调整 Key 的表示方式让用户的 Query 更容易匹配到正确内容同时确保 Value 里有足够的信息支撑回答。1.3 上下文窗口与“记忆错觉”上下文窗口是 LLM 的短期记忆容量它决定了模型一次能“看到”多少内容。很多人误以为模型能记住之前的对话其实它只是把历史消息全部塞进输入里每次都重新计算一遍。一旦超过窗口上限服务端要么报错要么做截断模型就会“失忆”。这个机制带出一个非常实际的问题你的业务对话越往后真正的上下文空间越小。所以使用 LLM 的第一原则是不要把对话历史当数据库也不要把上下文窗口当长期存储。该压缩的压缩该向量化的向量化该落库的落库。我见过一个典型的失败案例某团队做客服机器人的时候把所有历史聊天记录都往上下文里塞结果系统跑到第 10 轮就崩了不是网络问题是 token 超限。后来改成只保留最近 6 轮对话摘要加业务关键信息反而效果更稳。记住一个判断标准上下文窗口里只放“和当前任务最相关的东西”无关的坚决不放。2. 调用LLM的正确姿势2.1 API调用URL、模型与鉴权三件套不管用哪家模型你第一件要做的事就是搞清楚 API 的基本组成请求地址Endpoint、模型名称Model、身份凭证API Key。以 OpenAI 兼容格式为例一个典型的对话补全请求长这样。from openai import OpenAI client OpenAI( api_key你的密钥, base_urlhttps://api.example.com/v1 ) resp client.chat.completions.create( modelqwen-plus, messages[ {role: system, content: 你是财务分析助手回答要简洁。}, {role: user, content: 2025年Q1应付账款周转天数是多少} ], temperature0.3 ) print(resp.choices[0].message.content)这里有一个很常见的误区你以为一切都要用云端闭源 API其实现在很多场景用兼容接口是为了留后路。我在项目里一贯的做法是第一版先用一个统一格式封装调用层底层接哪家模型可以随时切换。这样模型升级、换供应商都不用改业务代码。除此之外请求参数里有一个 stream 开关我建议所有交互式场景都打开它能让首字返回更快用户感知上“模型在打字了”体验差距非常大。2.2 关键参数temperature与top_p参数是很多人忽略但实际影响非常大的部分。temperature 控制随机性取值通常 0 到 2数值越低输出越确定top_p 控制候选集合的累计概率0.1 更保守0.9 更发散。经验值做抽取、分类、格式化输出temperature 设为 0 或者 0.1做头脑风暴、创意文案可以放到 0.7 到 0.9。这两个参数一般只用调一个别同时猛调否则输出质量会变得非常奇怪。还有一个总被忽略的参数max_tokens。它限制这次输出最多生成多少 token很多人不设置结果模型长篇大论成本爆炸。我建议所有生产环境请求都显式设置 max_tokens。你哪怕只是设置一个比任务需要多 20% 的上限也比放任不管强得多。另一个我常用的参数是 response_format部分模型支持让输出固定为 JSON极大减少你解析文本的麻烦。如果你的供应商不支持这个参数那就在提示词里强制要求 JSON 格式并做好异常兜底。2.3 System Prompt与角色固化System Prompt 是给模型设定的“总纲”它在每轮对话前都跟着发过去模型会把它当成最高指令。很多人写 system prompt 写得太随意比如“你是一个助手”这基本等于没写。好的 system prompt 应该包含四个要素角色、任务边界、输出风格、禁忌事项。我拿真实项目举个例子。我帮一家医院信息科做债务风险分析助手时system prompt 是这样写的角色是“医院财务风控分析专家”任务范围是“仅回答与资产负债、预算执行、逾期账款相关的问题”输出要求是“给出结论、依据指标、风险等级如果信息不足明确说不确定”禁忌事项是“不要编造财务数据不要给出绝对化投资建议”。这一套写下来模型输出的可控性提升了非常多尤其在“不确定就说不确定”这一条上直接减少了幻觉带来的误导。我强烈建议你把 system prompt 当代码管理每个版本都存 git、写 changelog。2.4 成本与并发token要精打细算调用 LLM 的成本三要素分别是输入 token 数、输出 token 数和并发请求数。你可能会想模型 API 按 token 计费我少说几句不就省了其实核心成本往往藏在你的上下文设计里而不是输出里。同样的用户问题你把相关背景文档全塞进去一次可能 8000 token你用检索只抽 800 token 精要段落成本立刻下降一个量级。并发是另一个容易被忽视的点。你以为模型服务是单请求独立算力的实际上你的企业账号有速率限制RPM、TPM。一旦超限服务端会返回 429 限流错误。我的经验是所有正式项目必须做请求排队和指数退避重试。你可以在接入层用一个简单的信号量控制并发数如果连续失败三次就放弃本次调用并把任务标记为异常等待人工处理。别把重试逻辑写成无限重试遇到模型服务持续故障时无限重试只会造成雪崩。3. Prompt工程让模型按你的思路走3.1 提示词的结构化写法Prompt 写得好不好直接决定 LLM 输出质量。我见过很多人把提示词写成长篇大论的散文模型确实能理解但结果经常跑偏。更稳的做法是结构化指令明确、示例充分、边界清晰。我常用的模板分四块任务描述、输入数据、输出要求、示例。举例来说你要模型做合同关键信息抽取。任务描述是“从合同中抽取乙方、金额、付款条件”输入数据放原文输出要求是“返回 JSON只包含 contract_party、amount、payment_terms 三个字段”示例则给一个简短的输入输出对照。你会发现这样写出的 prompt 即使模型不是最强版本也能稳定输出你要的结构。核心原因在于模型非常擅长模式匹配你给了明确模式和框架它就不容易自己开脑洞。3.2 少样本示例与思维链每个做 LLM 应用的人都应该学会少样本提示Few-shot和思维链Chain-of-Thought它们是提升精度的两把钥匙。少样本很简单在 prompt 里预先给出 2 到 3 个输入和正确输出的配对。模型看了示例后会模仿示例的格式与推理思路。思维链则是在复杂推理场景明确要求模型“先列出你的推理步骤再给出结论”。我在做医院债务风险预警时经常需要模型综合多个财务指标判断风险等级。如果直接问“这个医院属于高风险还是低风险”模型经常答错。改成结构化 prompt先要求模型依次分析资产负债率、流动比率、逾期账款占比分别给出单项评级最后综合判断。这一步其实不玄学它就是强制模型把隐藏的推理过程摊开让每一步都受到约束。测试下来准确率能从 70% 提到 85% 以上。3.3 输出约束与返回格式生产环境使用 LLM最怕的不是回答错而是回答“没法用”。你需要模型输出标准 JSON它非要给你一段带解释的文字你需要它只输出代码它非要在代码块前后加说明。解决这个问题要靠三招第一在 prompt 里明确“只允许输出 JSON不要输出其他文字”第二如果模型支持使用 response_format 或 JSON Mode第三解析时做好容错用正则提取最外层的 JSON 片段再用 json.loads 解析解析失败就重试。我特别建议你写一个通用的 LLM 调用封装把所有结构化输出请求都走同一个函数发送请求拿到内容尝试解析结构化结果如果失败把错误信息附带在下一轮对话中让模型重新生成。这条路能让你的应用稳定很多因为模型的输出不可能 100% 符合预期你要在工程上做“宽带”而不是指望模型“完美”。4. 用框架还是不用框架LangChain与直接调用的博弈4.1 框架解决什么问题LangChain 这类 LLM 框架一出现就火了很多人无脑引入结果项目变得比业务代码还复杂。我的观点很直接框架本身没有罪但它解决的问题是编排不是魔法。如果你只做简单的问答、抽取、总结直接封装 API 就够如果你要做多工具调用、多步骤 Agent、复杂 RAG那框架的抽象能力可以帮你省下很多工作量。框架最大的价值是提供了几个标准化的抽象LLM 调用类、消息模型、检索器、工具调用、记忆机制。你不需要重复造轮子。但它的代价是学习成本和隐藏的版本兼容问题。我见过太多团队被 LangChain 的版本更新搞崩同一个接口改得面目全非。如果你决定用把版本锁死并且把自定义代码和框架代码解耦别让框架侵入业务层。4.2 RAG让模型学会“翻书”再回答RAG检索增强生成是目前把 LLM 用在知识库问答最主流的方法道理很简单模型训练数据有截止日期你单位内部资料它根本没见过与其让它瞎猜不如先检索出相关资料再拼接进 prompt让它“带着答案翻书回答”。整个流程分成四个环节文档切片、向量化、相似度检索、生成回答。切片是最容易被低估的环节。切片过大检索精度下降切片过小上下文碎片化。我的经验是不同文档类型要不同切片策略合同按条款段切、制度按章节切、表格按行和上下文组合切。切片还要保证一定的重叠比如每段保留前一段末尾的 50 到 100 个字符防止语义被切断。检索阶段你可能会用到向量相似度也可能用关键词更稳的做法是混合检索向量召回加关键词召回再用重排序模型把最相关的结果顶到前面。4.3 GraphRAG与本体从碎片知识到网状知识这个新方向值得你关注。普通 RAG 的短板是“只见片段不见关系”它检索到的是一个个文本块但这些块之间的关联模型并没有系统地利用。GraphRAG 做的事情就是在构建知识索引阶段先把实体抽取出来再把它们之间的关系建立成图检索时不仅找文本片段还顺着图中的关系路径补充上下文。它特别适合处理多实体、多关联的问答场景。热搜里提到的“LLM Wiki”“本体Ontology”也属于同一脉络。你可以把本体理解成领域专家手工定义的“概念地图”比如医院财务领域里有“收入、支出、应收账款、预算、资产负债率”这些概念以及它们之间的关系。有了本体LLM 在抽取和检索时就不至于跑偏。综合下来我的建议是小型知识库用普通 RAG 就够大型、关系复杂的知识库再上 GraphRAG但别把系统第一步就做得太复杂否则运维成本会反噬你。4.4 Agent与工具调用让模型“动手做事”Agent 是当前 LLM 应用最性感的词核心是模型不再只是“生成文字”而是能按你的业务流程调用外部工具、读取数据库、执行代码。以 OpenAI 兼容的 function calling 为例你可以定义一组 JSON Schema 描述工具模型会先判断该用哪个工具返回结构化调用参数你的业务系统再执行并回传结果循环直到问题解决。做 Agent 最大的坑是死循环和误调用。明明用户只是闲聊模型却调用了一个高成本的查询工具工具返回异常模型又不断重试。我的解决方法是每个工具都必须有清晰的描述和“适用边界”并且设置最大调用轮数比如最多 5 轮超出就直接返回人工接管。设计 Agent 时要有“不做事”的权力模型必须能判断“当前问题不在工具范围内”然后老实说不知道而不是强行调用某个最像的工具。5. 把LLM放进生产部署、评估与兜底5.1 本地部署与ONNX什么时候不用云端API要不要本地部署不能只看流行度要看需求数据敏感要求高所有文本不能出内网必须本地极端追求低延迟和稳定性本地 GPU 是可靠选择成本上如果需求量级巨大本地跑开源模型可能比 API 更划算。反过来说业务量不大团队没有 GPU 运维经验我劝你别折腾本地部署直接买 API 更省心。本地部署的一个实用选型是 ONNX Runtime。ONNX 是一个开放的模型交换格式你可以把 PyTorch 或 Transformers 训练的模型导出成 ONNX再跑在 CPU 或 GPU 上。它的好处是推理速度快、部署简单、没有太重的框架依赖。比如用 Faster Whisper、MiniLM 这类模型做语音转写和文本向量化ONNX 格式非常稳。但大模型例如 7B、13B 级别本地部署更常见的选择是 llama.cpp 或者 vLLM前者普通 CPU 也能跑后者走高性能服务。我的建议是小模型用 ONNX大模型先看 vLLM别盲目套同一个技术栈。5.2 模型选型Open LLM Leaderboard该看哪几列面对一堆模型怎么选公开榜单是一个有用的入口但你不能只盯着综合排名。Open LLM Leaderboard 这类榜单上有多个维度通用推理、知识问答、数学逻辑、代码、指令跟随等。你要先看自己的任务偏向哪个能力。财务预警任务更需要可靠的抽取与分类能力数学推理未必是关键代码助手则需要代码能力权重更高。我选模型时的动作很固定先在榜单筛出两三个候选再拿自己的 50 条真实样本跑一个“对比测试集”分别看输出正确率、格式稳定性、延迟、成本。榜单分数是参考你自己的数据才是裁判。另外要留意模型许可证和商用合规开源不等于随意商用许可证限制要先看清楚。你不想项目上线一个月后突然发现模型 license 不允许商用。5.3 LLM as Judge自动评估的坑与解法人工评估每个输出太费人力于是有人提出“用模型做裁判”也就是 LLM as Judge。拿一个更强的模型给定题目、标准答案和待评答案让它打分或判定好坏。这个方法在研发阶段有高效率但它有一个大坑裁判模型会对更长的答案、更华丽但空洞的措辞产生偏好也会受到自身立场影响评出的分数不一定可靠。我的经验是尽量把评估标准写成“结构化指标”而不是模糊的好感。比如问裁判模型答案是否包含预算执行率、资产负债率、逾期账款三个关键字段是否给出了明确的风险等级是否存在与引用数据不符的内容每个问题单独打分最后再汇总。这样裁判模型的随意性会大幅降低。复杂场景别只用一个裁判模型可以用两个不同的模型各自打分有分歧再人工介入。5.4 给LLM写单元测试从“用例”到“断言”LLM 和传统函数不一样它没有确定性输出但单元测试仍然可以做。把每个 prompt 模板、每个 Agent 的某个分支、每次工具调用的参数选择当成“待测单元”用一组固定的测试用例设定可接受的断言规则跑回归测试。这不是断言模型的原始输出等于某个字符串而是断言它符合模式、包含关键实体、不触犯禁忌条款。我举一个实际例子测试“风险等级分类”功能输入一个财务描述断言输出 JSON 中 risk_level 字段必须属于 low/mid/high 之一如果描述里有“逾期超过 3 个月”断言 risk_level 至少是 mid。这种测试不是为了证明模型永远正确而是防止你改了一版 prompt 之后原来能通过的用例突然回归失败。建议把你积累的 prompt 和用例存成一个测试目录每次变更都跑一遍这样能把“模型玄学”拉回工程轨道。6. 常见错误与排查实录6.1 provider rejected the request schema or tool payload这个报错是我在接入某个模型 provider 时反复遇到的翻译成人话就是你传给模型工具调用的结构不符合它的接口规范。最常见的三个触发点其一你定义的 tools 参数里某个字段类型不对比如把必填项写成了非必填其二你传人的 arguments 是一个被 JSON 序列化两次的字符串导致 provider 无法解析其三模型返回的工具参数里带了多余的字段provider 在校验时直接拒绝。我的排查流程很固定先把 tools 简化成只有一个最朴素的工具确认请求能通再逐步加字段定位是哪个 schema 出问题。其次打印原始 payload 出来看别盯着框架抽象层瞎猜框架帮你隐藏了很多细节但报错时这些细节才是关键。最后检查一下版本模型 provider 更新过 API 规范的大版本旧的工具格式可能不再被接受。这个报错八成是你自己的 payload 没写对少部分是对面接口版本变了别一开始就怪厂商。6.2 网关与LLM网关解决什么问题企业里多个系统都要调用 LLM如果每个系统各自申请 API key、各自控制流量管理上肯定乱。LLM 网关就是一个统一入口用来做鉴权、限流、负载均衡、日志和成本核算。你可以把它理解成 LLM 的“总闸门”所有内部系统的模型请求都从这里过而不是直接打到厂商 API。我建议技术负责人认真考虑引入一层轻量网关哪怕只是用 Nginx 或 Go 写一个简单的转发代理。网关层能做的关键事包括统一配置多套模型供应商按业务线做配额限制记录每次调用的用户、模型、token 数并对重复故障做熔断。等系统规模大了以后你可以在网关层实现更复杂的策略比如低优先级任务走便宜模型高优先级任务走强模型。这个抽象可以帮你以后换模型供应商时不被业务代码绑架。6.3 上下文超限与Token截断上下文超限是所有 LLM 生产应用都会撞上的墙。模型报错“maximum context length exceeded”几乎都是因为你在请求里放了太长的历史或文档。处理办法是多层级的第一限制单次输入长度超出部分让用户简化问题第二做历史摘要把旧对话压缩成几句话代替原文第三做分段回答长文档拆成多轮问答而不是一次让模型读完。我特别提醒两个隐蔽情况一个是 system prompt 太长很多团队写了几百行说明长期占用窗口另一个是检索结果太多RAG 一次召回 10 段内容每段 500 字那就直接塞满 5000 token。设计检索策略时要控制召回数量而不是“检索越全越好”。实时看每个请求实际使用的 token 数把日志反馈做成曲线你很快就能发现哪些场景在悄悄吃掉上下文。6.4 模型幻觉可以治但不可能根治幻觉是 LLM 绕不开的话题。模型不是数据库查询它是根据概率生成文本遇到知识空白它会编出看起来合理的答案。生产系统能做的是限制它的发挥空间强制它只依据提供的上下文回答不允许补充外部知识对关键数字要求给出引用来源对高风险决策人工复核。我合作过一个医疗债务风险系统的案例第一次上线模型自信地说出“2024 年财政拨款增长 15%”但系统资料里根本没有这条数据后来我们加了一条 system prompt 硬性约束“所有结论必须引用给定文本内容未提及的信息回答‘未提供’。”效果立竿见影。但你也要认清现实约束只能降低概率不能消除。所以在流程设计上凡是涉及钱、合同、医疗建议的 LLM 输出都必须安排人工确认节点这是底线。7. 一个实际业务场景医院债务风险智能预警的技术拆解7.1 业务难点与技术选型这个场景来自我们做过的医院财务预警项目目标是把海量财务数据、合同文本、审计报告、内部制度汇总起来自动判断债务风险并提供化解建议。难点有三个数据格式极杂有 PDF、扫描件、Excel、业务系统接口风险判断需要跨多个指标综合推理院长和财务科要的不是“一段文字”而是“风险等级依据建议”。技术选型上我们没有一开始就上大而全的框架而是做了一个分层方案文档解析层负责把非结构化文本变成结构化字段模型做抽取和分类检索层用 RAG 索引制度、合同和审计报告分析层用一个 Agent 流程分步骤评估预算执行、资产负债、逾期账款最后汇总风险评分。上线后财务科只需要上传文档和报表路径系统自动生成一张“风险预警卡”。7.2 数据清洗与本体构建这一环节很多人不重视直接决定后面模型效果的好坏。原始数据里的扫描件是图片要先做 OCRPDF 里经常有页眉页脚、重复水印要清洗掉Excel 里的日期格式五花八门要统一成标准格式。数据质量不行再强的模型也白搭。在领域本体上我们手工定义了一套医院财务风险相关概念资产类有应收账款、固定资产、货币资金负债类有短期借款、长期借款、应付账款指标类有资产负债率、流动比率、速动比率。除了概念还定义了关系比如“应收账款属于资产”“借款可能导致偿债压力”。构建本体后LLM 做信息抽取时就能把“应付款”正确归类到应付账款而不是误会成“应付工资”。7.3 多Agent分工与人工复核闭环我们没有用一个 giant prompt 一次完成所有任务而是拆成多个小 Agent每个 Agent 负责一个步骤报告解析 Agent 抽取关键数字指标计算 Agent 算资产负债率、流动比率、逾期率风险评级 Agent 根据规则和模型输出综合定级建议生成 Agent 再基于评级结果形成化解建议。每步之间传递结构化 JSON而不是让一个模型从头到尾自由发挥。人工复核闭环是这个系统安全性的保障。系统生成的每张“风险预警卡”都附带“依据段落”财务科负责人要确认确认后数据才进正式报表。同时人工修正信息会回流到知识库与 prompt 示例库形成持续改进。这个设计想通得很早LLM 只是线索提供者决策必须是人的。7.4 效果评估与演进路线上线两个月后我们做了三轮评估准确率指标用了 200 条测试数据计算风险等级判断的准确率从初版 78% 提升到 90%效率指标是原来财务科做一次月度分析要 2 天现在 1 小时内拿到初稿格式合规率则看生成的预警卡在字段完整性、引用可溯源性上的达标率稳定在 95% 以上。演进路线我们留了三个口子第一知识库里的本体可以扩展更多财务指标第二建议生成模块后面可以接更细的政策规则库但仍然保持“建议仅供参考”的定位不越权第三模型底座保持可替换等更强的开源模型发布后跑一遍回归测试集再切换。这个场景给我最大的启发是LLM 项目能不能成功模型能力只占一半另一半全看使用方法和工程兜底。最后分享一点我个人这些年反复调模型的经验别把 LLM 当作一个聪明得什么都懂的助手把它当作一个“学习能力很强但很容易走偏的新员工”。你给它清晰的角色、明确的边界、完整的流程并保留人工复核的余地它的价值会超出你预期。每当你被模型输出气得头疼时先别急着换模型回去检查你的 prompt、你的数据切片、你的工具调用设计大多数问题都出在这些地方。