LLM应用开发

你的原型一个周末就上线了,演示惊艳全场,然后生产环境就来敲打了你。模型从一份它从没见过的文档里给出了一个听起来很自信的回答;在 Notebook 里好用的提示词,一上量就按同样的成本失败;让五个用户满意的输出,到五千个用户时开始胡编;而且你每修一处,回答反而更差。在大语言模型之上做应用,不是一项提示工程练习——它是一门拥有自己的失效模式、成本曲线和评估要求的工程学科。本指南会带你走一遍从原型到生产的各个阶段,以及决定你的 LLM 应用能否经受真实用户考验的那些具体决策。

围绕 LLM 建一个应用,听上去是这十年最简单的技术红利——直到你第一张真实账单到账。你十分钟调通 API,演示让所有人惊叹;然后同样的调用变成一天两千次,你五块钱的免费额度一小时内蒸发。一个常见的失效模式长这样:公司官宣一个 AI 功能,媒体叫好,然后财务部门悄悄把它关掉——因为每个用户会话的花费比订阅费还贵。根据多个生产团队的成本分析,一个粗糙构建的客服助手容易做到每个活跃用户每月 1 到 5 美元,而架构得当(带检索、缓存和模型路由)的可以压到 0.1 美元以下。

玩具和产品之间的差距不是魔法,而是一组具体的工程决策:你怎么给模型喂上下文、怎么守住输出、怎么测量质量、怎么控住花费。这份指南从提示词设计讲到评估、再到生产成本控制,给你具体数字和工具,而不是空谈。

从 API 层和提示词设计开始

每个 LLM 应用都始于一次 API 调用,但好提示词和坏提示词的差别巨大。写精确的系统指令、判断少样本(few-shot)示例是否有用、选对 temperature 和 token 上限,既改变质量也改变成本。一个更清楚、第一次就给对答案的提示词,比一个随意的、逼模型带 4000 个输出 token 重试好几次的提示词便宜十五倍。要量 token,别量感觉。好的提示词通常包含:系统角色、清晰任务、对格式和长度的约束,以及显式的"我不知道"处理,让模型承认无知而不是乱编。

在集成层,多数生产应用通过支持流式输出和结构化输出的 API 跟模型对话。流式输出让界面在延迟再高时也显得快;结构化输出(JSON schema)让你能可靠地解析响应,而不是抠文本。两者都是多数原型跳过的便宜红利,而在你有了扎实的 API 集成 习惯之后就容易得多。下一个杠杆是路由:把简单查询发给又小又便宜的模型,只在硬推理时才升级到旗舰模型。这种"模型路由"模式通常能砍掉 60% 到 80% 的成本,同时让主体量保持质量稳定。

检索层:RAG 做对才有用

多数生产 LLM 应用并不是在从模型的权重里钓通用知识,而是回答关于你的文档、产品或数据库的问题,这就意味着你要用到检索增强生成(RAG)。模式是:把你的文档嵌入向量数据库,把用户问题转成查询向量,检索出 top-k 相关片段,塞进提示词当上下文。做对了,你就能基于自己的数据给出准确、及时的答案,同时让模型专注、减少幻觉。

错误也是可预测的。按固定字符数切块会把句子撕开;不先测测试集就做的嵌入选择会返回糟糕结果;而只提示"用上下文"、却不教它"缺答案时说出来"的模型,会产生自信的胡说。好的 RAG 流水线看的是检索命中率和回答忠实度,而不是某条被精心挑选的 demo 好不好看。先拿一份小而干净的语料起步,用五十条有代表性的问题手工评估检索,在扩容前先改进切块和嵌入。想真正吃透语言模型和嵌入的原理,Python 入门 和 进阶提示工程 会在每个项目里帮你打底,而不只是第一个。

对比构建积木与可选方案

几个关键模式。第一,所有主流提供方都提供便宜的"小模型"和昂贵的"旗舰模型",你的路由策略决定哪些调用值得多付。第二,编排层(LangChain)是便利,不是魔法,很多团队用几百行写得很好的代码去替换它,避开它的抽象税。第三,向量库主要区别在"托管 vs 自托管"和规模,所以按你是想自己运维还是买单来决定。在产品连一次准确检索都没有之前,别过度设计技术栈。

护栏、安全与输出验证

生产 LLM 功能不能"只是好",它必须安全、可预测。这意味着要在裸模型外再叠几层:输入内容审核,拦截有害内容或提示注入;输出验证,检查响应是否符合你的 schema,是否含不安全内容;以及对模型"允许做什么"设硬上限。提示注入是真实且当下的威胁——一条嵌入的用户指令覆盖了你的系统提示;健壮的应用会隔离不受信的输入,并根据"来自系统还是用户"来限制工具访问。

