尧图网站建设 
1. 先把概念揉碎LLM到底是什么怎么才算“会用”先说实话我接触过的开发者里能从“调通API”到“真正用好LLM”之间往往隔着一道看不见的坎。这个坎不在于会不会写代码而在于有没有把几个底层概念吃透。LLM的使用方法说白了不是“记住几个接口、会写几个提示词”这么简单而是一整套从模型理解、场景拆解到工程落地的思维转换。1.1 LLM本质是下一个token预测器不是搜索引擎大语言模型LLM的核心是在给定上文的情况下预测下一个最可能出现的词元token。它本质上是一个条件概率分布估计器——你给它“今天天气真”它就会按概率输出“好”“棒”“不错”等候选。我见过很多人把它当搜索引擎用上来就问“中国有多少人口”模型答了个数字就觉得它在“检索”。其实它是在“续写”。这个区别决定了使用姿势完全不同搜索引擎靠索引命中LLM靠模式泛化。所以同一个问题你换个问法、加个上下文、给个示例结果可能天差地别。至于“LLM是否属于深度学习”这个问题答案当然是肯定的。LLM是深度学习中自然语言处理方向的集大成者核心架构是Transformer靠海量文本预训练得到语言能力再通过指令微调SFT、人类反馈强化学习RLHF等步骤“学会听话”。理解这个脉络你才知道为什么有些模型“聪明但不好使”有些模型“笨但特别听话”——这就是基座能力和对齐调教之间的博弈。1.2 Token、上下文窗口和Attention机制的“三把钥匙”搞懂LLM绕不开的是token。Token是模型处理文本的最小单位可以是单词、子词甚至单个字符。中文场景尤其要注意一个汉字在不少模型中会被拆成1~2个token1000个汉字往往对应1000~1500个token。API计费、上下文长度、生成速度全部围绕token展开。我之前用某模型跑一批简历解析一篇三千字的简历动不动就吃掉3500个token等反应过来账单已经翻倍了。所以在使用LLM之前先给自己备一个tokenizer工具比如在线tokenizer、huggingface的tokenizers库把输入文本提前量一量这是省钱的第一步。另一个关键概念是上下文窗口就是模型一次能“看到”的最大token数。拿聊天举例如果窗口是8k你的历史对话系统提示词当前问题加起来超过8k最早的内容就被“挤”出去了模型就会“失忆”。我踩过最典型的一个坑多轮对话里塞了一堆长长短短的历史消息表面上模型还在回复实际上前面几轮的关键信息早就被截断了。解决方案很简单定时对历史消息做摘要压缩或者只保留最近N轮。再说那个流传很广的说法——LLM的token三个点是“Key我是谁、Query我在找什么、Value我能提供什么”。这句话不是在玩概念它直接对应Transformer注意力机制里的QQuery、KKey、VValue三个矩阵。用人话说就是模型在处理某个词时会拿着“我的问题”Query去和文本中其他词携带的“身份标识”Key做对比看哪些词和我相关然后根据相关度去提取它们携带的“实际内容”Value。比如处理“苹果把库克任命为CEO”这句话模型遇到“库克”时会让它和“苹果”“任命”“CEO”这些词的Key做匹配相关度高就加大权重最终融合出的结果就包含了“库克是苹果公司CEO”这层语义。这三个点的比喻本质是在帮我们理解注意力机制里三个角色的分工。明白这个你就知道为什么LLM能处理长距离依赖关系也知道为什么上下文被截断会让模型“抓瞎”——因为相关内容根本不在它的注意力范围内了。1.3 公开榜单怎么用Open LLM Leaderboard只能当参考热词里提到了Open LLM Leaderboard这类公开榜单。很多朋友一上来就盯着排行榜选模型觉得排前面的就是最好的。但我实际用下来榜单分数和真实业务表现之间往往隔着一条鸿沟。排行榜测的多是通用知识、推理能力、指令遵循而你的场景可能是合同审查、简历筛选、客服问答、SQL生成通用分高不代表在这些垂直场景里就好使。我自己有个习惯拿到一个新模型不急着上生产先拿真实业务里的50~100条样本跑一遍人工看结果和现有模型做对比。这个“小样本人工评测”比看任何榜单都有说服力。榜单的真正价值在于帮你圈定候选池筛掉明显不行的模型但不能替你拍板。2. 手把手走通选型与接入从模型选择到API调用的完整链路概念清楚了就要解决最现实的问题我到底该用哪个模型怎么接入用什么工具管理这些接入。这一步是LLM使用方法里最容易卡住新人的地方因为可选的东西太多了反而不知道该选什么。2.1 先问自己三个问题再选模型第一我的场景是“要知识深度”还是“要执行指令”如果是要做行业问答、知识库检索、内容总结那选通用能力强的基座模型比如Qwen系列、DeepSeek系列如果是要让模型调用工具、写代码、操作外部系统那选指令遵循能力强的模型比如Claude系列、GLM系列。第二我的数据隐私要求有多高如果只是内部工具、非敏感场景直接用第三方API最省事如果涉及客户隐私、商业机密就要考虑私有化部署或使用合规的私有化API。第三我的预算成本控制在什么范围这个要算综合成本包括API调用费开发人力维护成本不是哪个便宜选哪个而是“性价比最优”。我自己做过一个OCR文档抽取项目最初选了当时榜单第一的大模型效果好但贵得离谱后来换成中等开源模型加了一点提示词优化准确率只掉了1.5%成本却降到了原来的十分之一。这种取舍不实际跑一遍根本没法拍板。2.2 第三方API网关与模型切换工具用CC Switch接入DeepSeek、Qwen、GLM现在国内外的模型API其实已经非常成熟DeepSeek、通义千问Qwen、智谱GLM都有官方API但实际开发中你会遇到一个很现实的问题今天你觉得Qwen好明天可能DeepSeek出了新版本效果更优后天客户指定要用GLM。如果每个模型都在代码里硬编码一套接口改来改去会非常痛苦。这时候就需要一个统一的“模型接入层”。我目前比较推荐的做法是使用第三方API网关或模型切换工具比如热词里提到的CC Switch。这类工具的核心价值是统一一套接口规范底层去适配不同厂商的API让你在代码里只对接一个地址通过配置切换模型供应商。我用CC Switch接入DeepSeek、Qwen、GLM的实际操作大致是三步。第一步在工具里配置各个模型的API Key和Endpoint第二步设置统一的基础URL比如本地代理地址让应用只认这一个地址第三步在请求参数里指定具体模型名用完随时切换。这样做的最大好处有两个一是避免厂商锁定想换模型只是改配置的事不用动代码二是方便对比评测同样的提示词切到不同模型上跑一跑效果高下立现。接入第三方API时还有几个非常实操的要点。第一版本号一定要锁定不要在代码里直接写默认版本一旦厂商把默认版本升级你的应用可能悄悄被换到底层模型行为就变了。第二兜底逻辑必须做API超时、限流、返回格式异常都要有重试和降级方案。第三流式输出streaming体验好但调试难如果首次接入建议先关流式把逻辑跑通再加流式优化体验。第四网络超时和连接池要设置好尤其是并发高的场景Python的openai库默认超时很多时候不够用生产环境建议把timeout调大同时用连接池控制并发防止打爆对端。这些细节看着小恰恰是“会用”和“不会用”的分水岭。2.3 本地部署ONNX Runtime跑LLM的保姆级流程很多场景下数据不能出内网必须本地部署。这里就牵涉到热词里出现的“ONNX部署LLM模型”。ONNX Runtime是微软开源的推理引擎优势在于跨平台、支持CPU/GPU异构、针对推理做了很多优化。我把一个开源模型导出为ONNX格式并本地跑起来的流程简单梳理一下。首先准备工作。你需要一台有足够内存的机器CPU部署的话16G内存起步GPU部署建议显存至少8G。Python环境准备好安装onnxruntime、transformers、torch这几个基础库。然后获取模型。从HuggingFace或ModelScope找一个开源模型比如Qwen2.5系列、Llama系列等用transformers加载后导出ONNX。导出时核心是要指定opset版本和quantization策略。我一般推荐先用float16精度导出模型体积小一半推理速度也更快只有在精度损失不可接受时才换float32。然后你就可以用ONNX Runtime进行推理了。核心代码逻辑大致是import onnxruntime as ort from transformers import AutoTokenizer # 加载tokenizer tokenizer AutoTokenizer.from_pretrained(qwen/Qwen2.5-1.5B-Instruct) # 创建ONNX推理会话 session ort.InferenceSession(model_fp16.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider]) text 帮我写一个Python读取CSV文件的示例 messages [{role: user, content: text}] inputs tokenizer.apply_chat_template(messages, tokenizeTrue, return_dictTrue) # 转为ONNX Runtime期望的numpy格式 ort_inputs {k: v.cpu().numpy() if hasattr(v, cpu) else v for k, v in inputs.items()} outputs session.run(None, ort_inputs) # 从输出中解码生成结果 response tokenizer.decode(outputs[0][0], skip_special_tokensTrue) print(response)这里的细节在于apply_chat_template它负责把对话格式转成模型期望的指令格式每家模型要求的模板不一样比如Qwen用的是|im_start|user之类的标记Llama用的是[INST]标记。用错模板的典型症状是模型答非所问或者疯狂重复标点。ONNX部署最大的优势是资源占用可控、推理速度稳定缺点是需要处理模型转换和优化调试成本比直接用API高。它的适用场景非常明确内网离线部署、对数据安全要求极高的行业或者要做私有化交付的甲方项目。2.4 说清楚LLM网关到底解决什么问题LLM网关这个概念这几年特别火它本质上是一个“大模型应用入口”位于应用和模型之间负责请求转发、身份认证、限流、熔断、日志采集和成本统计。它和“模型切换工具”的区别在于切换工具解决“多模型随手换”网关解决“面向多团队、多应用、多模型时怎么统一治理”的问题。在团队开发场景里核心价值非常明显。比如你们团队有5个应用每个应用都用好几款模型如果没有网关每个人各自配置API Key月底账单对不上出了问题也不知道是哪个应用调了哪个模型导致的。有了网关统一入口、统一鉴权还能按部门/应用维度统计token消耗做精细化的成本管理。网关还可以做缓存策略比如同样的请求短时间内若有人问过就直接返回缓存结果能省不少成本。我见过做得好的网关方案直接把某团队的月成本压掉30%以上。所以我的建议是个人开发用“切换工具”就够团队协同、生产环境必须上“网关”这套治理思路。3. 提示词工程实战如何把模型调成“老员工”而不是“新人”模型选定、接口打通接下来决定体验的就是提示词功底。同样是调一个API有人拿回来的结果能用有人拿回来的结果像一坨没组织好的口语区别全在提示词。提示词工程不是写作文是有方法论的。3.1 结构化提示词框架像写开发需求文档一样写提示词我的提示词模板可以分享给大家经过多次打磨后我总结了一个“五段式”结构非常稳定好用适合绝大多数业务场景。角色定义明确让模型扮演什么角色。比如“你是一名有10年经验的Java架构师”而不是直接说“帮我写代码”。任务描述清晰说明要做什么。这里必须具体避免“帮我分析一下”这种模糊表达改成“请提取这份合同中的付款条款、违约金比例、最长履约期限”。输入数据把待处理的内容明确框起来用分隔符如输入和/输入告诉模型哪些是数据防止它把数据混入指令。输出要求规定输出格式比如“输出为JSON数组包含字段name和value”这能极大提升结果的结构化程度。边界与说明告诉模型什么不要做比如“不要推测不存在的信息”“如果原文没有相关内容输出空字符串”。举一个实际例子我用GPT-4级别模型做会议纪要时提示词是你是总裁办助理擅长提炼会议决策。请根据以下会议记录输出三部分内容——“决策事项”“责任人”“截止时间”。会议记录我用记录.../记录框起来。这样出来的结果基本不用改直接能填进周报。而如果直接问“请帮我总结一下这个会议”模型给的就是一堆废话文学。3.2 角色设定和Few-shot让模型“入戏”的两种武器角色设定System Prompt的核心原理是给模型一个稳定的“出发状态”。做过实验的朋友都知道同样的任务加上“你是一名资深律师”和只写“帮我审合同”输出的专业深度完全两回事。原因在于角色设定把模型的输出分布拉向了特定风格和知识模式这和模型训练时学到的各种文体模式有关。当然角色不是瞎吹你要给自己设计的角色配备足够的“资料”专业的术语、行业的习惯、输出风格偏好都要写清楚。Few-shot少样本示例则更进一步直接给模型看几个“标准答案示例”。它在处理格式类任务时几乎是无敌的。比如我要从发票信息里抽取字段除了规则说明我还会给它两个输入输出对样例。它看到样例后就明白字段抽取的边界在哪里什么该抽什么不该抽。Few-shot的使用有一个要点示例一定要有代表性最好正例、反例、边界例都有。比如我让模型判断文本情感我会给三个示例一个明显正面一个明显负面一个含含糊糊。这个“含糊”的示例往往决定了模型后续遇到边界case时是偏向保守还是激进。3.3 温度、Top-p这些参数到底怎么调热词里提到“llm的token三个点”那是模型内部机制真正影响输出风格的是我们在外部可以调控的推理参数。最常遇到的是temperature温度和top_p核采样。我打个比方每个候选token都带着一个概率temperature就是把概率分布拉平或拉尖。温度越高分布越平输出越随机、越有创意温度越低输出越确定、越保守。0到1之间一般场景我会这样设0.0~0.3代码生成、抽取、格式化、OCR修正等追求准确稳定的任务0.4~0.7客服回复、内容总结、写作辅助等需要自然语言但不容许太跑偏的任务0.8~1.2头脑风暴、创意写作、文案灵感等需要发散的任务。top_p是另一种控制多样性的方式取值0到1代表“只从累计概率达到p的最小token集合里采样”。实践中top_p和temperature不要同时猛调一般固定一个动另一个。我个人的使用习惯是生产环境固定temperature0.2, top_p0.9既稳定又有一定的容错空间创意场景固定top_p0.95再微调温度来改变发散程度。另外还有一个容易忽略的参数是max_tokens最大生成长度很多AI生成中断、答案不完整其实不是模型不行而是你把输出长度限制得太短了。估算一下一个汉字约等于1~2个token要给模型留够“发挥空间”。4. 进阶玩法拆解RAG、GraphRAG和LLM as Judge基础能力打通后很多人的需求会走向“让模型更懂我的私有数据”和“让模型替我做评估”。这就绕不开RAG、GraphRAG以及LLM as Judge这些进阶玩法。4.1 RAG给LLM接上外挂知识库RAG检索增强生成的核心思路很简单你在让模型回答问题前先从自己的知识库里检索相关片段把这些片段作为上下文塞给模型它基于这些内容生成回答。这样做的价值显而易见第一模型不再依赖训练时固有知识可以回答自己的私有业务问题第二可以通过更新知识库来更新答案不用重新训练模型第三答案可以溯源到具体文档方便审计。RAG的实际落地流程一般包括四个环节。文档清洗把PDF、Word、Excel转成纯文本去掉页眉页脚、水印、乱码文本切分按语义或固定长度切成chunk我实测下来中文场景500~800字一截比较稳妥太短了语义不全太长了检索噪音多向量化入库用embedding模型把每个chunk变成向量存入向量数据库检索问答用户提问时把问题向量化在库里做相似度检索取Top-K相关片段组装提示词后交给LLM生成答案。这个链路看着简单但每个环节都有坑切分时把一段完整的话拦腰截断、检索时召回不相关片段、向量模型和知识域不匹配等都会导致回答质量崩掉。关于RAG和LLM Wiki的关系可以这样理解LLM Wiki是知识库的内容源RAG是利用这些内容做问答的手段两者配合才是完整的知识服务方案。4.2 GraphRAG比普通RAG多出来的关系推理能力GraphRAG是这两年出现的RAG升级版核心是在纯文本切分之外额外构建一张知识图谱。普通RAG只能做“基于相似度的字面检索”遇到需要多跳推理的问题比如“A公司的母公司是BB的竞争对手是C那么A和C有关系吗”普通RAG基本无能为力因为它检索到的片段之间没有关联GraphRAG通过实体抽取和关系抽取把文档中的核心概念连接成图检索时不仅做相似度匹配还会沿着图结构扩散把相关的实体、关系一起捞回来。GraphRAG的项目落地比普通RAG重很多需要额外做实体识别、关系抽取、图谱存储和查询。我的建议是如果你的场景是文献综述、行业研究报告、复杂企业关系分析这类“关系密集”的任务GraphRAG值得投入如果只是FAQ问答、政策条款检索普通RAG就够不要为了追新把架构搞复杂。我自己曾经在项目里强行上GraphRAG结果光实体识别模型选型和调优就搞了一周后来发现用户真正的高频问题用普通RAG就能解决。这是血的教训——先看需求再选技术。4.3 LLM as Judge让模型当“裁判”靠谱吗LLM as Judge就是用大模型来评估大模型的输出质量。传统评估方式是人工打分慢且贵自动评估指标如BLEU、ROUGE又太机械抓不住“内容合理”“逻辑连贯”这类高维质量。所以业界开始用大模型当裁判给被测模型的回答打分或排序。实际操作中一种常见的做法是构造一个“裁判提示词”把任务描述、候选回答、评分标准一起发给裁判模型让它打分并给出理由。这里有个关键经验裁判模型本身要有足够强的能力通常要选择同级别或更高级别的模型否则会出现“差模型评更好模型”的尴尬评分标准尽量用Rubric式的细则把“5分信息完整无虚构格式正确”这类标准写清楚别写“请打分”一句话了事还要警惕位置偏差多个候选放在一起时模型容易偏向第一个或最后一个可以通过随机调换顺序多次评测取均值来缓解。LLM as Judge虽然不完美但只要评测标准设计得当它的效率和一致性远远超过人工抽检。现在我自己的项目里AI生成结果的质量回归测试基本都用这种方式人工只保留抽查环节。5. 实操记录从0到1实现一个“文档问答助手”的完整过程前面讲了这么多概念、方法、经验这一节我用自己做过的一个真实小项目把整个链条串起来——做一个“企业制度文档问答助手”。这个项目麻雀虽小但五脏俱全涵盖了场景定义、模型选型、提示词设计、接口接入、RAG落地和问题排查的全部环节。5.1 场景定义、方案选型与成本测算背景是我给一家中小型公司做内部工具员工经常要在上百份制度文档里搜某条规定传统搜索体验很差。需求是员工输入一句大白话系统能给出相关制度依据和明确答复。方案选型的关键判断点有几个。第一数据敏感性中等内部制度不算绝密但不能随便上公网最终选了私有化的开源模型方案。第二模型选型对比了Qwen和GLM系列最终选了Qwen2.5-7B-Instruct量化版因为它在通用知识和中文指令遵循上表现均衡且在本地CPU/GPU混合环境能跑得动。第三架构确定为大致的“文档解析→向量化→RAG检索→LLM生成”没有上GraphRAG理由很简单制度问答主要是单点事实查询不需要多跳推理。成本测算我做了个表供大家参考项目开源自建服务器GPU租赁约800元/月embedding模型免费开源向量模型LLM推理资源包含在服务器内维护人力约0.5人天/月对比第三方API成本按当月调用量估算约省30%~50%5.2 提示词设计从“随便问问”到“标准交付”我最终使用的系统提示词长这样你是某公司的制度问答助手。用户会向你提问公司制度相关内容。 回答要求 1. 只能依据检索到的制度片段回答不得编造制度内容 2. 如果检索片段不足以回答直接说“根据现有制度文档暂未找到相关内容” 3. 回答需注明出处格式为“根据《XX制度》第X章第X条” 4. 用户问题可能很口语化你要先理解意图再匹配制度条文 5. 回答控制在200字以内先结论后依据。这里有几个设计心得。第一“不得不编造”是制度类问答最关键的必须写死第二“先结论后依据”符合业务阅读习惯第三“告知未找到”是为了减少模型硬凑答案的幻觉问题。我还配合做了几个few-shot示例把“工龄满一年可以休几天年假”这种高频问题的最优答法给模型看过一遍实际效果提升非常明显。5.3 开发联调与效果验证联调阶段我把它分成三层。第一层纯LLM接口验证直接调模型测试它是否理解角色和输出要求。这里最容易出的问题就是模型把别的制度内容也“带”进来乱答。第二层RAG检索质量验证拿50个真实问题跑一遍检索统计Top-5召回里有没有正确答案如果召回率低于80%就要调整切分大小或改embedding模型。第三层端到端验证用户问题走完“检索→组装→生成→溯源”全链路重点检查回答有没有涉及检索片段之外的内容。整个验证过程花了大概3天我把50个问题的验证结果做成表格逐条记录是哪一环出的问题——模型问题改提示词检索问题改切分源头问题改文档清洗规则。这个过程特别重要因为一旦问题定性错了后面所有优化都是白费力气。5.4 全流程走通的几个通用要点第一日志要全覆盖。从用户请求到检索结果到最终答案每一步都要有日志否则出了问题根本没法回溯。我吃过一次亏线上用户反映答非所问我查了半天才发现是embedding模型服务挂掉了检索结果全为空。幸好有日志不然只能大海捞针。第二提示词版本管理。很多人改提示词是直接在代码里改改完不记录结果效果变好了也说不清是哪里起了作用。我的做法是把提示词模板放到独立配置文件里配Git版本管理每次改动都留commit信息。第三灰度发布。不要一把全量切新模型先让5%的流量跑一跑对比效果再推广。第四监控告警要设置服务挂了、响应变慢、token消耗异常都要有告警。它不是你写了就完事的东西而是保证你“敢睡个安稳觉”的基础设施。6. 常见问题与排查实录把踩过的坑一次说清楚最后分享一些高频问题和排查经验这些几乎是我在帮别人看LLM项目时一定会被问到的内容。6.1 高频报错与排查思路速查表报错/问题常见原因排查与解决LLM request failed: provider rejected the request schema or tool payload发送给模型的工具调用参数格式与模型不完全兼容或模型不支持该工具类型检查工具定义是否遵循模型要求的JSON Schema格式先用最小化工具测试看看是否把复杂嵌套参数搞复杂了简化工具结构再试回答前后矛盾、答非所问上下文窗口被截断、系统提示词被后续内容淹没、检索内容噪音太大检查上下文占用率必要时压缩历史记录检查提示词是否被用户输入注入覆盖生成内容长度不够max_tokens设置过小、模型提前收敛调大max_tokens检查是否在提示词里说过“回答简短”输出格式不稳定该输出的JSON经常破模型生成时带有多余文本、温度过高温度降到0.2以下在提示词中要求“只输出JSON不要解释”用正则或校验逻辑兜底本地部署后推理很慢未启用GPU加速、量化精度过高、并发串行检查是否安装了对应GPU的onnxruntime版本开float16或int8量化排查是否有batch推理的优化空间多次请求后内存爆掉未释放历史上下文、推理进程持续占用显存检查是否每轮对话都把全量历史送进去本地推理建议定时重启进程做显存清理6.2 性能、成本和幻觉三大实战优化心得性能优化上除了硬件升级最容易见效的是请求合并。如果业务里有20条相似的文本要分类不要一条一条发拼成一个batch请求吞吐量直接翻倍其次是模型蒸馏与量化我用int8量化后的7B模型跑过测试速度提升40%精度损失不到2%在内部问答场景完全可接受。成本优化上能走开源本地模型就不走API能用小模型就不上大模型能缓存就绝不重复计算。比如同一份合同的不同员工发起了三次解析如果按文档哈希缓存结果三分之二的钱就省下来了。幻觉问题是最难根治的我的经验是三道防线第一道提示词约束明确“不要编造”第二道给事实核查让模型先回答再用检索回来的片段自查一次第三道人工抽检对高风险输出人工过一遍。艰险是没法100%消除的能做的只有降低发生概率和影响范围。6.3 安全合规与避坑指南使用LLM时有几个底线我在任何项目里都会反复强调。第一不要拿生产Key去做测试临时Key用完就删不要把API密钥提交到代码仓库用环境变量或密钥管理服务。第二面向公众场景的输出建议做一层内容过滤不把未经审核的模型输出直接公开展示尤其是垂直行业场景。第三涉及个人信息、商业秘密、医疗财务等敏感数据时优先私有化方案不要心存侥幸把数据传到外部API。第四对外提供服务前务必检查数据授权范围、合规条款和行业规定这不是小题大做而是对用户、对客户、也是对自己负责。7. 最后分享几条属于我自己的“LLM使用经验”全文说的都是“方法”这里我想用更直白的话收个尾。第一条经验是“不会用”多半是因为“不理解”而不是“不会调”。我见过太多人拿着各种花式提示词模板直接抄抄完了效果不好便开始“是不是模型不行”。大多数情况下问题恰恰出在他没理解模型的运行机制它就是个概率续写器不是搜索引擎也不是数据库。你把它当续写器来设计交互、约束行为方法自然就对了。记住处处碰壁时先回去补概念往往比继续调参数更有用。第二条经验跟具体工具相关把可复用的部分沉淀下来。比如一个稳定的提示词模板、一套标准化的评测集、一个调好的RAG切分策略这些才是你真正的项目资产。模型一年换三代但你的方法论可以持续复用。我现在做新项目时第一件事不是选模型而是把过去沉淀下来的评测集拿出来快速试几款新模型谁过线用谁两三天就能定下来。这个习惯替我省了大量时间。第三条是最实际的技术在迭代你在业务里沉淀的“判断力”才是真正稳的东西。某个项目里我当时选了某模型后来新模型更强更便宜我很快迁移过去业务关键要素没变。真正值钱的不是会用某一款模型而是知道“什么任务适合交给LLM”“怎么判断它的输出好不好”“出问题了往哪几个方向查”。这些能力才是你随着经验积累起来的、别人抄不走的竞争力。试着先从一个最小的场景开始把上面的链路走通一遍再用自己的数据积累经验值你会比只看教程的人走得更远。 LLM使用从入门到实战：原理、选型、提示词与RAG全解析
1. 先把概念揉碎LLM到底是什么怎么才算“会用”先说实话我接触过的开发者里能从“调通API”到“真正用好LLM”之间往往隔着一道看不见的坎。这个坎不在于会不会写代码而在于有没有把几个底层概念吃透。LLM的使用方法说白了不是“记住几个接口、会写几个提示词”这么简单而是一整套从模型理解、场景拆解到工程落地的思维转换。1.1 LLM本质是下一个token预测器不是搜索引擎大语言模型LLM的核心是在给定上文的情况下预测下一个最可能出现的词元token。它本质上是一个条件概率分布估计器——你给它“今天天气真”它就会按概率输出“好”“棒”“不错”等候选。我见过很多人把它当搜索引擎用上来就问“中国有多少人口”模型答了个数字就觉得它在“检索”。其实它是在“续写”。这个区别决定了使用姿势完全不同搜索引擎靠索引命中LLM靠模式泛化。所以同一个问题你换个问法、加个上下文、给个示例结果可能天差地别。至于“LLM是否属于深度学习”这个问题答案当然是肯定的。LLM是深度学习中自然语言处理方向的集大成者核心架构是Transformer靠海量文本预训练得到语言能力再通过指令微调SFT、人类反馈强化学习RLHF等步骤“学会听话”。理解这个脉络你才知道为什么有些模型“聪明但不好使”有些模型“笨但特别听话”——这就是基座能力和对齐调教之间的博弈。1.2 Token、上下文窗口和Attention机制的“三把钥匙”搞懂LLM绕不开的是token。Token是模型处理文本的最小单位可以是单词、子词甚至单个字符。中文场景尤其要注意一个汉字在不少模型中会被拆成1~2个token1000个汉字往往对应1000~1500个token。API计费、上下文长度、生成速度全部围绕token展开。我之前用某模型跑一批简历解析一篇三千字的简历动不动就吃掉3500个token等反应过来账单已经翻倍了。所以在使用LLM之前先给自己备一个tokenizer工具比如在线tokenizer、huggingface的tokenizers库把输入文本提前量一量这是省钱的第一步。另一个关键概念是上下文窗口就是模型一次能“看到”的最大token数。拿聊天举例如果窗口是8k你的历史对话系统提示词当前问题加起来超过8k最早的内容就被“挤”出去了模型就会“失忆”。我踩过最典型的一个坑多轮对话里塞了一堆长长短短的历史消息表面上模型还在回复实际上前面几轮的关键信息早就被截断了。解决方案很简单定时对历史消息做摘要压缩或者只保留最近N轮。再说那个流传很广的说法——LLM的token三个点是“Key我是谁、Query我在找什么、Value我能提供什么”。这句话不是在玩概念它直接对应Transformer注意力机制里的QQuery、KKey、VValue三个矩阵。用人话说就是模型在处理某个词时会拿着“我的问题”Query去和文本中其他词携带的“身份标识”Key做对比看哪些词和我相关然后根据相关度去提取它们携带的“实际内容”Value。比如处理“苹果把库克任命为CEO”这句话模型遇到“库克”时会让它和“苹果”“任命”“CEO”这些词的Key做匹配相关度高就加大权重最终融合出的结果就包含了“库克是苹果公司CEO”这层语义。这三个点的比喻本质是在帮我们理解注意力机制里三个角色的分工。明白这个你就知道为什么LLM能处理长距离依赖关系也知道为什么上下文被截断会让模型“抓瞎”——因为相关内容根本不在它的注意力范围内了。1.3 公开榜单怎么用Open LLM Leaderboard只能当参考热词里提到了Open LLM Leaderboard这类公开榜单。很多朋友一上来就盯着排行榜选模型觉得排前面的就是最好的。但我实际用下来榜单分数和真实业务表现之间往往隔着一条鸿沟。排行榜测的多是通用知识、推理能力、指令遵循而你的场景可能是合同审查、简历筛选、客服问答、SQL生成通用分高不代表在这些垂直场景里就好使。我自己有个习惯拿到一个新模型不急着上生产先拿真实业务里的50~100条样本跑一遍人工看结果和现有模型做对比。这个“小样本人工评测”比看任何榜单都有说服力。榜单的真正价值在于帮你圈定候选池筛掉明显不行的模型但不能替你拍板。2. 手把手走通选型与接入从模型选择到API调用的完整链路概念清楚了就要解决最现实的问题我到底该用哪个模型怎么接入用什么工具管理这些接入。这一步是LLM使用方法里最容易卡住新人的地方因为可选的东西太多了反而不知道该选什么。2.1 先问自己三个问题再选模型第一我的场景是“要知识深度”还是“要执行指令”如果是要做行业问答、知识库检索、内容总结那选通用能力强的基座模型比如Qwen系列、DeepSeek系列如果是要让模型调用工具、写代码、操作外部系统那选指令遵循能力强的模型比如Claude系列、GLM系列。第二我的数据隐私要求有多高如果只是内部工具、非敏感场景直接用第三方API最省事如果涉及客户隐私、商业机密就要考虑私有化部署或使用合规的私有化API。第三我的预算成本控制在什么范围这个要算综合成本包括API调用费开发人力维护成本不是哪个便宜选哪个而是“性价比最优”。我自己做过一个OCR文档抽取项目最初选了当时榜单第一的大模型效果好但贵得离谱后来换成中等开源模型加了一点提示词优化准确率只掉了1.5%成本却降到了原来的十分之一。这种取舍不实际跑一遍根本没法拍板。2.2 第三方API网关与模型切换工具用CC Switch接入DeepSeek、Qwen、GLM现在国内外的模型API其实已经非常成熟DeepSeek、通义千问Qwen、智谱GLM都有官方API但实际开发中你会遇到一个很现实的问题今天你觉得Qwen好明天可能DeepSeek出了新版本效果更优后天客户指定要用GLM。如果每个模型都在代码里硬编码一套接口改来改去会非常痛苦。这时候就需要一个统一的“模型接入层”。我目前比较推荐的做法是使用第三方API网关或模型切换工具比如热词里提到的CC Switch。这类工具的核心价值是统一一套接口规范底层去适配不同厂商的API让你在代码里只对接一个地址通过配置切换模型供应商。我用CC Switch接入DeepSeek、Qwen、GLM的实际操作大致是三步。第一步在工具里配置各个模型的API Key和Endpoint第二步设置统一的基础URL比如本地代理地址让应用只认这一个地址第三步在请求参数里指定具体模型名用完随时切换。这样做的最大好处有两个一是避免厂商锁定想换模型只是改配置的事不用动代码二是方便对比评测同样的提示词切到不同模型上跑一跑效果高下立现。接入第三方API时还有几个非常实操的要点。第一版本号一定要锁定不要在代码里直接写默认版本一旦厂商把默认版本升级你的应用可能悄悄被换到底层模型行为就变了。第二兜底逻辑必须做API超时、限流、返回格式异常都要有重试和降级方案。第三流式输出streaming体验好但调试难如果首次接入建议先关流式把逻辑跑通再加流式优化体验。第四网络超时和连接池要设置好尤其是并发高的场景Python的openai库默认超时很多时候不够用生产环境建议把timeout调大同时用连接池控制并发防止打爆对端。这些细节看着小恰恰是“会用”和“不会用”的分水岭。2.3 本地部署ONNX Runtime跑LLM的保姆级流程很多场景下数据不能出内网必须本地部署。这里就牵涉到热词里出现的“ONNX部署LLM模型”。ONNX Runtime是微软开源的推理引擎优势在于跨平台、支持CPU/GPU异构、针对推理做了很多优化。我把一个开源模型导出为ONNX格式并本地跑起来的流程简单梳理一下。首先准备工作。你需要一台有足够内存的机器CPU部署的话16G内存起步GPU部署建议显存至少8G。Python环境准备好安装onnxruntime、transformers、torch这几个基础库。然后获取模型。从HuggingFace或ModelScope找一个开源模型比如Qwen2.5系列、Llama系列等用transformers加载后导出ONNX。导出时核心是要指定opset版本和quantization策略。我一般推荐先用float16精度导出模型体积小一半推理速度也更快只有在精度损失不可接受时才换float32。然后你就可以用ONNX Runtime进行推理了。核心代码逻辑大致是import onnxruntime as ort from transformers import AutoTokenizer # 加载tokenizer tokenizer AutoTokenizer.from_pretrained(qwen/Qwen2.5-1.5B-Instruct) # 创建ONNX推理会话 session ort.InferenceSession(model_fp16.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider]) text 帮我写一个Python读取CSV文件的示例 messages [{role: user, content: text}] inputs tokenizer.apply_chat_template(messages, tokenizeTrue, return_dictTrue) # 转为ONNX Runtime期望的numpy格式 ort_inputs {k: v.cpu().numpy() if hasattr(v, cpu) else v for k, v in inputs.items()} outputs session.run(None, ort_inputs) # 从输出中解码生成结果 response tokenizer.decode(outputs[0][0], skip_special_tokensTrue) print(response)这里的细节在于apply_chat_template它负责把对话格式转成模型期望的指令格式每家模型要求的模板不一样比如Qwen用的是|im_start|user之类的标记Llama用的是[INST]标记。用错模板的典型症状是模型答非所问或者疯狂重复标点。ONNX部署最大的优势是资源占用可控、推理速度稳定缺点是需要处理模型转换和优化调试成本比直接用API高。它的适用场景非常明确内网离线部署、对数据安全要求极高的行业或者要做私有化交付的甲方项目。2.4 说清楚LLM网关到底解决什么问题LLM网关这个概念这几年特别火它本质上是一个“大模型应用入口”位于应用和模型之间负责请求转发、身份认证、限流、熔断、日志采集和成本统计。它和“模型切换工具”的区别在于切换工具解决“多模型随手换”网关解决“面向多团队、多应用、多模型时怎么统一治理”的问题。在团队开发场景里核心价值非常明显。比如你们团队有5个应用每个应用都用好几款模型如果没有网关每个人各自配置API Key月底账单对不上出了问题也不知道是哪个应用调了哪个模型导致的。有了网关统一入口、统一鉴权还能按部门/应用维度统计token消耗做精细化的成本管理。网关还可以做缓存策略比如同样的请求短时间内若有人问过就直接返回缓存结果能省不少成本。我见过做得好的网关方案直接把某团队的月成本压掉30%以上。所以我的建议是个人开发用“切换工具”就够团队协同、生产环境必须上“网关”这套治理思路。3. 提示词工程实战如何把模型调成“老员工”而不是“新人”模型选定、接口打通接下来决定体验的就是提示词功底。同样是调一个API有人拿回来的结果能用有人拿回来的结果像一坨没组织好的口语区别全在提示词。提示词工程不是写作文是有方法论的。3.1 结构化提示词框架像写开发需求文档一样写提示词我的提示词模板可以分享给大家经过多次打磨后我总结了一个“五段式”结构非常稳定好用适合绝大多数业务场景。角色定义明确让模型扮演什么角色。比如“你是一名有10年经验的Java架构师”而不是直接说“帮我写代码”。任务描述清晰说明要做什么。这里必须具体避免“帮我分析一下”这种模糊表达改成“请提取这份合同中的付款条款、违约金比例、最长履约期限”。输入数据把待处理的内容明确框起来用分隔符如输入和/输入告诉模型哪些是数据防止它把数据混入指令。输出要求规定输出格式比如“输出为JSON数组包含字段name和value”这能极大提升结果的结构化程度。边界与说明告诉模型什么不要做比如“不要推测不存在的信息”“如果原文没有相关内容输出空字符串”。举一个实际例子我用GPT-4级别模型做会议纪要时提示词是你是总裁办助理擅长提炼会议决策。请根据以下会议记录输出三部分内容——“决策事项”“责任人”“截止时间”。会议记录我用记录.../记录框起来。这样出来的结果基本不用改直接能填进周报。而如果直接问“请帮我总结一下这个会议”模型给的就是一堆废话文学。3.2 角色设定和Few-shot让模型“入戏”的两种武器角色设定System Prompt的核心原理是给模型一个稳定的“出发状态”。做过实验的朋友都知道同样的任务加上“你是一名资深律师”和只写“帮我审合同”输出的专业深度完全两回事。原因在于角色设定把模型的输出分布拉向了特定风格和知识模式这和模型训练时学到的各种文体模式有关。当然角色不是瞎吹你要给自己设计的角色配备足够的“资料”专业的术语、行业的习惯、输出风格偏好都要写清楚。Few-shot少样本示例则更进一步直接给模型看几个“标准答案示例”。它在处理格式类任务时几乎是无敌的。比如我要从发票信息里抽取字段除了规则说明我还会给它两个输入输出对样例。它看到样例后就明白字段抽取的边界在哪里什么该抽什么不该抽。Few-shot的使用有一个要点示例一定要有代表性最好正例、反例、边界例都有。比如我让模型判断文本情感我会给三个示例一个明显正面一个明显负面一个含含糊糊。这个“含糊”的示例往往决定了模型后续遇到边界case时是偏向保守还是激进。3.3 温度、Top-p这些参数到底怎么调热词里提到“llm的token三个点”那是模型内部机制真正影响输出风格的是我们在外部可以调控的推理参数。最常遇到的是temperature温度和top_p核采样。我打个比方每个候选token都带着一个概率temperature就是把概率分布拉平或拉尖。温度越高分布越平输出越随机、越有创意温度越低输出越确定、越保守。0到1之间一般场景我会这样设0.0~0.3代码生成、抽取、格式化、OCR修正等追求准确稳定的任务0.4~0.7客服回复、内容总结、写作辅助等需要自然语言但不容许太跑偏的任务0.8~1.2头脑风暴、创意写作、文案灵感等需要发散的任务。top_p是另一种控制多样性的方式取值0到1代表“只从累计概率达到p的最小token集合里采样”。实践中top_p和temperature不要同时猛调一般固定一个动另一个。我个人的使用习惯是生产环境固定temperature0.2, top_p0.9既稳定又有一定的容错空间创意场景固定top_p0.95再微调温度来改变发散程度。另外还有一个容易忽略的参数是max_tokens最大生成长度很多AI生成中断、答案不完整其实不是模型不行而是你把输出长度限制得太短了。估算一下一个汉字约等于1~2个token要给模型留够“发挥空间”。4. 进阶玩法拆解RAG、GraphRAG和LLM as Judge基础能力打通后很多人的需求会走向“让模型更懂我的私有数据”和“让模型替我做评估”。这就绕不开RAG、GraphRAG以及LLM as Judge这些进阶玩法。4.1 RAG给LLM接上外挂知识库RAG检索增强生成的核心思路很简单你在让模型回答问题前先从自己的知识库里检索相关片段把这些片段作为上下文塞给模型它基于这些内容生成回答。这样做的价值显而易见第一模型不再依赖训练时固有知识可以回答自己的私有业务问题第二可以通过更新知识库来更新答案不用重新训练模型第三答案可以溯源到具体文档方便审计。RAG的实际落地流程一般包括四个环节。文档清洗把PDF、Word、Excel转成纯文本去掉页眉页脚、水印、乱码文本切分按语义或固定长度切成chunk我实测下来中文场景500~800字一截比较稳妥太短了语义不全太长了检索噪音多向量化入库用embedding模型把每个chunk变成向量存入向量数据库检索问答用户提问时把问题向量化在库里做相似度检索取Top-K相关片段组装提示词后交给LLM生成答案。这个链路看着简单但每个环节都有坑切分时把一段完整的话拦腰截断、检索时召回不相关片段、向量模型和知识域不匹配等都会导致回答质量崩掉。关于RAG和LLM Wiki的关系可以这样理解LLM Wiki是知识库的内容源RAG是利用这些内容做问答的手段两者配合才是完整的知识服务方案。4.2 GraphRAG比普通RAG多出来的关系推理能力GraphRAG是这两年出现的RAG升级版核心是在纯文本切分之外额外构建一张知识图谱。普通RAG只能做“基于相似度的字面检索”遇到需要多跳推理的问题比如“A公司的母公司是BB的竞争对手是C那么A和C有关系吗”普通RAG基本无能为力因为它检索到的片段之间没有关联GraphRAG通过实体抽取和关系抽取把文档中的核心概念连接成图检索时不仅做相似度匹配还会沿着图结构扩散把相关的实体、关系一起捞回来。GraphRAG的项目落地比普通RAG重很多需要额外做实体识别、关系抽取、图谱存储和查询。我的建议是如果你的场景是文献综述、行业研究报告、复杂企业关系分析这类“关系密集”的任务GraphRAG值得投入如果只是FAQ问答、政策条款检索普通RAG就够不要为了追新把架构搞复杂。我自己曾经在项目里强行上GraphRAG结果光实体识别模型选型和调优就搞了一周后来发现用户真正的高频问题用普通RAG就能解决。这是血的教训——先看需求再选技术。4.3 LLM as Judge让模型当“裁判”靠谱吗LLM as Judge就是用大模型来评估大模型的输出质量。传统评估方式是人工打分慢且贵自动评估指标如BLEU、ROUGE又太机械抓不住“内容合理”“逻辑连贯”这类高维质量。所以业界开始用大模型当裁判给被测模型的回答打分或排序。实际操作中一种常见的做法是构造一个“裁判提示词”把任务描述、候选回答、评分标准一起发给裁判模型让它打分并给出理由。这里有个关键经验裁判模型本身要有足够强的能力通常要选择同级别或更高级别的模型否则会出现“差模型评更好模型”的尴尬评分标准尽量用Rubric式的细则把“5分信息完整无虚构格式正确”这类标准写清楚别写“请打分”一句话了事还要警惕位置偏差多个候选放在一起时模型容易偏向第一个或最后一个可以通过随机调换顺序多次评测取均值来缓解。LLM as Judge虽然不完美但只要评测标准设计得当它的效率和一致性远远超过人工抽检。现在我自己的项目里AI生成结果的质量回归测试基本都用这种方式人工只保留抽查环节。5. 实操记录从0到1实现一个“文档问答助手”的完整过程前面讲了这么多概念、方法、经验这一节我用自己做过的一个真实小项目把整个链条串起来——做一个“企业制度文档问答助手”。这个项目麻雀虽小但五脏俱全涵盖了场景定义、模型选型、提示词设计、接口接入、RAG落地和问题排查的全部环节。5.1 场景定义、方案选型与成本测算背景是我给一家中小型公司做内部工具员工经常要在上百份制度文档里搜某条规定传统搜索体验很差。需求是员工输入一句大白话系统能给出相关制度依据和明确答复。方案选型的关键判断点有几个。第一数据敏感性中等内部制度不算绝密但不能随便上公网最终选了私有化的开源模型方案。第二模型选型对比了Qwen和GLM系列最终选了Qwen2.5-7B-Instruct量化版因为它在通用知识和中文指令遵循上表现均衡且在本地CPU/GPU混合环境能跑得动。第三架构确定为大致的“文档解析→向量化→RAG检索→LLM生成”没有上GraphRAG理由很简单制度问答主要是单点事实查询不需要多跳推理。成本测算我做了个表供大家参考项目开源自建服务器GPU租赁约800元/月embedding模型免费开源向量模型LLM推理资源包含在服务器内维护人力约0.5人天/月对比第三方API成本按当月调用量估算约省30%~50%5.2 提示词设计从“随便问问”到“标准交付”我最终使用的系统提示词长这样你是某公司的制度问答助手。用户会向你提问公司制度相关内容。 回答要求 1. 只能依据检索到的制度片段回答不得编造制度内容 2. 如果检索片段不足以回答直接说“根据现有制度文档暂未找到相关内容” 3. 回答需注明出处格式为“根据《XX制度》第X章第X条” 4. 用户问题可能很口语化你要先理解意图再匹配制度条文 5. 回答控制在200字以内先结论后依据。这里有几个设计心得。第一“不得不编造”是制度类问答最关键的必须写死第二“先结论后依据”符合业务阅读习惯第三“告知未找到”是为了减少模型硬凑答案的幻觉问题。我还配合做了几个few-shot示例把“工龄满一年可以休几天年假”这种高频问题的最优答法给模型看过一遍实际效果提升非常明显。5.3 开发联调与效果验证联调阶段我把它分成三层。第一层纯LLM接口验证直接调模型测试它是否理解角色和输出要求。这里最容易出的问题就是模型把别的制度内容也“带”进来乱答。第二层RAG检索质量验证拿50个真实问题跑一遍检索统计Top-5召回里有没有正确答案如果召回率低于80%就要调整切分大小或改embedding模型。第三层端到端验证用户问题走完“检索→组装→生成→溯源”全链路重点检查回答有没有涉及检索片段之外的内容。整个验证过程花了大概3天我把50个问题的验证结果做成表格逐条记录是哪一环出的问题——模型问题改提示词检索问题改切分源头问题改文档清洗规则。这个过程特别重要因为一旦问题定性错了后面所有优化都是白费力气。5.4 全流程走通的几个通用要点第一日志要全覆盖。从用户请求到检索结果到最终答案每一步都要有日志否则出了问题根本没法回溯。我吃过一次亏线上用户反映答非所问我查了半天才发现是embedding模型服务挂掉了检索结果全为空。幸好有日志不然只能大海捞针。第二提示词版本管理。很多人改提示词是直接在代码里改改完不记录结果效果变好了也说不清是哪里起了作用。我的做法是把提示词模板放到独立配置文件里配Git版本管理每次改动都留commit信息。第三灰度发布。不要一把全量切新模型先让5%的流量跑一跑对比效果再推广。第四监控告警要设置服务挂了、响应变慢、token消耗异常都要有告警。它不是你写了就完事的东西而是保证你“敢睡个安稳觉”的基础设施。6. 常见问题与排查实录把踩过的坑一次说清楚最后分享一些高频问题和排查经验这些几乎是我在帮别人看LLM项目时一定会被问到的内容。6.1 高频报错与排查思路速查表报错/问题常见原因排查与解决LLM request failed: provider rejected the request schema or tool payload发送给模型的工具调用参数格式与模型不完全兼容或模型不支持该工具类型检查工具定义是否遵循模型要求的JSON Schema格式先用最小化工具测试看看是否把复杂嵌套参数搞复杂了简化工具结构再试回答前后矛盾、答非所问上下文窗口被截断、系统提示词被后续内容淹没、检索内容噪音太大检查上下文占用率必要时压缩历史记录检查提示词是否被用户输入注入覆盖生成内容长度不够max_tokens设置过小、模型提前收敛调大max_tokens检查是否在提示词里说过“回答简短”输出格式不稳定该输出的JSON经常破模型生成时带有多余文本、温度过高温度降到0.2以下在提示词中要求“只输出JSON不要解释”用正则或校验逻辑兜底本地部署后推理很慢未启用GPU加速、量化精度过高、并发串行检查是否安装了对应GPU的onnxruntime版本开float16或int8量化排查是否有batch推理的优化空间多次请求后内存爆掉未释放历史上下文、推理进程持续占用显存检查是否每轮对话都把全量历史送进去本地推理建议定时重启进程做显存清理6.2 性能、成本和幻觉三大实战优化心得性能优化上除了硬件升级最容易见效的是请求合并。如果业务里有20条相似的文本要分类不要一条一条发拼成一个batch请求吞吐量直接翻倍其次是模型蒸馏与量化我用int8量化后的7B模型跑过测试速度提升40%精度损失不到2%在内部问答场景完全可接受。成本优化上能走开源本地模型就不走API能用小模型就不上大模型能缓存就绝不重复计算。比如同一份合同的不同员工发起了三次解析如果按文档哈希缓存结果三分之二的钱就省下来了。幻觉问题是最难根治的我的经验是三道防线第一道提示词约束明确“不要编造”第二道给事实核查让模型先回答再用检索回来的片段自查一次第三道人工抽检对高风险输出人工过一遍。艰险是没法100%消除的能做的只有降低发生概率和影响范围。6.3 安全合规与避坑指南使用LLM时有几个底线我在任何项目里都会反复强调。第一不要拿生产Key去做测试临时Key用完就删不要把API密钥提交到代码仓库用环境变量或密钥管理服务。第二面向公众场景的输出建议做一层内容过滤不把未经审核的模型输出直接公开展示尤其是垂直行业场景。第三涉及个人信息、商业秘密、医疗财务等敏感数据时优先私有化方案不要心存侥幸把数据传到外部API。第四对外提供服务前务必检查数据授权范围、合规条款和行业规定这不是小题大做而是对用户、对客户、也是对自己负责。7. 最后分享几条属于我自己的“LLM使用经验”全文说的都是“方法”这里我想用更直白的话收个尾。第一条经验是“不会用”多半是因为“不理解”而不是“不会调”。我见过太多人拿着各种花式提示词模板直接抄抄完了效果不好便开始“是不是模型不行”。大多数情况下问题恰恰出在他没理解模型的运行机制它就是个概率续写器不是搜索引擎也不是数据库。你把它当续写器来设计交互、约束行为方法自然就对了。记住处处碰壁时先回去补概念往往比继续调参数更有用。第二条经验跟具体工具相关把可复用的部分沉淀下来。比如一个稳定的提示词模板、一套标准化的评测集、一个调好的RAG切分策略这些才是你真正的项目资产。模型一年换三代但你的方法论可以持续复用。我现在做新项目时第一件事不是选模型而是把过去沉淀下来的评测集拿出来快速试几款新模型谁过线用谁两三天就能定下来。这个习惯替我省了大量时间。第三条是最实际的技术在迭代你在业务里沉淀的“判断力”才是真正稳的东西。某个项目里我当时选了某模型后来新模型更强更便宜我很快迁移过去业务关键要素没变。真正值钱的不是会用某一款模型而是知道“什么任务适合交给LLM”“怎么判断它的输出好不好”“出问题了往哪几个方向查”。这些能力才是你随着经验积累起来的、别人抄不走的竞争力。试着先从一个最小的场景开始把上面的链路走通一遍再用自己的数据积累经验值你会比只看教程的人走得更远。