★ FEATURED ARTICLE 第一次听到“大模型开发”的时候我的第一反应是这跟我有什么关系如果你是个零基础的小白程序员想入门大模型开发先听我一句劝你现在缺的不是显卡不是数学而是一套把模型用起来的流程。我做了几年后端日常写业务接口、调数据库、部署服务突然被业务逼着去做一个文档问答机器人才慢慢摸出门道绝大部分项目里你根本不需要训练模型你需要做的是把别人已经训练好的大模型通过API接到你的业务流程里。这篇文章不打算给你灌“AI改变世界”的鸡汤也不搞那种“五分钟精通大模型”的标题党。我会用我自己从零折腾过来的经验把大模型应用的完整链路拆给你看环境怎么搭、API怎么调、提示词怎么写、RAG怎么做、上线前怎么评测、常见的坑怎么绕。适合谁看懂一点Python、没碰过大模型、想尽快做出一个能用的应用的同学。我会尽量让每一步都能直接照着操作同时把背后“为什么这么做”也讲清楚。1. 先别急着写代码搞清楚大模型开发到底在做什么1.1 大模型开发不是训练模型而是“用”模型很多小白听到“大模型开发”四个字第一反应就是训练一个模型需要多少显卡、多少T的数据——然后直接被劝退。实际上行业中说的“大模型开发”绝大多数指的是“基于大模型的应用程序开发”。换句话说模型是别人训练好的你做的事情是调用它、约束它、编排它让它为你的业务服务。我习惯把大模型比作一个能力很强但没经历过你们公司流程的新人。你不用教他怎么说话、怎么写代码那是他预训练阶段已经学会的。你要做的是给他一份清晰的岗位说明System提示词、给他具体的任务User输入、告诉他输出格式和红线然后把他的产出整合到你的系统里。所以真正花时间的部分是什么定义输入输出、清洗和准备数据、设计提示词、处理上下文、写调用代码、评测效果、处理异常。这些事跟传统后端开发的思维方式非常接近不需要你懂反向传播也不需要你会推导注意力机制。你把大模型当成一个黑盒服务去用这是零基础入门最快的一条路。1.2 小白最容易踩的四个认知误区我见过不少第一次接触大模型开发的人上来就被下面这些想法困住白白浪费大量时间。误区一必须懂数学和算法。做应用开发时你调用的是现成接口模型内部怎么计算是黑盒。真到需要微调或研究模型原理那天再回头补数学完全来得及。误区二必须本地部署一个模型。本地部署涉及到硬件成本、环境依赖、推理优化复杂度远高于直接调API。对个人学习和中小业务来说用现成的大模型服务是性价比最高的选择。误区三必须用流行的开发框架才显得专业。框架确实能提升效率但那不是入门必需品。先用最朴素的HTTP请求把链路跑通你才能理解每个环节在干什么框架才不会变成黑魔法。误区四提示词嘛随便写写就行。这是最大的误解。提示词是当前阶段决定应用效果最关键的杠杆。同一个模型、同一份资料提示词写得好不好输出质量可能差得非常远。这四个误区对应的真实情况我在后文都会展开细讲。先记住一个判断标准如果一个环节让你觉得“太难了”大概率是你在用错误的方式去做一件本来不需要那么复杂的事。1.3 你需要具备的基础能力清单说“零基础”也不是真的什么基础都不要。我梳理了一份最低限度的能力清单你对照看看Python基础会定义函数、会用列表和字典、会解析JSON基本够了。字符串和文件处理要能读文档、拼接文本、按分隔符切分内容。HTTP和JSON概念知道POST请求是什么知道返回结果长什么样稍微看一下就能上手。读文档的能力大模型服务商都会给接口文档你能照着文档配置参数就行。这里面没有高数没有线性代数没有机器学习理论。如果你是后端、前端、测试或者运维出身上面这些你大概率都具备。如果完全没写过代码那建议先用一周时间补一下Python基础语法再回来看这篇文章。2. 环境准备与第一个API调用10分钟跑通Hello World2.1 本地开发环境搭建既然要开发第一步是把本地环境收拾利索。我推荐的组合是Python 3.9以上版本 虚拟环境 Jupyter Notebook。虚拟环境一定要养成习惯。你用Python写业务时可能会装各种依赖如果全部装到全局环境里过两个月自己都分不清哪些包是哪个项目的。创建虚拟环境的命令很简单python -m venv my_llm_env source my_llm_env/bin/activate # Windows下是 my_llm_env\Scripts\activate激活之后你在这个环境里装的所有库都只属于当前项目不会污染系统Python。对于大模型开发初期不装任何第三方库也能跑因为HTTP请求用Python自带的库就能实现。后面如果做文档处理再按需安装解析库。Jupyter Notebook是我强烈建议的学习工具。它最大的好处是“一段段执行、随时看结果”。调通API之后你可以直接在单元格里改提示词、看输出不用每次改完都从头运行整个脚本。等代码稳定了再把逻辑迁移到正式的Python脚本或服务里。2.2 消息结构System、User、Assistant第一次调用大模型API之前你必须要理解一个概念大模型不是简单地接收一句话然后返回一句话。主流的对话模型接口接收的通常是一个“消息列表”列表里每条消息带一个角色字段常见的是下面三种。System系统消息相当于岗位说明书。告诉模型它是谁、它需要遵守什么规则、它的回答风格是什么样的。User用户消息你实际想让它处理的任务或者你在对话中提出的问题。Assistant助手消息模型之前回复过的内容。在多轮对话中你需要把对话历史按顺序传回去模型才能保持上下文连贯。这三个角色的区别你可以用餐厅点菜来理解System是餐厅的服务规范User是你点的菜Assistant是后厨已经端上来的菜。服务规范决定了后厨的出餐风格而已经端上来的菜会影响后面是不是继续给你加菜。很多初学者犯的错是把所有内容一股脑塞进User消息里。比如把系统指令也写在User里虽然有时候模型也能听懂但一旦你的任务变复杂混乱的角色划分会让模型不知道哪些是规则、哪些是任务、哪些是示例。规范使用消息结构是让输出稳定的第一步。2.3 写一个可复用的调用函数先不引入任何第三方SDK用Python标准库就能完成第一个调用。我习惯先写一个通用的chat函数把模型名称、消息列表、温度参数传进去返回模型生成的文本。代码类似这样import json import urllib.request API_BASE https://your-endpoint.example.com/v1/chat/completions API_KEY 在这里填你的密钥 MODEL_NAME your-model-name def chat(messages, temperature0.3): payload { model: MODEL_NAME, messages: messages, temperature: temperature } data json.dumps(payload).encode(utf-8) req urllib.request.Request( API_BASE, datadata, headers{ Content-Type: application/json, Authorization: Bearer API_KEY }, methodPOST ) with urllib.request.urlopen(req, timeout60) as resp: result json.loads(resp.read().decode(utf-8)) return result[choices][0][message][content]然后这样调用messages [ {role: system, content: 你是一个乐于助人的助手回答要简洁。}, {role: user, content: 用一句话解释什么是RESTful API。} ] print(chat(messages))这段代码里API_BASE、API_KEY、MODEL_NAME都要替换成你实际拿到的服务信息。不同平台的具体接口地址和返回结构会有差异但大同小异关键是返回的JSON里通常会有一个choices数组数组里每一项的message.content就是模型生成的正文。很多平台把输入和输出都按“token”计费。token可以理解成模型处理文本的最小单元一个中文汉字在多数模型里大约消耗1到2个token英文单词则可能是半个到一个token。你的提示词越长消耗的token越多费用越高。这会在后文成本规划里进一步说明。2.4 先别急着做业务做三个小实验跑通Hello World之后我建议你先别急着写业务逻辑花半小时做三个小实验目的是建立对模型行为的直觉。第一个实验把System里的“回答要简洁”改成“回答要详细先给背景再给结论”用同一个问题问两遍。你会发现模型输出的风格和结构有明显变化。这能让你直观感受到System消息的约束力。第二个实验保持提示词不变把temperature分别设为0、0.3、1.0各跑几次。温度这个参数控制的是模型输出的随机性温度越低输出越确定、越保守温度越高输出越发散、越有创造力但也容易出现胡言乱语。做严谨的知识问答时温度通常调到0.2以下做文案创意时可以调到0.7以上。第三个实验要求模型输出严格的JSON格式比如“请把这段文字的关键词抽取出来以JSON数组返回”。看看在什么温度下格式更稳定。绝大多数实际业务都需要程序解析模型输出如果模型返回一堆“好的这是您的关键词……”这种废话程序解析会非常痛苦。这个实验会帮你在设计提示词时更加重视“输出结构约束”。做完这三个实验你基本就理解了大模型API的脾气。这时候再进入真实业务你会从容很多。3. 拿到一个需求先想清楚这四件事3.1 判断需求类型重对话还是重检索很多人拿到需求就急着写代码我的建议是先坐住十分钟把需求揉碎了问清楚。大模型应用需求大致可以分成三类。第一类是纯对话/生成类比如智能客服闲聊、文案辅助写作、头脑风暴助手。这类需求的核心是模型本身的生成能力以及你对输出风格的约束技术上主要靠提示词工程。第二类是知识库问答类比如“根据我们公司的产品文档回答内部问题”“根据运维手册排查故障”。这类需求的关键不是让模型“记住”文档而是准备好一套外部资料检索流程让模型在回答时能“查到”相关内容再做生成。这就是后文要讲的RAG方案。第三类是结构化信息抽取类比如从长文本里提取摘要、关键词、字段或者把非结构化文本转成固定的JSON。这类需求的重点在于输出格式约束和数据清洗比如你要求模型“只能输出JSON不要解释”然后程序直接解析。拿到需求后先判断它属于哪一类因为不同类型的技术选型完全不同。用对话生成的思路去做知识库问答结果就是模型凭记忆瞎编用知识库问答的思路去做文案生成又会显得又笨又慢。3.2 选模型时看哪几个维度当你要接一个大模型服务时面对各种模型名称往往不知道怎么选。我的经验是看五个维度。第一个是上下文长度。上下文长度决定了模型一次能“看到”多少文本。如果业务要读一篇几十页的PDF再总结上下文不够长的模型是吃不下的。这时候要么换更长上下文的模型要么把PDF拆成多段分别处理。第二个是能力差异。不同模型在推理、代码、中文理解上的表现差异很大。简单任务用小模型就够复杂任务必须上能力更强的模型。你可以在同一套测试问题上对比几个模型的输出再决定用谁。第三个是价格。按token计费是主流方式输入和输出单价往往不一样。有些模型输出价格是输入的几倍如果你的应用以生成长文本为主成本会涨得很快。第四个是速率限制和稳定性。有的模型服务在高峰期可能响应很慢有的每天调用量有限额。做生产环境前必须确认限流上限和可用性承诺。第五个是多模态需求。如果你的业务涉及图片识别、语音输入就需要选择对应的多模态模型而不是纯文本模型。我自己做选型时会把需求整理成一张表格把候选模型的上下文长度、价格、已知优劣势列出来先用10个典型问题做离线评测再决定用哪一个。跑通阶段选性价比最高的线上效果不够再升级模型。3.3 设计最小可行闭环很多入门者犯的错误是一上来就想做一个完整系统前端、后端、数据库、管理后台全都要结果一个月过去了核心的“模型能不能答对问题”还没验证。我推荐的做法是先做一个最小可行闭环。步骤非常简单人工准备10到20个典型问题并写上你期望的答案。在Notebook或者脚本里直接调用模型跑这些问题看输出质量。效果满意之后再补上文件上传、前端页面、权限控制这些周边功能。这个“先验证大脑、再搭身体”的思路看着朴素但能帮你避免最大的浪费——辛辛苦苦做了个漂亮的界面结果发现模型回答根本不能用。模型输出的质量是这个系统的地基地基本来就没打牢上面的房子盖得再好看也白搭。3.4 成本怎么预估成本是开发大模型应用避不开的话题。很多人第一次看到账单才慌了神。我建议在动手前先粗略算一笔账。单次调用的成本公式是输入token数乘以输入单价加上输出token数乘以输出单价。比如你的提示词固定1000个token模型输出大概500个token那一次调用的成本就是这两部分的加和。把单次成本乘以预估的调用次数就得到月度成本。初期验证阶段我习惯把测试控制在每天几十次调用以内费用通常可以忽略不计。但一旦上线做对外服务调用量会指数级上升。所以在方案设计阶段就要想好哪些请求可以复用缓存、哪些任务可以用便宜的小模型、哪些提示词能写得精简一些。这些细节放到后面“成本与性能平衡”再细说。4. 提示词工程小白的第一个核心技能4.1 提示词为什么这么重要提示词重要是因为大模型的输出质量高度依赖你给它的上下文约束。模型本质上是在做“概率续写”你给它一段文本它根据训练到的模式继续写下去。提示词的作用就是为这个续写过程设定方向、边界和格式。方向不清楚输出就发散边界不明确模型就会自由发挥格式不约束程序就不好解析。你可以把提示词理解成一份工作简报。交给一个聪明但是不了解你具体需求的实习生你只说“写个总结”他交上来的可能是诗歌你说清“对本周实验数据进行总结按结论、数据、建议三部分输出控制在200字以内”他大概率能给你一份能用的东西。大模型也是如此你的提示词越具体、越有结构输出就越接近预期。4.2 一套可以直接套用的提示词模板我自己在大量实测中总结出一套提示词模板结构非常稳定直接套用即可角色设定你是一个擅长什么的专家。任务描述你的目标是什么。背景信息你有哪些资料可用资料放在什么位置。输入内容需要处理的具体文本或问题。输出要求输出分成哪几个部分格式是什么限制多少字。禁止事项哪些事不能做比如不能编造、不能使用外部知识。示例给出一个“输入-预期输出”的样例模型会模仿样例的风格。举个例子做会议纪要助手时我会这样写你是一个会议纪要专员。请根据下面提供的会议录音转写文本生成一份会议纪要。 会议纪要必须包含以下部分会议结论、待办事项、风险点。 待办事项要列出负责人和截止时间如果原文中没有提到请写“未提及”。 不要补充原文之外的信息不要把你的建议写进去。 会议转写文本 “......” 请输出 1. 会议结论不超过100字 2. 待办事项分点列出 3. 风险点分点列出没有则写“无”为什么这个模板有效因为它做了三件事第一给模型一个明确角色让输出语言风格靠拢第二把输出拆成固定小节降低遗漏第三用“没有则写‘无’”堵住了模型编造内容的嘴。4.3 让输出稳定的三个技巧即使有了好模板模型输出仍然可能出现不稳定。我实测下来下面三个技巧最管用。第一个技巧是降低温度。做知识问答、信息抽取、格式转换这类对准确性要求高的任务把temperature调到0.1到0.3之间。温度越低输出越接近模型在概率分布里选最高概率的结果幻觉概率会明显下降。但也不是越低越好极端到0时有些模型会变得机械重复所以我会在0.2左右试跑几次再定。第二个技巧是强制输出结构。让模型按固定的JSON格式或分点格式输出甚至可以在提示词里直接定义一个JSON的键名表要求模型只输出符合该结构的对象。这样程序解析就不需要正则表达式去猜乱七八糟的文本了。结构越明确模型自由发挥的空间越小。第三个技巧是自纠错。让模型先生成一次答案然后在下一轮对话中把答案重新丢给它并追加一句“请检查上面的回答是否满足所有要求补充遗漏或修改错误”。这个方法会多花一倍调用成本但在我做过的很多任务里确实能挽回一些边界情况下漏掉的信息。只建议在质量要求高的环节使用。4.4 评测不要靠感觉调提示词学提示词工程最容易走进一个死胡同这次调完感觉好了下次换一个输入又不行了于是一直改一直试最后完全靠运气。我后来养成一个习惯准备一个固定的评测集每次修改提示词都用同一套案例跑一遍对比效果。评测集不需要很大15到30个典型问题足够了。关键是这些问题要覆盖正常场景、边界场景、容易出错的场景。然后我按这个维度打分准确性答案是否基于资料是否答非所问。完整性要求的内容是否都覆盖了。格式合规性是否按指定格式输出程序能否直接解析。幻觉率是否出现了资料和任务里没有的内容。我通常用表格记录比如“样例编号、输入、期望输出、实际输出、是否有幻觉、是否格式合规”。每次改完提示词重新跑一遍对比分数。这比“凭感觉调”靠谱得多。5. 实战案例零基础做出企业内部知识库问答机器人5.1 需求与方案选择为什么用RAG而不是微调前文讲了那么多基础现在进入实战。假设你所在的团队有几十份产品文档、运维手册和故障案例大家每天都在群里问“XX功能怎么配置”“XX报错怎么处理”。领导让你做一个知识库问答机器人要求回答准确、能给出来源、不能胡编。如果你直接拿这些问题去问裸的大模型它会用预训练学到的知识回答根本不知道你们内部文档写了什么。于是你需要把文档送到模型面前。这时候有两个选择微调和RAG。微调是拿着你的文档去调整模型权重让模型“记住”这些内容。但对中小团队来说微调成本高、周期长而且每次文档更新都要重新微调非常不划算。RAG是检索增强生成思路是用户提问时先从文档库里检索出最相关的几段内容再把问题和这些内容一起交给大模型让模型“看着资料答题”。RAG就是开卷考试。它不需要模型强行记住你的文档每次回答前先“查资料”。这既降低了幻觉率又能让用户核验信息的来源是知识库问答的首选方案。这套方案里你不需要训练任何模型你只需要搞定“文档切分、向量化、检索、组装提示词”这四件事。5.2 文档清洗与分块决定检索质量的第一步很多人第一次做RAG只顾着调向量和提示词忽视了文档清洗和分块。结果检索质量一直上不去改来改去才发现是数据环节出了问题。首先是清洗。你的原始文档可能是PDF、Word、Markdown、TXT混合在一起的。PDF批量转出来的文本经常带奇怪的换行、页眉页脚、表格错位这些都会污染后续的向量化和检索。我一般先把所有文档转成纯文本或Markdown然后用脚本去掉无意义的重复标题、页码、页眉页脚遇到表格尽量保留为结构化的文本比如“字段名值”的格式。然后是分块。模型上下文有限向量检索也需要以“粒度合适”的文本块作为单位块太大检索出来的内容可能包含太多无关信息块太小语义不完整模型看不懂。我实测下来一般按500到800个字符切分或者按文档原有章节切分效果比较稳。分块时还有一个细节让相邻的两个块保留一小段重叠区域比如50到100个字符。这样能避免一个完整概念刚好被切断导致检索时找不到完整信息。举个例子一份文档里的“连接数据库时如果出现timeout请先检查防火墙设置”如果刚好在你切分的位置被分成两半搜索“数据库连接超时”可能就检索不到了。有了重叠区信息被截断的概率会小很多。5.3 向量化、存储与召回分块完成之后下一步是把每个文本块转换成向量存进一个向量数据库并为用户的提问做相似度检索。向量化的过程是调用一个Embedding模型把一段文本变成一个固定长度的数字列表。这个数字列表就是向量。向量最神奇的地方是语义相似的文本它们的向量在高维空间里的距离也接近。比如“数据库连不上”和“数据库连接超时”这两个文本向量距离会比“今天天气不错”近很多。所以ES里传统的“关键词匹配”做不到的“语义检索”向量检索能做到。整体流程用代码示意大概是这样的def build_index(docs): chunks split_docs(docs, chunk_size500, overlap50) for chunk in chunks: vector_store.add( textchunk, vectorget_embedding(chunk) ) def answer_with_rag(question): question_vec get_embedding(question) top_chunks vector_store.search(question_vec, top_k3) context \n\n.join(top_chunks) prompt build_rag_prompt(question, context) return chat([{role: user, content: prompt}])代码里的vector_store可以是任何你选用的向量存储组件get_embedding是对某个向量化模型服务的封装。你不用急着纠结具体选型重点是理解链路文档变成向量进库问题变成向量去检索检索到的原文拼成上下文再交给对话模型生成答案。检索时有一个重要的参数top_k也就是取回最相似的几块文本。我通常先取3到5块测试。取少了可能漏信息取多了会把无关内容塞进提示词反而干扰模型判断。这需要根据文档量和问题复杂度去实验。5.4 把检索结果装进提示词RAG效果好不好提示词占了半壁江山。检索到的内容不能直接丢给模型说“你来答”你得在提示词里明确限定使用范围。我常用的RAG提示词模板是这样的你是某团队的技术支持助手。请根据下面提供的资料回答问题。 要求 1. 只依据资料内容回答不要使用资料之外的知识。 2. 如果资料中没有相关内容请直接回复“资料中没有相关内容”不要编造。 3. 回答时先给出结论再说明依据并在依据后面标注来源编号。 4. 回答控制在200字以内。 资料 [1] ...... [2] ...... [3] ...... 问题 ...... 回答为什么要求标注来源编号因为这样用户能去原文核对模型在编答案时也会多一层心理压力——它不是凭空写而是在已有资料基础上“复述组织”。实测下来加入这个要求后胡说八道的概率明显降低。另一个常见问题是用户问题可能是口语化的比如“我的库连不上了咋办”而文档里的写法可能是“连接超时排查”。这种问答对不上的情况除了靠向量检索的语义能力还可以对用户问题做一个“改写”步骤先把口语问题改成“关键词加后缀”的形式比如“如何排查数据库连接超时问题”再进行检索。这个改写本身也用大模型完成多一次调用但能明显提升召回率。5.5 上线前的评测与优化知识库机器人做完基本流程后千万不要直接上线。我见过太多人满怀信心地把机器人丢给同事用结果被一连串问题问得崩溃。上线前一定要做一轮集中的效果评测。我建议准备20个有代表性的真实问题覆盖产品配置、报错排查、操作步骤、政策规则等方向。每个问题跑完之后填一张评测表是否检索到正确资料、答案是否准确、格式是否合规、有没有幻觉、回答速度是否可接受。这轮评测的目的不是追求满分而是找出系统性的短板。如果发现“检索不到正确资料”优先去查分块和向量化环节分块是不是太大了、重叠区是不是不够、文档有没有漏掉关键信息。如果发现“检索到了但答案还是错”优先去改提示词增加“只依据资料”的强调、增加输出格式约束。如果发现“问题本身含糊导致检索不准”可以考虑加一轮问题改写。这一步是整个大模型应用开发里最花时间的环节但也是最能拉开效果差距的环节。大部分“别人做得好看我的怎么这么蠢”的差距就出在评测和迭代上做得不够。6. 高频故障与排查技巧实录6.1 四个高频问题的现象、原因和解决办法我在带团队做项目时几乎每个人都会遇到下面这四个典型问题。列成表格方便你排查时直接对照。问题现象常见原因解决办法接口响应超时模型服务繁忙、网络慢、提示词太长合理设置超时时间并做重试减少输入token错峰调用报错提示token超限消息总长度超过模型上下文窗口截断或压缩历史消息拆分成多个任务选更长上下文的模型输出不稳定同一个问题答案变来变去温度过高、提示词约束不够调低temperature增加格式约束固定评测集对比中文内容出现乱码或截断文件编码不统一、输出token上限设太低统一使用UTF-8提高输出token上限清洗原始文档超时问题是我遇到最多的。大模型接口普遍比普通API慢几百毫秒到几十秒都可能。我在代码里会把超时设到60秒以上并加上“失败后等待几秒再重试”的逻辑。重试一定要有退避不要失败后立刻疯狂重发那样容易触发服务商限流。token超限也常见。尤其做多轮对话时历史消息会越积越长。一个务实的做法是只保留最近几轮对话更早的内容做摘要压缩后再拼接。很多模型都有自己的上下文窗口上限一旦超限会直接报错而不是自动截断。6.2 一套可复用的排查流程遇到问题别慌也别乱试。我总结了一套自己的排查顺序按照这个走大部分问题都能定位。第一步先做最小化复现。把问题场景砍到最简单只传一条User消息去掉历史记录和复杂System看能不能复现。能复现说明问题出在基础调参或提示词不能复现说明问题出在某段上下文或历史消息上。第二步打印完整请求参数。把messages、temperature、max_tokens这些参数全部打印出来检查是否有非预期内容。比如某些字符被错误转义、历史消息里混入了None、JSON序列化失败等。第三步固定变量。把温度调到0同一输入多跑几次确认不是随机性问题。如果温度0下输出仍然不符合预期那基本可以断定是提示词或数据问题。第四步切分责任。是网络问题看日志里的报错码是接口问题看返回错误信息是模型效果问题换一个模型或改提示词对比是数据问题去检查分块内容和检索召回内容。这套流程的核心是“先复现、再拆解”而不是“猜一个原因改一下试试”。大模型输出的随机性确实会让排查变得更烦但只要变量控制得足够干净绝大多数问题是能稳定定位的。6.3 成本与性能平衡的几个实用策略项目做出来之后成本控制就是接下来绕不开的话题。大模型应用是按调用次数和token量花钱的一天几千次调用的应用一个月下来账单不容小觑。我的习惯是把成本控制放在方案设计的初期而不是账单出来之后。第一能缓存就缓存。同样的用户问题如果答案不需要实时变化可以先把问题和答案存起来下次命中直接返回不调用模型。第二提示词精简。System提示词和检索回来的上下文每多一个token都是钱。警惕把一长串规则塞进每个请求里如果能用更短的表达达到同样效果就尽量精简。第三模型分级。简单任务比如“把文本转成摘要”“判断意图”用便宜的小模型就够了。复杂推理任务再交给强模型。不要所有请求都用同一个最贵模型那是很大浪费。第四批量任务错峰。如果你的系统需要对历史文档进行批量处理尽量安排在低峰期执行一方面价格可能更优惠另一方面也避免影响线上实时请求的响应速度。6.4 一些容易忽略的细节最后再补几个容易被忽略、但实际中能救命的细节。第一日志里绝不能打印API密钥。这个听起来是老生常谈但我见过不止一次有人为了排查问题把整个请求头打印出来密钥直接就暴露了。密钥要放到环境变量或配置中心里不要硬编码进代码。第二要对用户输入做长度和内容限制。如果有人粘贴一段几十万字的文本进来你的提示词会被瞬间撑爆。轻则token超限重则费用飙升。在入口做长度校验超过限制就提示用户分段上传。第三如果涉及敏感信息要在调用模型之前做脱敏处理。你发的任何内容都会作为请求发给模型服务敏感数据是否合规、是否被记录都需要提前评估。至少要把身份证号、手机号、密码这类信息挡住。第四保留每次评测的数据集。这些测试用例是你最宝贵的资产。以后更换模型版本、调整提示词、做微调时都需要同一套评测集来对比效果。没有评测集你永远只能靠感觉出问题也不知道是哪次改动引起的。最后分享一个习惯文章写到这里该讲的流程基本都讲完了。最后再分享一个我个人一直在用的习惯每次调完一段提示词或者改完一套RAG参数我都会把原始输入、最终输出、模型名称、参数配置、日期这些信息存成一个带日期的文本文件。听起来很小儿科但这个习惯帮我省过很多事。大模型应用有一个和传统开发很不一样的特性输出是概率性的今天调好的效果过段时间可能因为模型版本更新、服务策略调整而悄悄变差。如果你没有留痕出了问题根本不知道是提示词变了还是模型变笨了。留痕之后你可以快速回滚到之前效果好的那版配置。说句实在话大模型开发真正难的地方不是“跑通一个Demo”而是“让它稳定复现你想要的效果”。而稳定复现的前提就是每一次实验都清清楚楚、有迹可循。这个习惯是我最想第一个告诉你的东西。希望这篇从零开始的经验记录能让你少踩几个坑。下一个阶段你不需要追求一步到位做多复杂的系统先拿一个小需求比如把某个文档问答机器人跑通你就已经迈出了真正入门的那一步。
阅读完成 · 觉得有帮助？