对结构化任务,把模型输出按 schema 解析,不匹配就拒绝或重试。对金融、健康这类安全至关重要的领域,把模型输出当作需经确定性规则层(必要时再加人工)验证的草稿。很多能力强的架构让模型生成内容,但在任何有后果的东西上面加一层显式验证。正是这种分层,让你能上线一个不会变成负债的 AI 功能,而它依赖于理性地整合 AI 服务的功底,包括知道何时该 进阶提示工程 或做微调,而不是盲目硬接,其中用到的数据功底可以参考本站的 AI 自动化办公技巧 场景化落地。

评估:在扩容前测量质量

如果你无法判断一个 LLM 应用好不好,你就无法改进它,而且你会是最后一个知道某次改动搞坏它的人。建一个含 40 到 100 条代表性输入和期望输出的评估集,捕获模型答案和子集上的人工评分,并追踪两件事:测试集的准确率和每次请求的成本。回归测试极其重要,因为模型更新和提示词微调会静默地改变行为;上个月好用的东西可能随新模型版本退化。把模型和提示词一起版本化,这样你能回滚到任意一个已知正常的配置。

当人工稀缺时,用一个更强的模型在清晰 rubric 下给答案打分或抽检幻觉。"LLM 判官"式自动评估并不完美,但比主观的临时测试好得多,而且让你能实证地比较提示词变体——就像扎实的数据功底帮你正确读懂那些指标一样。被版本化的、可衡量的流水线,是多数团队跳过却杠杆率最高的事,它直接解释了为什么有些 LLM 功能悄悄烂掉,另一些则迭代向卓越。

让功能活下来的成本控制

• 把简单查询路由给小模型,旗舰只留给难例,通常能砍掉 60% 到 80% 的开销。
• 缓存重复或相似的查询,让同一个客服问题命中缓存查找,而非一次完整模型调用。
• 给每个用户设定每日 token 上限,并设硬预算告警,防止单个失控用户烧光当月预算。
• 用提示级 token 预算,把上下文截断到任务需要的量,而不是把每片检索到的内容都塞进去。
• 把异步任务批量处理,享受打折的批处理端点,而不是实时调用。
• 持续监控每次请求的成本,设一个能赶在账单吓到你之前暴露回退的阈值。

量是多数预算死掉的地方。一个每次请求 0.01 美元的功能听起来像免费,直到它每月服务一百万次请求。专业团队从第一天起就给模型层圈上硬性的财务边界,提前决定"一个可持续盈利的用户会话可以花多少钱",并工程化检索、缓存和路由来守住那条线。把机器学习基础和应用管线吃透,配合本站 AI 数据分析,成本控制就从猜变成可复制的流程。

常见问题（FAQ）

开发者原型化 LLM 应用最快的方式是什么?

从对单一提供方的一次 API 调用开始,用清晰的系统提示词和结构化输出,再构建两个相连的功能:对一小份语料的检索步骤,和一个流式聊天界面。初期跳过重型框架;几百行朴素代码更快、更容易调试。只有原型表现出真实准确度后再加编排和评估。

怎么降低生产 RAG 系统的幻觉?

提高检索质量以保证相关上下文真的在场,提示模型只从给定上下文回答,并加一个"信心信号"让模型说不清楚就说"我不知道"而不是猜。建一个小评估集,对着它迭代切块和嵌入。没有单一修复能根除幻觉,但这个组合能大幅降低它。

该基于 LangChain 构建,还是从零写代码?

取决于你的团队和复杂度。当你需要快速串起很多提供方和工具时,LangChain 能加速集成,代价是抽象和版本更替。小而稳定的应用往往直接写更清晰。许多成熟团队最终用一层薄薄的内部封装加自己的胶水代码来保证可靠。

跑一个 LLM 应用生产要花多少钱?

差异很大。一个粗糙构建的客服助手可能每个活跃用户每月 1 到 5 美元;而带模型路由、缓存和 token 上限、架构得当时的可以压在 0.1 美元以下。这些数字假设有几千个会话;解法是测量每次请求的成本,并把检索和提示层设计得让它保持低。

OpenAI、Anthropic 和 Google 之间怎么选?

拿你真实的工作负载去对各家的关键维度做基准:测试集准确度、延迟、上下文需求、单位 token 成本、多模态要求。别按牌子选。因为你可以在一个接口背后做抽象,所以在三家上都跑同一套评估集,让数字决定,然后保留路由能力,以便价格或质量变化时切换。