这半年来一直在折腾大语言模型的应用开发从最开始对着API文档发懵到后来能独立搭出完整的应用期间踩了不少坑也积累了一些实打实的经验。这次开这个系列就是想把这些实践过程中的思路、代码、教训都沉淀下来。既然是第一讲就不聊太深的东西先解决“从哪下手”的问题——搞明白LLM应用开发到底在开发什么把环境、概念、工具链这些地基打好再带大家从头走通一个最简单的完整Demo。看完这一篇你应该能对LLM应用开发有个整体认知并且自己跑通第一个程序。1. 整体思路LLM应用开发到底在开发什么1.1 把大模型当“实习生”而不是“计算器”很多刚接触LLM开发的人第一个误区就是把大模型当成一个超级计算器以为给它一个问题它就能像传统程序那样给你确定性的输出。实际完全不是这么回事。我刚入坑的时候用一个大模型API做情感分析同一句话跑了十遍两次结果是正面五次是负面剩下三次直接给我返回了“这句话情感复杂需要结合上下文判断”——这就是典型的不理解模型工作机制导致的问题。我后来琢磨出一个比较贴切的类比跟大模型打交道本质上是在管理一个知识渊博但没什么常识的实习生。这个实习生读过海量的书知道古今中外几乎所有知识但他不懂你的业务规则不知道你想要什么格式的答案甚至有时候会为了让你满意而“编造”内容。你的核心工作就是通过写清楚的指令提示词、给足够的上下文对话历史、设定明确的边界参数限制让这个聪明但毛躁的实习生干出你想要的活。这个思维方式转变很重要。一旦你接受了“模型是实习生”这个设定很多设计决策就顺理成章了为什么需要做提示工程因为实习生听不太懂模糊的指令需要你把话说明白。为什么要做输出校验因为实习生怕做错有时候会“贴心地”撒谎。为什么要把业务逻辑拆成模块而不是全塞给模型因为模型的输出不稳定你不能把核心业务的命脉押在不确定性上。1.2 应用开发的三种主流架构形态LLM应用开发虽然花样百出但归根结底架构形态就三种理解清楚它们的区别你就知道该在什么场景下选择什么方案。第一种是“直连模式”这也是最简单的形态。你的应用直接把用户输入拼进提示词发给大模型拿到结果返回。适合做聊天机器人、简单的文本润色、翻译这类对答案准确性要求不高的场景。优点是开发快一个请求就能搞定成本低缺点是什么业务逻辑都塞在提示词里一旦规则复杂提示词就变得像条条框框的法规文件维护起来很痛苦。第二种是“RAG模式检索增强生成”也是目前企业应用落地最多的一种形态。核心思路是“先查资料再写答案”。比如你要做个公司内部的知识库问答机器人模型并不知道你们公司上季度的销售数据这时候你先把用户问题拿去文档库里检索找到相关的几段内容再把这些内容和用户问题拼在一起发给模型模型就能基于你给的资料来回答了。这种模式解决了模型“知识滞后”和“胡编乱造”的问题是目前落地性价比最高的方案。第三种是“Agent模式”也就是让模型具备调用工具的能力。模型本身不能执行代码、不能访问数据库、不能调用第三方API但你可以给它定义好一批“工具”也就是函数模型在回答问题时会自动判断需要调用哪个工具来获取信息。比如用户问“帮我查一下这个订单的物流状态”模型会先从对话里提取订单号然后调用你提供的物流查询函数拿到物流信息后再组织语言回答用户。这是最接近“智能助理”的开发模式但也最难掌控因为模型决定调用哪个工具的过程本质上是在猜猜错就得靠你设计反馈机制去纠正。2. 核心概念与开发准备踩坑后的反思2.1 关于Token嵌入与上下文窗口你需要真的理解透做LLM应用开发有几个概念绕不开但网上的教程大多轻描淡写导致很多人包括我在实践中栽了跟头。第一个是Token嵌入。模型不直接看文字而是把文字切碎成Token令牌再映射成多维向量。不同语言、不同分词器的Token切法不一样英文一般一个单词拆成0.7到1.3个Token中文就更吓人通常一个字就要占用1到2个Token。我测过一段500字的中文产品说明扔给某主流大模型Token消耗量差不多是800到900。这意味着你预估成本的时候不能拿字数去套得按Token算。如果没这个概念你很可能在账单出来的时候傻眼。第二个是上下文窗口。这个参数指的是模型一次能处理的Token总量包括输入和输出。你输入的所有内容加上模型要生成的输出必须塞进这个窗口里。听起来简单但实际开发中容易踩坑的地方在于对话历史会越积越多。用户跟你的机器人聊了二十轮之后前面所有对话都作为上下文发给模型很快窗口就爆了。我见过一个事故线上聊天机器人在第30轮对话时突然报错排查了半天就是上下文窗口超限。解决方案一般有两种一种是做滑动窗口只保留最近几轮对话另一种是做摘要压缩把前面的对话用模型总结成一段摘要替换掉完整历史。这里有个实操参数要跟大家分享。假设你用的是基础模型上下文窗口是4K即4096个Token你设定最大输出限制是1000个Token那留给输入的空间就是3000个Token。再扣掉系统提示词和对话格式的开销实际能承载的对话轮次可能只有七八轮。我在设计对话类应用时一般会给“一句话简介最近两轮对话”的上下文策略既保证模型有足够的背景信息又不会让Token消耗失控。2.2 温度系数与Top-p采样造出确定性输出的秘诀模型生成的随机性既是它的魅力所在也是应用开发中最令人头疼的地方。好在有参数可以调节——温度系数temperature和Top-p采样核采样这两个参数直接影响输出的稳定程度。温度系数控制的是模型输出服从概率分布时的随机性程度范围一般是0到2。打个比方温度低的时候模型就像一个死板的公务员永远挑最稳妥的词语组合输出稳定但略显枯燥温度高的时候模型像喝了两杯咖啡的创意总监什么词都敢用输出天马行空。我在实际项目中凡是做信息抽取、结构化数据生成、代码补全这类需要高确定性的任务温度直接调到0.1甚至0而做营销文案、故事生成这类创意任务温度会调到0.7以上。Top-p采样解决的则是另一个维度模型在每一步生成下一个Token时会有一个候选词的概率分布。Top-p是设定一个概率阈值只从概率累积到该阈值的候选词里选。比如Top-p0.9意味着模型只会从累积概率达到90%的那批词里挑选其他概率垫底的候选词直接排除能有效去除“杂音”。一个很实用的经验是温度系数和Top-p不要同时调得很激进。我见过有人把温度调到0.9又把Top-p调到0.1结果输出质量极其不稳定。推荐的做法是先固定温度在0.7这是很多模型的默认值把Top-p从1.0逐步调到0.8观察输出质量变化如果还不够稳定再把温度往下降。两个参数都降低输出会过于保守甚至呆板两个都调高输出就会疯狂到没法用。调参的过程本质上是找平衡点可以在开发环境里做批量的输入输出对比找到最适合你业务场景的参数组合。2.3 工具选型与API接入的实际经验现在市面上的大模型API服务商不少选哪家是个学问。我的建议是挑主流大厂和主流开源模型的API接口生态成熟、文档完善、出问题好排查。比较了一圈之后我现在的技术栈是核心生成链路用某个主流大模型的API接口因为它的上下文窗口大中文理解能力强本地跑模型做测试用某个开源模型因为免费、可离线、方便单机调试向量数据库用某个开源的嵌入式向量库适合中小规模场景不需要额外部署服务。配置API接入的时候有几个细节特别值得注意。第一个是API密钥的管理千万别硬编码在代码里然后推到公共仓库我在一个技术社区就见过有人把密钥直接贴在示例代码里被别人刷掉了几千块的额度。正确的做法是用环境变量或者专门的配置管理工具来管理密钥并且在应用启动时做一次密钥有效性检查。第二个是超时设置默认的超时通常比较保守但大模型接口的响应时间波动很大短则几百毫秒长则几十秒如果设置太短会频繁报错太长又拖垮用户体验。我的经验是普通对话场景设置连接超时10秒、读超时60秒批量处理场景可以放宽到120秒。第三个是重试机制网络抖动和接口限流都会导致请求失败必须做指数退避重试就是第一次失败后等1秒重试第二次等2秒第三次等4秒最多重试3次。3. 首次端到端实践搭一个能跑通的最小应用3.1 环境准备与基础配置先说一下本次实践需要准备的东西。我用的是Python 3.10版本3.8以下的版本对最新的SDK支持不好建议至少3.9开发环境是VS Code包管理工具是pip。如果你用的是conda也完全可以核心就是别让依赖库互相打架。开始之前先创建一个项目目录并初始化虚拟环境mkdir llm-practice-01 cd llm-practice-01 python3 -m venv venv source venv/bin/activate # Windows下是 venv\Scripts\activate接着安装必要依赖pip install openai python-dotenv这里简单解释一下为什么用openai这个包。虽然不同服务商的API不完全一样但绝大多数都兼容OpenAI的接口格式用这个包可以一套代码对接多家服务商只需要改base_url和api_key就行。配置环境变量的时候我习惯在项目根目录建一个.env文件用python-dotenv加载# .env LLM_API_KEY你的密钥 LLM_BASE_URLhttps://你的服务商地址 LLM_MODEL_NAME你的模型标识然后写一个最基础的调用Demo感受一下从发送请求到拿到回复的完整链路import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) response client.chat.completions.create( modelos.getenv(LLM_MODEL_NAME), messages[ {role: system, content: 你是一个乐于助人的AI助手。}, {role: user, content: 用一句话介绍你自己。} ], temperature0.7, ) print(response.choices[0].message.content)跑通这段代码你就完成了LLM应用开发的第一步——建立客户端连接、发送对话消息、解析模型回复。这个流程看似简单但它是一切复杂应用的地基。3.2 打造一个实用工具智能会议纪要生成器Demo跑通之后光会调用API还不够我得带大家做一个稍微有点实际意义的小工具。这个例子的目标是输入一段会议录音转写的原始文字输出一份结构化的会议纪要包含议题、讨论要点、结论和待办事项四个部分。一开始我天真地以为直接把会议原始文字扔给模型告诉它“整理成会议纪要”就行了。第一次测试模型输出的结果倒也没错但格式五花八门有时候用表格有时候用列表待办事项和讨论要点混在一起分不清而且经常遗漏原始文字里的关键信息。问题出在提示词太模糊。经过几轮迭代我总结出一套比较靠谱的做法在系统提示词里给出明确的结构框架和输出规范在用户消息里再强调一遍关键信息。以下是改进后我在用的提示词模板system_prompt 你是一名专业的会议纪要整理助手。请根据用户提供的会议原始记录整理出一份结构清晰的会议纪要。 输出格式要求如下 【会议议题】 - 列出本次会议讨论的主要议题 【讨论要点】 - 每个议题下用简洁的语言概括讨论过程中提到的关键观点、数据、分歧 【结论】 - 总结每个议题最终达成的结论或共识 【待办事项】 - 列出需要跟进的事项每条包含负责人和完成时限如果原记录中提到了的话 - 格式【事项】负责人xxx / 时限xx 严格注意 1. 只能基于会议记录中的内容进行整理不得编造未提到的信息 2. 如果原记录中没有提到负责人的事项写“暂未明确” 3. 保持语言简洁每条要点控制在50字以内 这个模板里有个小细节加粗了“只能基于会议记录中的内容进行整理不得编造未提到的信息”这是吃过亏之后的教训。第一次跑的时候模型在“待办事项”里一本正经地写“需在一周内完成市场调研报告负责人未在纪要中明确”——后半句倒是没编但前半句里的“一周”“市场调研报告”完全不存在于我的原始会议记录里这就是典型的模型幻觉。再补充一个Token计算的经验。会议原始记录一般1000到2000字换算成Token大约800到1500加上系统提示词、输出结构的开销单次请求的Token消耗在2500到4000之间。用标准API接口做这个任务单份会议纪要的成本大概在0.05元左右性价比还是很高的。3.3 从单次调用到批量处理必须处理的两个问题如果你觉得做个单次调用的小工具就算完事了那还差得远。真实业务中往往需要批量处理文件比如一个会议录屏转写出三个小时的访谈记录你不可能把几万字一次性塞进一个请求需要分片处理又比如市场部一天传上来50份产品文档需要分类总结你需要写一个批量任务调度器。批量处理必然面临两个问题。第一个是速率限制Rate Limit。大多数API服务商都会有每分钟请求次数限制和每分钟Token消耗限制。如果不加控制地并发请求很快就会触发限流返回429错误。解决方式是做一个简单的令牌桶限流器。第二个是失败重试。批量任务的每一单请求都可能因为网络波动或服务端超时而失败必须要有排队重试机制。我写过一个非常朴素的批量任务处理器核心逻辑如下import time import json import threading from concurrent.futures import ThreadPoolExecutor, as_completed class RateLimiter: def __init__(self, max_calls_per_minute60): self.interval 60.0 / max_calls_per_minute self.lock threading.Lock() self.last_call_time 0.0 def wait_if_needed(self): with self.lock: now time.time() elapsed now - self.last_call_time if elapsed self.interval: time.sleep(self.interval - elapsed) self.last_call_time time.time() def process_text_batch(text_list, batch_prompt): limiter RateLimiter(max_calls_per_minute45) results [] def process_one(text): limiter.wait_if_needed() try: response client.chat.completions.create( modelos.getenv(LLM_MODEL_NAME), messages[ {role: system, content: batch_prompt}, {role: user, content: text} ], temperature0.2, ) return response.choices[0].message.content except Exception as e: time.sleep(3) return f处理失败:{str(e)} with ThreadPoolExecutor(max_workers4) as executor: futures [executor.submit(process_one, t) for t in text_list] for future in as_completed(futures): results.append(future.result()) return results这里解释几个设计决策。第一为什么限流器要加锁因为多个线程同时在跑如果没有锁两个线程可能同时通过检查然后同时发请求限流就形同虚设了。第二为什么最大并发只有4因为大模型接口是CPU密集型的服务端任务并发太高不仅触发限流还会导致单次响应变慢实测下来4到6个并发通常是性价比最优区间。第三为什么温度系数从0.7降到了0.2因为批量处理会议纪要这类任务稳定性比创造性更重要温度系数调低可以显著减少格式漂移。4. 绕开这些坑LLM开发新手最容易犯的五个错误4.1 提示词里的“角色扮演”并非越详细越好很多人相信一个说法给模型设定一个越详细的角色输出就越精准。实际测试下来不完全对。确实告诉模型“你是某个领域的专家”能提升输出质量但当角色描述长到几百字挤占了有限的上下文窗口时效果反而变差。我之前做一个客服工单分类的功能系统提示词洋洋洒洒写了三百多字从“你是某公司的资深客服专家”到“你拥有十年的客户投诉处理经验”事无巨细。测试结果分类准确率跟只用一句话“将工单按问题类型分类类型包括账号问题、支付问题、物流问题、技术故障、其他”的基线版本没有显著差异。后来我把系统提示词精简到100字以内不仅准确率没降Token消耗还降了三分之一。真实的经验是角色设定的作用是给模型提供一个倾向性框架而不是给它写一篇小传。你只需要说清楚三个维度身份定位你是谁、任务目标你要干什么、输出约束你要给出什么格式的结果。其他性格、语气、从业年限这些信息在大多数任务场景下都是多余的。4.2 把业务规则塞进提示词是一个巨大的陷阱刚开始学LLM开发的时候很自然的思路是什么逻辑都往提示词里写。比如做一个贷款审核助手你可能会在提示词里写“如果申请人的信用分低于600分直接拒绝如果收入低于每月5000元转人工审核”等等。乍一看很合理模型确实能按这些规则来推理。但问题是一旦规则有变你得修改提示词而提示词在同一时间只能由模型从头到尾处理一遍根本没有“部分更新”的概念。更麻烦的是大模型对“条件规则”的执行并不稳定。我做过一个实验给模型设置了五条条件规则让它模拟判断。单独测每条规则准确率都在95%以上但五条规则同时放在一个提示词里的时候整体准确率掉到了82%。原因很可能是规则多了之后模型在长上下文的推理过程中出现了注意力分散。正确做法是规则和判断逻辑尽可能留在代码里让模型只做它擅长的“语义理解”。还是拿贷款审核来说正确设计是先用模型抽取出申请人的关键信息信用分、收入、负债比然后在代码里用if-else做判断判断结果再交给模型生成个性化的通知文案。这种“模型做理解代码做决策”的分工模式是我在大量实践中总结出来的最稳妥的架构。4.3 不要盲目相信模型输出必须有“护栏”模型输出这层不确定性是个可以被优化但不能被消灭的变量。所以不管你用哪种架构都要在模型的输出之后加一道“护栏”。所谓护栏就是一套校验和修正机制用来确保模型的输出不会破坏你的业务流程。我做客服工单分类功能的时候模型的输出必须映射到预设的类型集合里。但模型有时候会用相近的表述比如“付款问题”对应到“支付问题”分类或者输出一个完全不在集合里的“保障服务”。这时候护栏的职责就是做一次映射匹配匹配不了的走默认分支而不是把未知分类的数据直接塞进数据库。护栏的另一个常见用法是JSON格式校验。现在很多应用让模型直接输出结构化JSON但模型偶尔会在JSON里多一个逗号或者少一个引号导致解析失败。我的防线是在解析JSON的代码里包一层异常处理解析失败时重新向模型发一次“修正请求”带上上次的输出和解析错误信息。实测这个策略能把JSON解析成功率从90%提高到99%以上。4.4 处理长文本不截断、不硬拼先切块再召回当需要处理的文本超出上下文窗口时新手的本能反应是截断掉后半段或者把多段文本硬拼在一起一次性发给模型。这两个做法都有问题。硬截断会丢失关键信息就像你让人评价一部电影他却只看了前二十分钟硬拼接则会稀释注意力让模型不知道该重点关注哪部分内容。正确的做法是切块加摘要。把长文本按逻辑段落切成多个块每个块分别用模型做一次局部总结然后将这些局部总结合并后再丢给模型做全局总结。这个思路在需要处理超长文档的场景屡试不爽虽然多花了几次API调用但效果稳得多。切块时有一个我踩过的坑按字符数硬切成固定长度很容易把一段完整的描述拦腰截断导致局部摘要缺失关键信息。更好的做法是按段落边界切分如果单个段落过长再按句子边界二次切分。实际操作中我一般把切块的目标长度设定在800到1200字之间既能保证上下文窗口利用充分又不会因为块太大导致局部摘要质量下降。4.5 测试集必须“脏”别只在理想数据上沾沾自喜我见过太多人包括早期的自己开发LLM应用时测试数据都是精心挑选的“干净”样例。找几个经典问题模型答得漂亮就以为万事大吉了。直到上线用户问了一个带错别字、夹杂口语化表达、还有一半内容无关的问题模型直接傻眼。做LLM应用测试一定要主动往测试集里注入“脏数据”包含错别字的输入、超长输入、完全无关的输入、需要拒绝回答的敏感输入、格式极其混乱的输入。把这些边界情况提前暴露出来你才有可能在开发阶段就把提示词和护栏调好。我建了一个固定的“对抗测试集”每次修改提示词后都跑一遍确保没有引入回归问题。这套流程虽然笨拙但对提升线上稳定性帮助巨大。5. 后续路线与自我提升建议写到这里第一篇实践差不多该收尾了。对于想继续学下去的朋友我建议你按这个顺序往下走先把今天这套最小Demo在自己的环境里跑通改一改温度系数和Top-p感受一下输出质量的变化然后试着把提示词换成你的一个真实场景比如整理你手头的某个项目会议记录最后把数据集扩大跑一个批量任务亲自体会一下限流和重试的必要性。我在这个领域的持续学习方式一个是盯官方文档模型服务商的更新说明里往往藏着新功能和新参数这些新东西往往是提效的利器另一个是把学到的东西写成这种系列的实践笔记写的过程里会逼我把模糊的理解漏洞补齐。我自己写起来才发现一个以为掌握了的概念落到文字和代码里往往能暴露出很多没有想透的细节。下一期我准备聊RAG检索增强的实战落地包括向量化的流程、检索排序的优化以及如何避免检索结果干扰模型判断。如果大家在跑今天这个Demo的过程中遇到问题或者对哪个环节有疑惑欢迎在评论区留言我会挑典型问题在后面几期里展开。