大模型这波浪潮我是实打实看着它从科研玩具变成生产工具的。前两年大家还在争论LLM到底算不算深度学习的新物种今年已经有一批团队靠LLM把内部流程彻底翻新了。但我也观察到大量项目死在半路不是模型本身不行而是使用方法不对——把LLM当成一个什么都能答的云接口来调跟把发动机当砖头用没什么区别。这篇文章不聊虚的我把LLM使用中最核心的几个环节一次性拆开模型选型看什么、Token怎么省、上下文怎么管、RAG和GraphRAG怎么落地以及上线前要解决的那一堆工程问题。无论你是刚接触大模型的初级开发者还是已经在生产环境里踩过坑的工程师下面这些内容应该都能直接抄作业。1. 先搞清楚LLM是什么理解模型边界比调参更重要1.1 别再纠结LLM是否属于深度学习这个问题在技术社区被反复提及答案是明确的LLM属于深度学习。它本质上是一类基于Transformer架构的深度神经网络通过在海量语料上进行预训练学习语言的统计规律和知识分布。说它是深度学习的新物种主要是因为它的使用范式发生了根本转变——经典深度学习模型做的是输入特征输出标签而LLM做的是输入文本输出文本。这个转变带来的直接影响是你没法再用老办法去训练它。过去做分类任务要标注大量样本并微调模型现在你用LLM核心技能变成了设计交互而非标注数据。很多团队习惯了传统机器学习的那套流程上手LLM时第一反应是我是不是得先收集一万条标注数据结果还没跑通就被成本和时间劝退。实际上对于绝大多数业务场景用提示词加少量示例就能得到可用结果只有那些对领域知识要求极高的场景才需要走微调路线。我的建议是先别急着定义它属于哪个类别重点要认清它擅长什么、不擅长什么。LLM擅长的是语言理解、文本生成、知识抽取、逻辑推理这类任务但它不擅长精确计算、不擅长处理超出上下文窗口的信息也不擅长保证100%的事实准确性。你越早建立这个认知后面踩坑的概率越低。1.2 选型前先学会看Open LLM Leaderboard这类榜单很多人选模型的方式很粗暴看榜单排名哪个分高用哪个。但Open LLM Leaderboard这类公开榜单上的分数和你的业务表现之间存在着不小的差距。原因有三。第一榜单评测集和模型训练数据之间可能存在数据污染模型可能在训练阶段见过评测题分数虚高第二榜单评测项如MMLU、GSM8K、HumanEval覆盖的是通用知识、数学推理、代码生成跟你业务遇到的合同要素抽取售后工单分类并不是一回事第三同一个模型在不同提示词风格下的表现差异极大榜单用的是特定格式的评测模板你换一种问法结果可能完全不同。我建议把榜单当成海选工具而不是最终裁判。正确流程是先通过榜单初筛出3-5个候选模型再拿你自己的真实业务数据构建一个小型评测集让这3-5个模型在完全相同的问题和提示词下输出结果然后逐条对比。对比方式可以人工打分也可以直接用LLM as Judge的方式——这个我在后面专门讲。我自己操盘过的项目里就出现过榜单高排名模型在特定中文业务场景下表现还不如一个开源小模型的情况这就是只看榜单的代价。这里可以把常见评测子集和业务场景做一个粗略对应评测子集考察能力适合参考的业务场景MMLU多领域知识知识问答、专家系统GSM8K数学推理财务计算、数据分析HumanEval代码生成开发辅助、自动化脚本HellaSwag常识推理对话系统、内容审核BBH复杂推理规则引擎、决策支持记住一句话榜单解决的是有哪些选择你自己的数据集解决的才是哪个能用。1.3 Spatial LLM这类领域大模型在解决什么热词里出现了Spatial LLM很多人第一次看到会懵。其实这类扩展模型的核心思路是通用LLM在处理空间关系、地理信息、三维场景等任务时表现很差因为它的训练数据里这些结构化空间信息是缺失的。Spatial LLM尝试把坐标系统、空间关系编码、地图数据等融合进模型让模型不仅能理解文字还能理解空间。这个方向给我们的启示是不要指望一个通用模型解决所有垂直问题。如果你的业务涉及GIS、自动驾驶、机器人控制、建筑信息模型这类场景需要考虑引入领域增强方案——要么用这类领域模型要么通过工具调用把空间计算能力外挂给LLM。我在实际项目中更倾向于后者因为通用LLM负责语义理解和任务拆解专业空间引擎负责精确计算两者各司其职比硬训练一个领域大模型要便宜得多、可控得多。2. 核心使用基础Token机制与上下文管理的三个关键点2.1 Token是怎么算钱和算力的用量估算方法Token是LLM的基本计量单位简单理解就是模型处理文本时切出的最小片段。很多新手第一次看到账单会吓一跳因为根本不知道成本是怎么跑上去的。这里我给一个非常粗糙但够用的估算规则英文文本大约1个单词等于1.3到1.5个Token中文文本平均一个汉字大约1到2个Token具体取决于分词器。最稳妥的办法是直接用各模型厂商提供的Token计数工具实测而不是靠猜。成本预算的核心公式是单次请求成本 输入Token数 输出Token数× Token单价。听起来简单但大多数人会忽略两个变量一是系统提示词每次请求都会计入prompt写得越长固定成本越高二是输出Token数往往比想象的多尤其当你要求模型返回结构化长文本时。我见过一个项目系统提示词写了3000多个Token每次调用光提示词就要烧掉一笔钱日调用量上万次光这部分开销就占了整个预算的大头。实操建议是在项目初期就建立Token消耗监控把每次请求的输入、输出Token数记录下来按天聚合。很多开源框架和LLM网关都内置了Token统计功能直接用就行。算钱不是什么高深的事但不算钱的项目基本都会在月底收到惊喜账单。2.2 Key/Query/Value三步法把Prompt结构化关于Token网上还有一个很形象的说法叫LLM的Token三个点Key是我是谁、Query是我在找什么、Value是我能提供什么。这句话本来说的是注意力机制里的三个概念但我发现把它用来设计提示词简直是好用得不得了的方法论。我是这么用的写任何Prompt之前先按这三个层次把需求拆解清楚。Key我是谁给模型一个明确角色和背景。比如你是一名有十年经验的财务分析师熟悉合并报表规则这句话能让模型自动调动对应的知识框架和表达风格。没有角色设定的模型输出往往平庸且发散。Query我在找什么说清楚这次任务的目标、约束条件和禁止事项。比如请从以下合同文本中提取付款条款输出JSON格式字段包括付款节点和金额如果条款缺失标记为null不要自行编造。Value我能提供什么把模型需要的参考资料、输入数据、示例格式全部喂给它。这部分是模型输出的原料越充分越具体输出质量越高。把这些组合起来一个结构化Prompt模板长这样【角色】你是一名资深法律顾问专长是合同审阅。 【任务】从用户提供的合同文本中抽取付款相关的关键条款并输出JSON。 【要求】 1. 必须包含字段payment_terms, amount, currency, due_date 2. 若合同中无对应信息字段值设为 null 3. 禁止补充合同之外的任何内容不要给出法律建议 【材料】 合同原文{contract_text} 【输出格式】仅输出JSON不要输出任何解释性文字。这套模板看起来简单但它把模型不知道自己要干什么这个最常见问题直接消灭了。我实测下来结构化Prompt和随口一句话写出来的Prompt在输出规范性和准确率上能拉开20到40个百分点的差距。2.3 上下文窗口管理不要一股脑全塞进去上下文窗口是LLM一次请求能看到的最大Token数。现在动不动就宣传100K、200K上下文听着很吓人实际用起来问题一大堆。第一上下文越长计算量和内存消耗越高单次请求的延迟和成本直线上升第二模型对长上下文的注意力分配并不均匀中间段的信息很容易被遗忘这个现象在业界叫迷失在中间。所以我的原则是能塞进去的信息量控制在上下文窗口的六成以内超过这个阈值就要启动压缩策略。常用的压缩方式有三种滑动窗口摘要、关键片段裁剪、向量检索定位后再引用。我个人最常用的是分层上下文结构——固定的系统提示词放最前面里面只放角色设定和全局规则动态检索出来的业务内容放中间这部分每次根据用户问题从知识库拉取最后放的是最新的对话历史用来保持短期连续性。老实说这个方案是我踩了好几次上下文超限和模型答非所问的坑之后才摸索出来的。很多人以为上下文窗口越大越好其实管理上下文的核心是减少不相关信息而不是增加窗口尺寸。一条经验是在发送请求前先用程序估算一下Prompt的Token数如果超过窗口的八成先做摘要或裁剪这比让模型自己处理超长文本要稳得多。3. RAG与GraphRAG落地LLM Wiki和本体Ontology的正确打开方式3.1 为什么纯Prompt不够RAG的意义与边界LLM的所有知识都固化在训练时的参数里这叫参数化知识。它的缺点显而易见训练数据有截止日期最新信息一概不知内部文档、私有数据更是无从谈起。RAG检索增强生成就是来解决这个问题的——它把知识存储从模型参数中剥离出来放到外部的检索系统里需要时先把相关资料检索出来再注入提示词让模型基于这些资料回答。RAG的经典链路是文档切分→文本向量化→建立索引→根据用户问题做相似度检索→把检索结果拼进Prompt→LLM生成回答。这个思路本身不难但边界问题很突出。文档切分做不好段落语义被切断检索质量就跟不上向量检索的召回率不够模型拿不到关键材料回答自然会长出幻觉。很多团队一上来就往向量数据库里灌数据结果问答效果还不如直接用模型硬答原因就在这几个环节没打磨。我给小团队的路径建议是先做一个最小RAG——选一个具体业务问题人工整理50到100条高质量问答对和参考文档验证链路能跑通再逐步扩大知识库。不要一开始就追求全量文档灌进去的大而全那样只会让调试难度翻倍。3.2 LLM Wiki与知识库用本体Ontology组织信息热词里的LLM Wiki和LLM Ontology看起来是两个词实际说的是同一件事的两个层次。LLM Wiki通常指的是一个用LLM驱动的知识库系统把组织内部的散乱文档变成可检索、可问答的知识资产而Ontology本体是这套知识库的骨架——它定义了知识库里有哪些实体、实体有哪些属性、实体之间有怎样的关系。为什么不能只做向量检索而不做本体因为纯向量的语义检索在处理单点事实查询时表现不错但在多跳关系推理面前就力不从心了。举个例子你问哪些供应商曾经因为质量问题被列入黑名单并且还有未结清的应付账款这需要把供应商、质量事件、财务记录三类实体串起来纯向量检索很难精准完成而如果知识库里有明确的本体结构这个查询就可以沿着关系图谱一步步走。我实操中的知识库构建步骤大致是先对文档做清洗和格式统一然后用LLM从文档里抽取关键实体比如项目、供应商、审批人和关系比如项目由供应商承接审批人批准了某笔款项把抽出来的结果整理成三元组结构再存入图数据库或带关系索引的存储中。这套工作用LLM来辅助完成比纯人工高效得多但抽出来的结果一定要做人工抽检因为LLM在关系抽取上也会出错。3.3 GraphRAG从向量检索到图谱推理GraphRAG是RAG的进阶版核心思路是在RAG的文档→向量→检索基础上增加一层知识图谱先用LLM从文档中抽取实体和关系构建图结构回答问题时先在图上进行检索和多跳遍历把命中的子图内容聚合成上下文再交给LLM生成最终答案。相比原生RAGGraphRAG在处理需要全局理解、跨实体关联的问题时优势明显尤其是有哪些它们之间什么关系这类问题。但GraphRAG不是银弹它的成本比普通RAG高不少。建图阶段需要调用大量LLM做抽取整个知识库更新一次图的代价不低查询阶段要做图遍历和子图聚合延迟也比普通向量检索要长。我的建议很明确业务问题以单点事实查询为主用普通RAG就够了只有当问题集中出现多主体关联全局统计复杂约束时才值得上GraphRAG。稳妥的路径是先在普通RAG之上积累一批高频问题分析出其中的多跳推理需求再针对性地引入图谱能力。4. 生产级部署框架、网关、评测与轻量化4.1 选框架先想清楚管几个模型LLM框架与LLM网关LLM框架和LLM网关这两个概念经常被混在一起但它们解决的问题完全不同。LLM框架比如LangChain、LlamaIndex这类解决的是应用编排问题——怎么把提示词、检索、工具调用、后处理串成一个完整的应用逻辑LLM网关解决的是流量管理问题——怎么统一管理多个模型的调用入口、API密钥、限流熔断、成本统计和模型故障转移。打个比方框架是厨房里的厨师负责把食材做成菜网关是大堂的接待和调度台负责管理客人从哪个门进、去哪个桌、后厨忙不过来时怎么调配。如果你只接一个模型并且不考虑运维可以暂时不用网关但只要你有两个以上的模型或者需要把LLM能力开放给公司内部多个团队使用网关就是必需品。网关至少要做这几件事统一的API入口让业务方不用关心底层是OpenAI还是开源模型密钥集中管理避免API Key散落在各个业务代码里请求级限流与配额控制防止某个业务方把预算烧光降级与容灾策略比如主模型超时自动切换到备用模型。我比较认可的做法是先选一个成熟网关再决定是否自研——大部分团队不需要自己写网关把精力花在业务上更划算。4.2 轻量部署ONNX部署LLM模型的基本流程在部署环节热词里有一个ONNX部署LLM模型这是很多私有化部署场景里的常见需求。ONNX是一种开放的模型交换格式好处是跨平台、支持多种运行时并且和PyTorch、TensorFlow都能互通。如果你的场景是CPU推理、边缘设备、或者对硬件依赖比较敏感ONNX是一个很务实的选择。基本流程分四步第一步从HuggingFace加载你选好的模型权重和Tokenizer第二步用torch.onnx.export把模型导出为ONNX格式导出时要固定好输入输出的动态维度尤其要注意注意力掩码、位置编码这些输入项第三步用ONNX Runtime加载导出的模型配置推理会话进行推理第四步把Tokenizer的编解码和ONNX推理封装成一个统一的服务接口。这里给出一个最简导出示例import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name your-llm-model model AutoModelForCausalLM.from_pretrained(model_name, torchscriptTrue) tokenizer AutoTokenizer.from_pretrained(model_name) dummy_input tokenizer(测试输入, return_tensorspt) torch.onnx.export( model, (dummy_input[input_ids], dummy_input[attention_mask]), llm_model.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{ input_ids: {0: batch, 1: seq}, attention_mask: {0: batch, 1: seq}, logits: {0: batch, 1: seq} }, opset_version17, )导出之后还有一个关键动作是量化。ONNX Runtime支持动态量化和静态量化能在精度损失可控的情况下显著降低模型体积并提升CPU推理速度。实际操作中权重量化到INT8后模型体积能缩小到原来的四分之一左右但要注意某些算子在量化后精度下降比较明显需要逐层评估。如果你的部署目标是高并发在线服务我个人还是推荐用vLLM这类专门优化的推理引擎ONNX更适合的是边缘部署、离线批处理和对环境依赖要求严格的私有化场景。4.3 质量保障LLM as Judge和基于LLM的单元测试LLM输出的随机性让测试变得很头疼。传统断言输出等于某值在LLM场景下基本不可用因为同一问题模型每次回答都可能有措辞差异。于是LLM as Judge成了主流方案——用一个更强的模型去评估目标模型的输出质量打分维度可以是准确性、完整性、格式合规性等。用Judge模型要注意几个坑。第一Judge模型也会有自己的偏好偏差比如更倾向格式漂亮的回答而不是内容正确的回答第二评估维度必须定义得非常具体笼统的好不好没有任何可操作性第三要定期抽检Judge的评分结果看它和人工评分的一致性如何如果一致性低于七成说明你的评估维度或者Judge选型有问题。与Judge配合使用的还有基于LLM的单元测试。我在项目里的做法是先定义一组固定的测试用例覆盖核心业务场景和边界条件每次代码或提示词调整后批量跑一遍测试用例记录模型输出然后用Judge对输出打分并对输出做JSON Schema校验最后把结果汇总成回归报告。这套流程能帮你在上线前发现不少改了一个prompt其他业务场景崩了的问题比靠人工一条条看输出高效得多。5. 常见报错与排查实录5.1 Provider Rejected类错误Schema与Tool Payload排查工程化使用LLM时有一个报错出现频率极高就是LLM request failed: provider rejected the request schema or tool payload。这个问题的根源在于你调用了模型提供方的工具调用Function Calling / Tool Calling能力但你提交的工具定义Schema或者工具参数Payload不符合提供方的校验规则。我整理过几个高频触发原因工具定义里用了供应商不支持的字段不同平台对工具定义有不同约束有些平台不允许某些类型嵌套有些要求description字段必填且不能为空。参数Payload和Schema不一致你声明参数是integer类型实际传的值却是字符串或者你声明required包含某个字段但实际调用时没传这个字段。工具名字或描述超过长度限制不同提供方对工具名和描述的长度有硬限制超了直接拒。并发下参数类型推断不稳定少数情况下调用端动态生成Schema时类型推断出错导致偶发性的Rejected错误。排查这类问题我有一套固定流程。第一步把工具调用关掉用纯文本方式请求一次确认基础链路是否正常第二步把出错的工具定义和Payload打印出来逐字段核对类型和必填项第三步用提供方官方提供的Schema校验工具做离线校验第四步如果Payload是动态生成的在生成的地方加类型断言确保整数是整数、字符串是字符串。大多数情况下走到第三步就能定位问题。这类报错本身不可怕可怕的是没有日志和监控下次出现还是抓瞎。5.2 其他高频问题简报除了上面的Schema问题实际使用中还有几个高频状况我把它们整理成一个速查表问题现象常见原因处理建议请求报上下文超限输入内容超过窗口长度启动摘要压缩、滑动窗口或检索裁剪回答内容前后不一致temperature设置过高把temperature降到0.2或更低固定few-shot示例中文回答混杂英文或表达生硬模型对中文适配不足在系统提示词中明确要求中文输出或更换中文优化模型回答出现幻觉性事实检索材料不足/噪声过多强制要求引用来源RAG阶段提高检索精度调用偶发超时或限流超出供应商速率限制接入LLM网关做限流退避和重试必要时切换备用模型工具调用返回格式异常模型生成的工具参数非法增加输出Schema校验对非法输出做重试或修复再提交这些问题的排查思路有一个共性先分清是模型问题、链路问题还是数据问题。模型问题优先调提示词和参数链路问题检查网关、超时和重试数据问题则要回到知识库的清洗和检索环节去找根源盲目重试没有意义。最后再分享一个我个人的使用体会。大模型项目能不能成很多时候差的不是算力也不是模型能力而是使用方法——有没有想清楚模型的能力边界有没有管理好Token和上下文有没有用RAG把私有知识接进来有没有在工程化上做好网关、评测和监控。我的建议是不要一上来就搭建一套庞大的架构先从一个小而完整的闭环跑起来一个具体问题、一份清洗后的知识库、一个稳定调用的模型、一套可量化的评测集。等这个闭环稳定了再层层扩展。你会在实践中发现LLM使用的正确姿势不是从某个教程里背出来的而是从一次次报错和对比中试出来的。