这两年经常有人问我“LLM到底怎么用”我一开始以为大家问的是API怎么调后来发现真正的问题是分散在“LLM是什么”“选哪个模型”“Token怎么算”“怎么搭知识库”“报错怎么排查”这些零散环节里的。乍一看全是“使用方法”但不同基础的人缺的入口完全不一样。这篇文章就按我这些年踩坑后整理出来的主线把LLM的使用方法从头到尾捋一遍先解决概念和Token的理解再给对话、API、框架、私有化部署四种使用姿势接着聊RAG与本体知识库然后是评测和行业落地最后放一份高频报错排查清单。适合刚接触大模型的开发者、产品经理以及所有想把LLM真正塞进业务场景里的人。1. 先搞清楚LLM到底是什么以及它凭什么能用1.1 用一句话拆穿LLM的本质LLM是Large Language Model的缩写翻译过来就是大语言模型。它本质上是一个用海量文本训练出来的深度学习模型底层核心是Transformer架构里的自注意力机制。训练时模型做的事情只有一件根据前面已经出现的文本预测下一个Token是什么。等你用得多了它自然学会了“顺着上下文接话”的能力也就有了对话、翻译、总结、写代码这些看起来像“智能”的表现。所以你问“LLM是不是属于深度学习”答案是确定的是——它不只是属于它就是这个领域最典型的产物。现在衍生出的所谓Spatial LLM、多模态LLM看起来是处理空间坐标、图像、视频、语音底层仍然是深度学习那一套把非文本信息编码成Token或者向量再交给Transformer继续做预测。生活化点的类比LLM像个被几十万本书“喂”出来的读书人。它记住的不是具体页码而是大量语言组合的统计规律。正因为它没有真正“翻开”某一本书所以它一定会出现一本正经编答案的情况这也就是“幻觉”。理解这一点比记住任何框架API都重要。1.2 它的边界在哪能做什么、不能做什么不少初学者会把LLM当成万能工具一旦遇到输出不对就开始怀疑是不是上下文写错了。其实更多的场景是我们在让它做它做不了的事。能做的事放在现实里是这么用的写文案、改写润色、抽结构化的信息、生成代码、做会议纪要、把非结构化文档变成表格、翻译成多语言、辅助解释复杂概念。你甚至可以把硬件调试里的概念扔给它比如示波器的使用方法、xrandr的显示配置参数、mpu6050陀螺仪的寄存器说明它都能给你讲出一套标准操作流程。我试过让LLM解释vlookup这类办公函数的嵌套用法它的思路比很多教程还要清晰。不能做的事也很明确第一它不知道训练截止日期之后发生的事情也不要指望它实时联网就能一直正确第二它对精确计算非常不稳定电话号码、金额明细、日期推算这类场景必须做校验第三它理解和生成的是“统计上的合理”不是“事实上的正确”。所以真正靠谱的LLM使用方法永远只有四个字——扬长避短让模型做语言理解和生成把精确计算和最终决策交给规则、代码和人工。1.3 选模型前必须知道的开源与API之分聊具体使用前先解决一个绕不开的问题模型从哪来。市面上主流的LLM分两条路线。一条是闭源API模型部署在厂商的服务端你通过HTTP或者SDK调用。像日常听说较多的DeepSeek、Qwen、GLM系列都有对外开放的API这种方式的优点是你不用管GPU、不用做性能调优花点Token钱就能拿到当前较强模型的能力。另一条是开源权重比如一些可商用开源的模型你可以把权重下载下来部署在自己的服务器或电脑上。好处是数据不出内网、适合私有化业务、长线成本可控坏处是硬件门槛高、部署维护要花不少心思。很多团队刚开始做验证时都用API跑通了再评估要不要私有化。在实际选型时千万不要只看模型名气。Open LLM Leaderboard这类公开榜单在特定评测集上的分数只能代表它在某些任务上的相对表现。我自己踩过的坑是一个在榜单上排名很高的通用模型在做我业务里的结构化抽取时效果反而不如一个更小但针对性微调过的模型。正确的姿势是拿自己真实的业务数据做小样本对比测试而不是被公开分数牵着走。2. Token是LLM的计价单位和理解单位必须吃透2.1 Token到底是字还是词看个实际例子如果只在LLM里挑一个概念必须弄明白那一定是Token。Token是模型处理文本的最小单元它既不是严格意义上的“字”也不是“词”而是模型分词器切出来的片段。我拿一句话举例“今天天气不错适合测试”。经过常见中文分词后可能是今天、天气、不错、适合、测试。这就是5个左右的Token。英文的情况更明显比如“unbelievable”可能被切成“un”“believ”“able”三个Token也可能被当成一个Token取决于词表里有没有收录这个完整单词。所以一般不用自己数Token而是交给分词器工具统计。Token为什么重要因为在你使用LLM的时候Token就是计费单位、上下文长度单位、性能瓶颈单位。一个并发请求里输入Token越多首字响应越慢这是物理规律。我自己平时大概按“中文1个汉字约等于1-2个Token英文1个Token约等于4个字符”来粗算设计Prompt和文档切片的时候心里就有底。2.2 Key、Query、Value把Token拆成三个角色很多人在网上看过一句话说“LLM的Token理解可以拆成三个点Key是我是谁Query是我在找什么Value是我能提供什么”。这句话不是玄学它对应的是注意力机制里的三个向量。用开会的场景解释会议室里每个人先做自我介绍自我介绍的内容就是Key发言的人抛出一个问题是否和某个自我介绍匹配这个匹配过程用的是Query匹配上之后匹配的那个人补充的详细背景资料就是Value。模型在处理一串文本时会对每个Token都计算一套Key、Query、Value再通过注意力权重把真正相关的信息聚合起来决定下一个Token是什么。这就是为什么模型能根据上下文“抓住重点”。这个理解还能反过来指导提示词怎么写。你在写Prompt时也可以把自己当成一个Token来处理明确“我是谁”角色设定说清楚“我在找什么”任务目标提供“我能给什么材料”背景信息。把这三件事交代完整通常效果比简单扔一句话要好得多。我见过有人只写一句“帮我写个方案”模型能发挥的空间有限但如果补上“你是一个有十年经验的售前工程师我在找一份智慧园区建设方案我有以下需求背景……”输出质量会明显提一截。2.3 上下文窗口和Token预算决定了你的输入该写多长每个模型都有一个最大上下文窗口常见的有32K、128K、200K等。这里最关键的是上下文窗口是输入和输出加起来的总预算不是你输入可以写满整个窗口。比如窗口是128K你输入塞了120K模型理论上只剩8K能给输出遇到长文本生成很容易中途截断。实际使用中我一般这么做先统计输入Prompt有多少Token再给输出预留足够空间。如果发现历史对话太长优先做三件事——只保留系统提示和最近几轮消息把早前对话压缩成一段摘要把不相关的背景材料从上下文里摘掉。Token预算不足出现“上下文长度超限”报错时很多人第一反应是崩溃其实大多数情况下问题不在模型而是对话管理做得太粗糙。LLM的使用方法里维护上下文是比写提示词更难也更容易被忽视的技能。3. 三种最常用的LLM使用姿势对话、API、框架3.1 最轻量把提示词当成一种“使用方法”如果只是偶尔用一次最轻量的方式就是打开任意一个模型对话窗口靠写提示词来拿到想要的结果。很多人觉得提示词没有技术含量恰恰错了——提示词是当前投入产出比最高的一种LLM用法。一个比较通用的提示词模板是这样角色 任务 上下文 要求 示例举个例子你是一名数据分析师角色。请把下面这段销售数据梳理成“区域-销量-环比变化”的Markdown表格任务。数据如下……上下文。要求只输出表格不加任何解释环比计算保留一位小数要求。参考格式……示例。这套模板看起来简单但注意几个细节。第一“示例”比“要求”更有效模型对具体模式的模仿能力很强第二零样本不一定差但一张好的few-shot示例能显著稳定输出第三复杂推理任务可以用链式思考但不要只写“请一步一步思考”更有效的写法是“先列出已知条件再逐项推导最后给出结论”用实际的结构引导它。3.2 工程化用API调用把LLM嵌进业务系统一旦你想把模型能力集成到自己的业务系统里就该切换到API调用这条线了。目前多数模型服务商都提供OpenAI兼容格式的接口写起来非常统一。一个最基础的Python调用长这样from openai import OpenAI client OpenAI( api_key你的API Key, base_url模型服务商提供的接口地址 ) resp client.chat.completions.create( modelmodel-name, messages[ {role: system, content: 你是一个只输出JSON的助手。}, {role: user, content: 请从下面这段话中抽取日期和人名返回JSON\ 张三在2025年5月10日提交了项目报告李四在第二天做了审核。} ], temperature0.2, max_tokens512, streamFalse ) print(resp.choices[0].message.content)重点说几个参数。temperature控制随机性喜欢稳定输出就调低到0.2以下创意类任务可以调到0.7以上。max_tokens限制输出长度不要忘了它会占上下文窗口。streamTrue适合做流式打字机效果但要注意在业务系统里处理流事件的逻辑更复杂。API调用真正麻烦的不是第一个请求而是工程质量你需要在接入层做错误重试、请求超时、成本监控、敏感信息脱敏还要考虑多模型切换。现在很多团队会引入LLM网关或者统一的接入客户端本质就是把“用哪个模型、Key怎么管、调度策略是什么”集中到一个地方管理避免业务代码被某一家模型厂商绑定死。3.3 框架化用LangChain、LlamaIndex省掉重复轮子有了API接下来最容易产生的需求是让模型不仅能聊天还能调用工具、读取文档、记住上下文。一个个自己实现太繁琐所以业界有了LangChain、LlamaIndex、Semantic Kernel这些LLM框架。如果不想被某个框架绑住也可以理解它们的核心抽象再手写轻量实现。框架解决的最大问题是“串联”。比如要做一个能查数据库的问答机器人传统写法是接收用户问题-调用模型-让模型把自然语言转成SQL-执行SQL-把结果送回模型-模型生成回答。每一步之间都有解析和异常处理。如果用LangChain它会帮你把工具注册、解析、回调串起来你只需要定义好“有哪些工具”“记忆装在哪里”“模型用哪个”。像现在不少AI编程工具自身就是一套“LLM框架”后端接统一的模型接入层配置好DeepSeek、Qwen、GLM等模型的API Key后在界面里切换模型就能完成任务。业内也有CC Switch这类桌面客户端做类似的事核心思路都是“统一接入、按需切换”这比把Key硬编码散落在各个项目里要稳妥得多。使用框架时我有一条原则框架只用来减少重复代码不要让它掩盖你的调试过程。遇到问题先看原始请求和响应别先怀疑框架。很多“框架很坑”的错觉其实是对底层API行为不熟悉导致的。3.4 私有化部署本地跑开源模型的取舍与ONNX部署再往下走一层是私有化部署。什么时候必须考虑数据隐私要求高、业务连续性强、或者API成本超预算。这时候就要选一个开源权重模型部署到自己的机器上。部署的完整路径大体是选模型型号-做量化-选推理框架-起服务-压测。选型号时量力而行一个7B参数的量化模型在普通显卡上就能跑得不错14B以上就需要认真评估显存。量化就是把32位浮点权重转成8位或4位整数显存占用和速度会舒服很多代价是精度略有损失。如果要用ONNX Runtime来做模型部署常规流程是这样的先把PyTorch格式的模型导出成ONNX格式过程中要固定好输入输出张量维度再用ONNX Runtime写推理脚本加载模型、绑定输入输出最后和原模型做同一批数据的输出比对确认误差在可接受范围。ONNX的优点是运行时轻、跨平台、能针对CPU或特定硬件做优化。国内昇腾环境上的AscendCL也算一条常见路线。它类似GPU编程里的显存管理方式申请内存、执行计算、同步等待、释放内存这套流程如果没做好会频繁出现内存泄漏。我的建议是在部署阶段就写一个简单的内存监控脚本观察连续推理多轮后显存占用是否持续上升很多问题可以提前暴露。4. 让LLM长记性RAG、GraphRAG与本体知识库实战4.1 RAG的原理给模型外挂一个知识库如果说前面讲的都是“让模型张口就来”那RAG要解决的就是“让模型别乱说”。RAG的全称是检索增强生成思路非常简单在模型回答之前先从你的知识库里检索出相关片段再把这些片段作为上下文一起交给模型生成答案。我常用开卷考试来解释模型本身像一个训练有素的考生但它的记忆是模糊的RAG就是允许它带资料进考场回答时先翻资料再作答。这样既保留了模型的语言组织能力又保证了答案有出处可依幻觉率会大幅下降。RAG的完整流程是解析文档、切片、向量化、建立索引用户提问时也同样做向量化在索引里做相似度检索取回TopK相关文本拼进Prompt。里面最容易被忽略的是切片策略。按固定字符数切会导致一句话被切断语义不完整切太长又会让单次Token开销变大还可能把无关信息检索进来。我通常会结合标题、段落边界来切单个切片控制在300到500字切片间留50字左右的重叠检索效果会好很多。4.2 GraphRAG与LLM Wiki本体用图结构管理知识普通RAG有一个明显弱点它在找“和你问的字面意思相似”的片段但很难挖掘出“实体之间的联系”。比如“公司A投资了公司B而公司B是风险评估项目的供应商”你问“公司A有没有风险敞口”纯粹的字面向量检索很可能找不到答案。GraphRAG就是为了解决这类问题出现的。GraphRAG会把文档里出现的实体人名、公司名、事件、技术概念抽取出来再抽取它们之间的关系把整份知识组织成一张图。提问的时候既做文本相似度检索也会沿着图的边把相关信息捞出来。效果更准但构建成本更高需要模型做大量抽取工作。一个自然的选择是信息相对稳定、关系复杂的领域优先考虑GraphRAG简单问答场景用普通RAG就够。至于“LLM Wiki本体”这类概念连着的其实是本体Ontology。简单说本体就是一份“概念地图”告诉你这个领域里有哪几类概念、概念之间是什么关系。你可以在做RAG之前先让LLM帮你把常见实体类型、关系类型、属性敲定形成一套统一的Schema再拿这套Schema约束抽取结果。很多公开的LLM Wiki项目本质上就是在做这件事用一套公开、可编辑的知识结构让零散文档变得可以被语义检索和推理。4.3 快速搭一个内部知识库的最小流程我不会推荐一上来就上重框架先手写一个最小RAG流程跑通比直接落在LangChain里更有利于理解问题。最小流程大概是五步读取文档按标题和段落做切片调用Embedding模型把每个切片转成向量把所有向量写入向量数据库或者先用一个本地文件装起来做余弦相似度计算用户提问把问题转成向量检索TopK切片把切片作为上下文拼接调用Chat模型生成答案。这里有两个容易踩的坑。第一个是Embedding模型选择一定要和文档语言匹配中英混合场景尤其要测试第二个是检索结果排序不要只看相似度分数有些情况下用“关键词过滤向量检索”的组合更稳。跑通最小流程后你自然能判断该不该引入LlamaIndex这类工具来简化向量化和检索逻辑。5. 模型光会聊天不行还得会评测、会落地5.1 别只看榜单Open LLM Leaderboard到底在比什么模型选哪一个很多人首选看公开榜单。Open LLM Leaderboard这类公开评测榜确实有参考价值但我建议把它当成“初筛工具”而不是“最终答案”。公开榜单通常在通用知识、推理、代码、数学等维度上打分使用的评测集相对标准覆盖面广。问题在于两类一是“刷题效应”某些模型可能在评测集附近反复优化过真实场景未必有同样的表现二是任务偏置一个高分模型可能在中文业务文书抽取上不如一个名字没那么响的模型。更靠谱的做法是准备30到50条你业务里典型的输入输出对分别跑几个候选模型人工打分对比成本和延迟再做决定。5.2 LLM as Judge让模型给模型的输出打分评测这件事本身也可以由LLM来做这就是“LLM as Judge”。思路是让一个能力较强的模型当裁判根据一套打分标准去评估另一个模型的回答质量。我常用的一套评估维度是相关性是否答非所问、忠实度是否忠实于提供的上下文有没有虚构信息、答案质量结构是否清晰、信息是否完整、是否满足指令要求。裁判的Prompt大致这样写你是一个严格的答案评审员。请根据以下标准对候选回答打分每项0-10分。 标准1相关性回答与用户问题直接相关没有偏离主题。 标准2忠实度回答是否完全基于提供的资料是否存在编造内容。 标准3质量信息组织清晰、覆盖关键点、格式符合要求。 用户问题…… 参考资料…… 候选回答…… 请输出JSON格式{相关性: 8, 忠实度: 7, 质量: 9, 总评: ...}LLM当裁判也有偏差比如偏好更长的回答、偏好某些措辞风格。所以纯自动评分只能用于研发阶段的批量对比上线前还是要人工抽检。我的习惯是自动评测跑量人工抽验保底两边结合着用。5.3 让LLM写单元测试以及行业落地的小步快跑让LLM参与软件测试已经是比较成熟的方向。以单元测试为例可以让模型读取函数签名、需求描述和已有代码生成测试用例。但关键动作不是“生成”而是“审查”模型生成的测试用例经常忽略边界条件或者断言写得过于宽松。我会先让模型生成用例再要求它自查一轮“有没有覆盖空值、异常、边界条件”最后把每个用例过一遍测试框架看是不是真的能发现缺陷。行业落地的路线也类似。比如我看到过“公立医院债务风险智能预警与化解策略研究”这类课题本质上是把历史财务数据、风险规则和行业知识库组合起来用RAG做交叉检索用LLM生成风险说明和处置建议。你在任何行业做落地都能套同一个框架先梳理出专家是怎么做判断的再把判断依据整理成知识库用RAG评测小步验证最后把人工评审环节留在流程里。不要一上来就指望模型输出百分百准确先用它在“辅助起草、辅助筛查”的位置上跑起来再逐步扩大范围。6. 高频报错与排查技巧实录6.1 最让人头疼的 provider rejected the request schema or tool payload这类报错的原文经常是“llm request failed: provider rejected the request schema or tool payload.”看到“schema”和“tool payload”就知道问题大概率出在工具调用或者结构化参数写错了而不是模型能力不够。我遇到的情况大概可以归成四类。第一类是Function Calling的工具定义格式不合法。比如描述里缺了“name”或“parameters”或者parameters不是JSON Schema对象。第二类是参数类型和模型要求不一致。模型定义里说expects一个string你传了一个array就会直接拒绝。第三类是消息内容里混入了不被当前模型支持的角色字段。比如自定义了一个“developer”角色但接口允许的只有system/user/assistant/tool。第四类是部分模型根本不支持某些参数比如有的模型不支持temperature参数但你还在请求体里传了。排查顺序我建议从外到内先用一个最简单的消息体做请求确认接口本身能通再把工具定义和参数逐个替换测试最后查看模型服务商返回的完整错误响应体很多信息比报错原文更详细。别盲猜先把最小可复现请求拎出来问题范围立刻会缩小。可能原因检查点解决方式tools定义不合法是否缺少name/parametersparameters是否为合法JSON Schema用官方示例结构逐字段对照参数类型不匹配工具声明类型vs实际payload类型是否一致统一用字符串或按Schema要求做类型转换角色字段不支持消息里是否使用模型不认识的角色改为system/user/assistant/tool传入了不支持参数确认模型支持temperature/top_p等去掉不支持的参数或换成模型允许的写法6.2 Token超限与上下文溢出“context length exceeded”“maximum context length”这类报错几乎人人都遇到过。最常见的触发点是把整本手册塞进Prompt、对话轮次过多、单个文档切片太长。应对思路是“减输入、换窗口、做摘要”。先减输入把所有和当前任务无关的历史消息摘掉只保留system和最近几轮再换窗口如果业务确实需要长上下文直接换成更大窗口的模型最后做摘要写一个专门的摘要模型调用把长历史压成几百字的梗概再塞回去。不要一遇到超限就盲目扩大窗口窗口变大了Tokens成本、首字延迟都会跟着变先看看上下文有没有被无效内容占满。6.3 输出内容和格式不稳定最典型的场景是你要求模型只输出JSON结果它偶尔给你多一段开场白你要求返回Markdown表格它偶尔给你列个列表。这不是模型“学不会”而是约束信号不够强。我给几层解决办法。第一层把要求写得更具体比如“只输出一个JSON对象不要Markdown代码块标记不要解释”。第二层在提示词里放一个输出示例让模型照抄格式。第三层使用接口的结构化输出或JSON模式能力直接从协议层约束——这通常最稳。第四层在后处理阶段做解析兜底用代码从文本里截取“第一个{”到“最后一个}”的部分再做json.loads即使模型偶尔夹带文字也不至于直接报错。如果是内容层面的不稳定比如同一问题答案前后不一致就降低temperature用多次采样然后投票的方式选出最一致的答案。这一招在评测环境和生产环境的成本都不高效果却非常明显。7. 一点过来人的使用心得7.1 几条真实的“使用红线”我在实际项目里给团队立过几条红线现在看依然有效。第一条绝不把模型输出当最终结果直接展示给用户尤其是涉及金额、日期、合同、法律意见这类高风险内容。模型给出的内容永远只当草稿经过规则审核和人工确认才能生效。第二条绝不在没有日志的情况下接入生产环境。每次请求和响应的原始记录都要带上时间戳、Token数、错误码没有日志的LLM系统出问题连定位都做不到。第三条绝不把业务机密无差别发给没有私有化部署承诺的第三方。数据边界这个问题在项目启动第一天就要想清楚而不是等到合规部门提醒你。7.2 一个建议先小步验证再大规模改造最后说点个人体会。很多人拿到LLM后特别喜欢做的第一件事是把整条业务链路都改造成“大模型驱动”。我的建议完全不同先挑一个低风险、高频的小场景做验证比如客服消息的分类、文档信息抽取跑通后再慢慢加场景。LLM很强但它像是一个能力很强但需要盯着干的实习生——你把任务拆得越细、验收标准定得越清楚它给你的惊喜越多反过来你放任它自由发挥翻车的概率也越大。调提示词遇到效果不好的时候先别急着怪模型先回头检查你的Prompt里有没有把“我是谁、我要找什么、我能提供什么”这三角色交代清楚这往往比换一个大模型更管用。