1. 从零上手LLM先搞清楚你手里拿的是什么牌很多人第一次接触LLM脑子里蹦出来的第一个问题就是“这玩意儿到底怎么用”。我见过太多人一上来就急着调API、跑模型、搭框架结果连自己用的模型是什么类型、能干什么、不能干什么都没弄明白最后踩了一堆坑回头补课。所以这篇东西我打算按实际操作的顺序把LLM使用过程中真正会遇到的问题一个个拆开讲不搞那些虚头巴脑的概念堆砌。先给完全没接触过的朋友一个最直白的定义LLM就是大语言模型Large Language Model本质上是一个用海量文本训练出来的概率模型你给它一段输入prompt它根据训练时学到的统计规律一个token一个token地往外吐输出。它不是在“思考”也不是在“查数据库”而是在做下一个token的概率预测。理解这一点非常关键因为后面很多使用技巧和坑根源都在这里。那LLM能做什么文本生成、摘要、翻译、代码补全、问答、信息抽取、对话、角色扮演、格式转换这些是最常见的用法。它不能做什么不能保证事实准确性、不能做精确数学计算除非借助工具、不能访问实时信息除非外挂检索、不能记住你上一轮对话之外的东西除非你把上下文塞进去。适合谁来学不管你是开发者、产品经理、运营、研究者还是纯粹的好奇者只要你想把LLM用起来解决实际问题这篇内容都适用。我自己的经验是把LLM当成一个能力很强但非常 literal 的实习生——你说什么它就做什么你没说的它不会主动帮你补你表达模糊它就自由发挥。所以“怎么用”的核心其实就两件事怎么把话说清楚以及怎么给它配上合适的工具和知识。2. LLM核心概念拆解Token、上下文窗口与模型选型2.1 Token到底是什么为什么它决定了你的钱包和效果Token是LLM处理文本的最小单位。你可以把它理解成“词片”——一个英文单词可能是一个token也可能被拆成好几个一个中文字通常对应1到2个token具体取决于分词器。比如“我是谁”这三个字在不同模型的分词器下可能是2到4个token。为什么要在意token两个原因。第一API计费按token算输入和输出都算钱你prompt写得越长成本越高。第二上下文窗口按token算模型一次能“看到”的token数量是有上限的超出部分要么被截断要么直接报错。我实测下来一个粗略的换算经验英文大约1个token对应0.75个单词中文大约1个token对应0.5到1个汉字。但这个比例因模型而异最靠谱的办法是用对应模型的分词器实际跑一下。很多平台都提供了token计数工具调API之前先数一下能省不少冤枉钱。注意不要用“字数”去估算token尤其是中英混排、代码、特殊符号混在一起的时候误差会非常大。我见过有人按字数算预算结果实际账单翻了三倍。2.2 上下文窗口LLM的“工作记忆”有多大上下文窗口context window指的是模型单次推理能处理的最大token数包括你输入的prompt和它生成的输出。早期模型只有2K、4K现在主流模型动辄32K、128K甚至更大。这个参数直接决定了你能怎么用LLM。窗口小你就只能做短对话、短文本处理窗口大你才能塞进去整篇文档、多轮对话历史、甚至一整个知识库的片段。但这里有个很多人不知道的坑窗口大不等于效果好。模型在超长上下文里会出现“中间遗忘”现象——放在上下文中间位置的信息模型回忆起来的准确率明显低于开头和结尾。所以如果你要往上下文里塞大量材料把最关键的信息放在开头或结尾中间放次要内容这是一个非常实用的技巧。2.3 模型选型开源还是闭源大还是小选模型这件事没有绝对的最优解只有适不适合你的场景。我一般按这几个维度来决策维度闭源大模型API开源自部署模型上手速度极快注册就能用需要环境、显卡、部署经验效果上限通常更高取决于模型规模和微调数据隐私数据要发给第三方数据完全本地成本结构按token付费前期硬件投入后期边际成本低可定制性有限主要靠prompt可以微调、量化、改结构维护负担平台负责自己负责如果你是做原型验证、效果优先、数据不敏感直接用闭源API最省事。如果你有数据合规要求、需要离线运行、或者要深度定制那就走开源自部署路线。开源模型里参数量从1B到70B甚至更大都有小模型跑得快但能力有限大模型效果好但吃硬件。7B到14B这个区间在消费级显卡上比较现实再往上基本就要考虑多卡或量化了。关于公开榜单比如Open LLM Leaderboard这类我的态度是参考可以迷信没必要。榜单测的是通用基准你的实际任务可能完全不在那个分布里。我见过榜单排名很高的模型在我自己的业务场景里表现平平也见过排名一般的模型在特定任务上出奇地好用。最终还是要拿你自己的数据去测。3. Prompt工程实操把话说清楚比什么都重要3.1 三个核心要素Key、Query、Value热词里提到的“token三个点key我是谁、query我在找什么、value我能提供什么”其实对应的是信息检索和RAG里的核心概念但放到prompt设计里同样适用。我把它翻译成prompt语言Key我是谁给模型设定角色和身份。“你是一个资深法律顾问”“你是一个Python代码审查专家”——这决定了模型调用哪部分知识和语气。Query我在找什么明确告诉模型你要什么。“帮我总结这段合同的风险点”“找出这段代码的bug”——任务指令要具体。Value我能提供什么把你手头的信息、约束条件、输出格式要求给清楚。“以下是合同全文……”“输出用表格三列风险点、严重程度、建议”。这三个要素齐了prompt的基本盘就稳了。缺了Key模型不知道用什么身份回答缺了Query模型不知道你要干什么缺了Value模型只能瞎编或者泛泛而谈。3.2 结构化Prompt的写法与模板我平时用得最多的prompt结构是这样的# 角色 你是一个[具体角色]擅长[具体能力]。 # 任务 请根据以下[输入类型]完成[具体任务]。 # 输入 [把你的材料贴在这里] # 约束 - 输出语言中文 - 输出格式[JSON/表格/段落] - 不要编造输入中没有的信息 - 如果信息不足明确说明缺少什么 # 输出 [可以给一个示例]这个模板看起来简单但每一条都有用。角色设定让模型收敛到合适的知识区域任务描述要动词明确约束条件里“不要编造”这条尤其重要能显著降低幻觉给输出示例则是在做few-shot模型会模仿你给的格式。3.3 常见Prompt反模式与修正我踩过的prompt坑基本都集中在这几类反模式一指令太模糊。“帮我写个方案”——写什么方案给谁看多长什么风格模型只能猜。修正把背景、目标、受众、长度、格式都写清楚。反模式二一次塞太多任务。“帮我总结这篇文章然后翻译成英文再提取关键词最后写个标题”——模型可能只做前一两步就停了。修正拆成多轮或者用明确的编号步骤并要求它逐步输出。反模式三否定式指令。“不要写得太啰嗦”——模型对“不要”的处理往往不如“要”来得稳定。修正改成正面指令“用不超过200字每段不超过3句”。反模式四没有给输出格式。你想要JSON结果它给你一段散文。修正直接给JSON schema或者示例。实操心得如果你发现模型输出不稳定先别急着换模型先把prompt改三遍。我大概有七成的问题是通过改prompt解决的剩下三成才是模型能力或工具链的问题。4. RAG与知识库让LLM用上你自己的数据4.1 为什么需要RAGLLM的训练数据有截止日期而且不包含你的私有数据。你问它“我们公司上季度的销售数据”它要么说不知道要么编一个。RAGRetrieval-Augmented Generation检索增强生成就是解决这个问题的标准方案先从你的知识库里检索出相关片段再把片段塞进prompt里让LLM基于这些片段回答。RAG的核心流程是文档切分 → 向量化 → 存入向量库 → 用户提问时检索最相关的片段 → 拼进prompt → LLM生成回答。每一步都有讲究切分粒度、embedding模型选择、检索策略、重排序任何一个环节出问题都会影响最终效果。4.2 LLM Wiki与知识库的搭建思路热词里反复出现的“LLM Wiki”“LLM Wiki知识库”“LLM Wiki项目”本质上就是把wiki形态的知识内容做成RAG可用的知识库。我自己的做法是文档预处理把wiki页面转成纯文本或Markdown去掉导航、页脚这些噪音。切分按语义切分不要按固定字数硬切。一个段落、一个小节为单位比较合理通常200到500字一段。向量化用embedding模型把每段转成向量。中文场景下选支持中文的embedding模型别直接用英文模型硬套。存储向量库存进专门的向量数据库同时保留原文和元数据来源、标题、时间。检索用户提问时把问题也向量化做相似度检索取Top-K个片段。重排序如果对精度要求高加一个rerank模型对检索结果重新排序。生成把检索到的片段和用户问题一起拼成prompt让LLM基于片段回答并要求它标注信息来源。4.3 GraphRAG与本体什么时候值得上普通RAG是“扁平”的——它检索的是一段段独立的文本片段片段之间的关系它不知道。GraphRAG则是在此基础上构建知识图谱把实体和关系抽出来检索时不仅看文本相似度还看图谱上的关联。热词里的“llm ontology”“rag graphrag llm wiki 本体rag”说的就是这个方向。什么时候值得上GraphRAG当你的问题需要跨文档、多跳推理的时候。比如“A公司的CEO曾经在哪些公司任职这些公司里有哪些和B公司有合作关系”——这种问题普通RAG很难答好因为它需要把多个片段里的实体关系串起来。但GraphRAG的代价也很明显构建图谱需要额外的抽取和校验成本维护复杂度高而且不是所有场景都能带来明显提升。我的建议是先用普通RAG跑起来遇到多跳推理的瓶颈再考虑GraphRAG不要一上来就上重型方案。5. 部署与工具链从API调用到本地运行5.1 API调用最省事的起步方式如果你只是想快速用起来调API是最短路径。基本流程就是注册平台 → 拿API key → 按文档发请求 → 解析返回。大多数平台都兼容OpenAI风格的接口所以你会了一个基本能套用到其他家。# 以OpenAI风格接口为例的调用示意 from openai import OpenAI client OpenAI(api_key你的key, base_url平台地址) response client.chat.completions.create( model模型名称, messages[ {role: system, content: 你是一个专业助手。}, {role: user, content: 用三句话解释什么是token。} ], temperature0.7, max_tokens500 ) print(response.choices[0].message.content)几个关键参数temperature控制随机性0更确定1更发散做事实问答用低值做创意写作用高值max_tokens限制输出长度top_p是另一种采样控制一般和temperature二选一调。5.2 本地部署ONNX与量化热词里提到“onnx部署llm模型”ONNX是一种模型交换格式好处是跨框架、跨硬件推理时可以用ONNX Runtime做加速。把LLM导出成ONNX再部署适合对推理性能有要求、又不想绑定特定框架的场景。但说实话LLM的ONNX部署比传统模型麻烦不少因为LLM有动态shape、KV cache、注意力机制这些复杂结构。我的经验是小模型1B到7B用ONNX部署比较现实大模型还是用专门的推理框架更省心。量化是另一个绕不开的话题。把模型权重从FP16降到INT8甚至INT4显存占用能降一半到四分之三速度也能提升代价是效果会有一定损失。INT8量化通常损失很小INT4就要看具体模型和任务了。消费级显卡跑本地模型量化基本是必选项。5.3 LLM网关多模型统一管理“llm 网关”这个词指的是在多个LLM之上加一层代理统一接口、统一鉴权、统一计费、统一路由。比如你同时用好几家模型网关可以让你用同一套代码调用不同模型还能做负载均衡、失败重试、限流。自己搭一个简单网关并不难核心就是转发请求加上一些中间逻辑。但如果团队规模不大、模型数量不多直接用各家SDK也不是不行。网关的价值在模型多、调用量大、需要统一治理的时候才明显。6. 常见问题与排查技巧实录6.1 模型胡说八道怎么办幻觉是LLM的固有特性不可能完全消除但可以显著降低。我的排查顺序是检查prompt是否给了足够信息。如果模型没有依据它只能编。加约束。“只根据以下材料回答材料中没有的信息说不知道。”降低temperature。高温会增加发散和编造的概率。上RAG。把事实性内容通过检索注入而不是靠模型记忆。要求引用来源。让模型标注每句话来自哪个片段方便你核查。6.2 输出格式不稳定怎么办明明要JSON它给你加了一段“好的以下是JSON”。解决办法用few-shot给一个完整的输入输出示例。用结构化输出功能如果平台支持的话。在prompt里明确“只输出JSON不要任何其他文字”。后处理时用正则把JSON部分抠出来。6.3 速度慢、成本高怎么优化问题可能原因优化方向响应慢模型太大、输出太长换小模型、限制max_tokens、流式输出成本高prompt太长、调用太频繁精简prompt、缓存重复查询、批处理并发上不去平台限流加队列、错峰、多平台分流本地跑不动显存不足量化、换小模型、CPU offload6.4 常见问题速查表现象排查方向快速修复回答答非所问prompt指令是否清晰重写任务描述加示例中文夹英文模型训练数据偏英文指定输出语言换中文能力强的模型重复啰嗦temperature过低或prompt要求不明确调高temperature加长度约束拒绝回答触发安全策略调整表述方式确认内容合规上下文丢失超出窗口或中间遗忘精简上下文关键信息放首尾检索不准切分粒度或embedding不匹配调整切分换embedding模型加重排序避坑技巧每次改完prompt或检索策略固定一组测试问题跑一遍对比前后效果。凭感觉调参很容易越调越乱有基准测试才能知道到底有没有变好。7. 一些实际用下来的体会LLM这个东西上手容易精通难。最容易犯的错误是把它当成万能工具指望它解决所有问题。实际上它更像是一个能力很强但边界清晰的组件你需要围绕它设计整个流程——prompt怎么写、知识怎么注入、输出怎么校验、失败怎么兜底。我自己的习惯是任何要上生产的LLM应用先做小规模人工评估攒个几十上百条真实case人工标注好坏再决定要不要继续投入。别一上来就追求全自动、全链路先把单点跑通再逐步扩展。另外模型迭代很快今天的最优解下个月可能就变了。所以架构上尽量把模型调用层抽象出来换模型的时候不用改上层业务逻辑。这个投入在长期看非常值。最后分享一个我常用的调试方法当你不知道模型为什么输出某个结果时把完整的prompt打印出来自己读一遍。很多时候你会发现如果换成你是一个完全不了解背景的人看了这个prompt也会给出类似的“错误”回答。问题往往不在模型而在我们以为自己说清楚了其实没有。