两年前我第一次把大模型接入业务系统时整个人是懵的。同一个问题同一段Prompt上午问和下午问答案居然不一样。作为一个被同样的输入必有同样的输出训练了十多年的程序员这种体验就像吃饭吃到一半桌子被抽走了。更崩溃的是它偶尔还会在答案里一本正经地编造一个不存在的API函数名下游代码一跑编译器立刻教我做人的道理。这不是某个模型的问题这是生成式AI的底色。它本质是一个概率模型按概率分布一个字一个字往外蹦。既然随机是它的天性那做工程时就永远不能假设它稳定。可产品不能不稳定。所以这一年多我在做AI应用时慢慢沉淀出一套应对办法我把它们叫做生成式AI设计模式——针对生成式AI反复出现的问题场景总结出的可复用解决方案模板。这篇文章是系列的第一篇。我不会一上来就抛二十个模式而是先讲清楚为什么需要一套方法论来兜底然后给出我认为最基础、也最值得先掌握的三个模式上下文增强检索、结构化输出加后置校验、候选-反思-择优循环。如果你正在用大模型API搭应用或者准备往AI应用方向发展这篇文章能帮你少踩不少坑。1. 先搞清楚生成式AI应用为什么这么难调1.1 传统开发的确定性假设失效了做传统软件时函数只要输入一致输出必然一致。单元测试天天跑回归测试反复执行靠的就是确定性。但生成式AI把这个假设打碎了。以文本生成为例模型本质是在根据前文预测下一个Token的概率分布。哪怕把参数完全固定只要采样时引入一点随机性结果就会在概率上漂移。这给工程带来四个直接麻烦输出不稳定同一Prompt下语义可能接近但具体措辞、结构、细节都不一样。格式不可控让它返回JSON它可能给你JSON夹带一段道歉让它返回枚举值它可能给你一个从未出现过的单词。幻觉难防回答得越流利编造事实的风险越高尤其在专业领域。成本随次数线性长一次生成不理想就要重来一次Token费用实打实地烧掉。这四个麻烦单靠调Prompt只能缓解解决不了根本问题。就像你不能靠反复跟实习生说别出错来保证交付质量你需要的是流程和检查机制。1.2 生成式AI里的设计模式是什么软件工程里的设计模式是指在特定上下文下反复出现的解决方案。生成式AI设计模式同理它不要求你发明新算法而是把已被验证有效的做法沉淀成模板什么场景下用、怎么搭、有什么坑、成本如何。这套分类我在实际工作里重点看五个维度如何控制输入给模型什么信息、如何控制输出限制模型怎么回答、如何补偿不确定性出错了怎么修、如何控制成本能不能少调几次、如何做工程治理鉴权、限流、观测。后续系列会陆续展开这篇先聚焦前三类。顺便说一句这套模式和传统的GoF设计模式不是一回事。GoF关注的是类与对象之间的协作关系面向的是确定性的程序结构生成式AI设计模式关注的是模型输入输出之间的概率性协作流程面向的是不确定性的闭环控制。换到Java、C、C#里思维方式照样能用只是你编排的组件从对象变成了模型调用。2. 模式一上下文增强检索让模型开卷考试2.1 它解决什么问题大模型的知识来自训练数据因此有三个天然缺陷知识有截止日期新消息一概不知道。专业领域知识薄弱企业内部文档、私有数据完全没训练过。就算见过类似资料也可能记错、混淆造成幻觉。上下文增强检索Retrieval-Augmented Generation简称RAG就是针对这三个缺陷的经典解法。核心思想一句话既然模型闭卷考试容易胡编那就把资料摆在它面前让它开卷考试。你不需要重新训练模型只需要在提问时把相关的资料片段作为上下文喂给它让它基于资料作答。这个模式价值巨大不需要微调模型不需要把私有数据交给厂商训练就能让模型学会一个领域的知识。企业知识库问答、文档摘要、合同审查这类场景基本都是这个模式打底。2.2 落地流程和关键参数一个最小的RAG链路分四步第一步把知识文档切成小块Chunk。切块是个容易被小看的工程问题。块太小语义被切断检索不到完整上下文块太大噪声多浪费Token还可能让模型忽略关键信息。我自己的经验是中文通用文档从512到1024字符起步再根据问答效果微调。如果文档有明显的段落标题、章节结构优先按章节切而不是机械截断。第二步把每块文本向量化存进向量数据库。选Embedding模型时要注意和检索场景的匹配别拿对话模型顺手当向量模型用。目前主流向量库基本都支持常见的Embedding模型关键是向量维度、相似度算法这些参数要和你的检索场景匹配。第三步把用户问题也向量化做相似度检索拿出最相关的若干块。这里有两个参数常被忽略TopK取几块上下文。取少了信息不足取多了模型会淹没在信息里。建议从3到5块开始试试。相似度阈值低于阈值的片段宁可不要。否则把不相关的内容硬塞给模型反而诱导它胡说。第四步把检索结果和用户问题一起组装成带上下文的Prompt交给大模型生成答案。Prompt里要明确说清楚请只根据以下资料回答如果资料中没有请明确说不知道。没有这句话模型很容易又开始自由发挥。2.3 一个容易忽略的坑RAG不是加了就一定变好。检索质量差的时候效果可能比不用RAG还差。因为模型会优先相信你喂给它的材料如果喂进去的是无关片段它也会一本正经地解释。所以数据清洗、切分质量、检索阈值这些前置环节重要性往往比Prompt本身更关键。这是一个输入决定输出的模式——垃圾进垃圾出。我见过不少团队上来就调Prompt折腾一周效果还是不行最后发现是向量库里塞了一堆格式混乱、没去重的旧文档。先把数据治理好再谈模型能力。3. 模式二结构化输出与后置校验让模型按规矩说话3.1 为什么自由文本在工程里是灾难生成式AI默认返回人类读着舒服的自由文本。好看是好看了程序要消费却很麻烦。下游系统需要某个字段值去走审批流结果模型返回根据您的描述我认为状态可能是A不过也可能是B……这套逻辑根本接不上。工程上需要的不是漂亮话而是可解析、可校验、可重试的数据结构。所以模式二的核心是两层让模型尽量结构化输出然后在后置环节强行校验不合格就重试。这就像让实习生写完工作汇报部门助理负责检查格式、字段齐不齐、数值范围合不合理不合格就打回去重填。汇报可以写得灵活但交给领导之前必须符合固定模板。3.2 输出约束的三种做法第一种纯靠提示词约束。在Prompt里写死必须返回JSON格式为……再给一两个few-shot示例。零额外成本但模型服从度不是百分之百复杂Schema下经常出格式错误。第二种用模型的函数调用Function Calling或结构化输出能力。现在主流模型API基本都支持声明输出结构模型会尽量按结构生成。这一步比纯提示词约束可靠得多也省去很多解析麻烦。第三种在第二种基础上再加一层后置校验和重试。这一步很多人会漏。模型毕竟是概率模型哪怕99%服从那1%的坏格式在生产环境就是事故。3.3 校验器该做什么一个实用的校验器至少做四件事语法解析确保是合法JSON字段名称对得上。字段完整性必填字段一个不能少出现未知字段要决定是忽略还是报错。类型和取值范围检查status只能是open/closed/reviewing之一模型就算输出了Open也要归一化之后才放行。业务规则校验这个字段不能为空那个金额必须大于零。校验失败后不要把错误抛给用户。直接把错误信息连同上一次的生成结果一起反馈给模型让它修正重试。我在实践里发现带明确错误信息的重试成功率比单纯重新生成高很多通常一两次就能拿到合规输出。当然要设最大重试次数防止死循环烧钱。下面是最小骨架用Python风格伪代码示意换Java、C、C#都是一样的思路def generate_structured(prompt, schema): for attempt in range(3): raw model.call(prompt, output_schemaschema) result, error validate(raw, schema) if error is None: return result prompt f\n上次输出违反规则{error}请据此修正。 raise MaxRetryError(结构化输出重试耗尽)3.4 实操参数建议把温度temperature调低一点比如0.2甚至0会显著提升格式稳定性。代价是答案变保守少一些惊喜但对大多数业务场景来说稳定大于惊喜。另外Schema不要设计得太复杂。能拍平就不要嵌套嵌套最多两层。模型对深嵌套结构的生成能力会明显跳水这一点我踩过不止一次。实测下来温度从0.7调到0.2格式错误率能从大概15%降到2%以下代价是回答的创造性也低了但对业务系统来说这是划算的交换。4. 模式三候选-反思-择优循环用多次生成换质量4.1 单次生成的天花板模型再强单次生成也有天花板。复杂任务里它可能漏掉一个关键约束或者在推理中途悄悄跑偏。指望一遍Prompt搞定所有问题不太现实。这时候需要模式三先让模型生成多个候选再让同一个或另一个模型扮演批评者指出候选里的问题然后带着批评意见重新生成修订版最后再做质量择优。这个模式的哲学是别把宝押在一次随机采样上用多次采样和反馈逼近正确答案。它其实借鉴了软件开发里的Code Review你先写一版代码同事审核提意见你再改再合入主干。生成式AI当然干不了这么复杂的活但思路是通的。4.2 两种常见实现路径第一种同模型自反思。先生成初稿然后让同一个模型批评自己的初稿你刚才的回答有没有事实错误有没有遗漏需求再让它带着批评重新作答。实现简单不需要接第二个模型但批评的独立性有限——它很可能觉得自己写得还不错改进有限。第二种多模型互相评审。用一个更强、通常也更贵的模型当裁判对初稿打分并给修改建议。效果更好尤其适合内容质量要求高的场景但成本明显上升。我常用的组合是生成阶段用性价比高的模型评审修订阶段用更强的模型把成本花在刀刃上。无论哪种务必设置最大迭代轮数和终止条件。我见过团队把反思循环写成while True结果模型从第二轮开始反复道歉、越改越短白白烧Token。对多数场景一轮生成加一到两轮反思就够了再往后收获和成本的比值会急剧下降。4.3 什么时候不值得用如果回答今天天气怎么样你直接调天气API就好根本不用生成式AI。就算需要生成像把这段文字翻译成英文这种确定性较高的任务单次生成往往已经不错加反思纯属浪费。所以模式三不是越用越好。它的适用场景是任务复杂、错误代价高、有明确可检查性的内容生成比如合规摘要、客服话术、复杂代码审查意见。用之前先自问一句这个任务错了代价有多大如果代价不大单次生成就够了。5. 综合示例一个企业知识库问答助手如何把三个模式串起来5.1 场景设定与架构串接为了让上面三个模式不止停留在概念里我拿一个典型场景来组合演示企业内部知识库问答助手。用户问政策问题系统必须回答准确还得注明出处如果知识库没有对应内容必须老实说不知道不许编。流程可以这样走用户输入问题。上下文增强检索从向量库检索出TopK条相关文档片段附上文档ID。组装Prompt要求模型输出结构化JSON包含answer、sources数组、confidence字段。结构校验验证JSON合法、sources非空、confidence在0到1之间。失败则带校验信息重试成功则走候选反思模式。为了控制成本只对低置信度或不满足业务规则的答案做反思。最终返回答案把sources展示给用户。5.2 伪代码骨架def qa_assistant(question): chunks retrieve(question, top_k5) # 模式一检索增强 prompt build_prompt(question, chunks) schema AnswerSchema.alias(Answer) # 模式二结构化输出 answer generate_structured(prompt, schema) if answer is None: # 校验失败重试耗尽 return 抱歉暂时无法给出可靠答案请转人工。 if answer.confidence 0.6: # 模式三低置信度才反思 critique critique_model.criticize(answer) answer generate_structured( build_revised_prompt(question, chunks, answer, critique), schema ) return answer这个组合很有意思模式一保证模型有据可答模式二保证程序能消费结果模式三只在关键节点兜底。三个模式各管一段不会互相打架。5.3 这样组合的成本与取舍成本上RAG本身便宜只需要一次向量检索结构化输出和普通调用等价主要增量来自反思模式的重试。所以我刻意设计成低置信度才反思而不是每次都反思。延迟上完整链路多了一两次额外模型调用用户等待时间会从几百毫秒涨到两三秒。这在内部工具场景完全可以接受但如果做高并发的对外接口就要谨慎评估——可能需要把反思放到异步流程或者只对高风险请求启用。6. 写在一之后这套体系还会继续长6.1 后续系列想展开的方向这篇作为系列第一篇我刻意只收敛了三个最基础的模式。它们的共同点是都围绕调用单个模型这件事做文章还没深入工程侧。而生成式AI应用真正上线之后还有更多场景会反复出现——比如输入输出网关模式所有模型调用统一走一个中间层做鉴权、限流、日志、按需降级。缓存与复用模式同样或相似的请求没必要每次都重新生成特定场景可以用语义相似度命中后直接复用结果。多路投票模式让多个模型或多个策略分别生成结果最后用表决策略收口用三倍成本换更高准确率。还有Agent编排里的工具调用、任务拆解、记忆管理每个都值得单独展开。这些内容我会在后续的二三里继续写。你不用等我如果手上正在做AI应用可以直接按这个框架自己先试。6.2 我给刚上手的开发者的三条建议第一别急着一次把所有模式都套上去。先用最简单的直连调用跑通流程把数据、Prompt、校验先做扎实再按需叠加模式。模式是工具业务效果才是目标。第二任何模式落地前先在几条真实业务数据上跑一遍基线。把单次生成的效果、成本、延迟记下来加上模式后对比同一批数据。你会发现很多想当然的优化实际收益和成本完全不成正比。第三用数字说话而不是用感觉。AI应用工程本质上还是工程能量化错误率、重试率、置信度分布才能说服自己也说服团队。我在实际项目里最大的收获不是会了几个花哨的Prompt技巧而是养成了一套先测量、再优化的习惯。希望这篇能帮你少走一些弯路。下一篇我会重点写工程侧的模式尤其是输入输出网关和缓存复用这两块对成本控制最立竿见影。到时候见。
两年前我第一次把大模型接入业务系统时整个人是懵的。同一个问题同一段Prompt上午问和下午问答案居然不一样。作为一个被同样的输入必有同样的输出训练了十多年的程序员这种体验就像吃饭吃到一半桌子被抽走了。更崩溃的是它偶尔还会在答案里一本正经地编造一个不存在的API函数名下游代码一跑编译器立刻教我做人的道理。这不是某个模型的问题这是生成式AI的底色。它本质是一个概率模型按概率分布一个字一个字往外蹦。既然随机是它的天性那做工程时就永远不能假设它稳定。可产品不能不稳定。所以这一年多我在做AI应用时慢慢沉淀出一套应对办法我把它们叫做生成式AI设计模式——针对生成式AI反复出现的问题场景总结出的可复用解决方案模板。这篇文章是系列的第一篇。我不会一上来就抛二十个模式而是先讲清楚为什么需要一套方法论来兜底然后给出我认为最基础、也最值得先掌握的三个模式上下文增强检索、结构化输出加后置校验、候选-反思-择优循环。如果你正在用大模型API搭应用或者准备往AI应用方向发展这篇文章能帮你少踩不少坑。1. 先搞清楚生成式AI应用为什么这么难调1.1 传统开发的确定性假设失效了做传统软件时函数只要输入一致输出必然一致。单元测试天天跑回归测试反复执行靠的就是确定性。但生成式AI把这个假设打碎了。以文本生成为例模型本质是在根据前文预测下一个Token的概率分布。哪怕把参数完全固定只要采样时引入一点随机性结果就会在概率上漂移。这给工程带来四个直接麻烦输出不稳定同一Prompt下语义可能接近但具体措辞、结构、细节都不一样。格式不可控让它返回JSON它可能给你JSON夹带一段道歉让它返回枚举值它可能给你一个从未出现过的单词。幻觉难防回答得越流利编造事实的风险越高尤其在专业领域。成本随次数线性长一次生成不理想就要重来一次Token费用实打实地烧掉。这四个麻烦单靠调Prompt只能缓解解决不了根本问题。就像你不能靠反复跟实习生说别出错来保证交付质量你需要的是流程和检查机制。1.2 生成式AI里的设计模式是什么软件工程里的设计模式是指在特定上下文下反复出现的解决方案。生成式AI设计模式同理它不要求你发明新算法而是把已被验证有效的做法沉淀成模板什么场景下用、怎么搭、有什么坑、成本如何。这套分类我在实际工作里重点看五个维度如何控制输入给模型什么信息、如何控制输出限制模型怎么回答、如何补偿不确定性出错了怎么修、如何控制成本能不能少调几次、如何做工程治理鉴权、限流、观测。后续系列会陆续展开这篇先聚焦前三类。顺便说一句这套模式和传统的GoF设计模式不是一回事。GoF关注的是类与对象之间的协作关系面向的是确定性的程序结构生成式AI设计模式关注的是模型输入输出之间的概率性协作流程面向的是不确定性的闭环控制。换到Java、C、C#里思维方式照样能用只是你编排的组件从对象变成了模型调用。2. 模式一上下文增强检索让模型开卷考试2.1 它解决什么问题大模型的知识来自训练数据因此有三个天然缺陷知识有截止日期新消息一概不知道。专业领域知识薄弱企业内部文档、私有数据完全没训练过。就算见过类似资料也可能记错、混淆造成幻觉。上下文增强检索Retrieval-Augmented Generation简称RAG就是针对这三个缺陷的经典解法。核心思想一句话既然模型闭卷考试容易胡编那就把资料摆在它面前让它开卷考试。你不需要重新训练模型只需要在提问时把相关的资料片段作为上下文喂给它让它基于资料作答。这个模式价值巨大不需要微调模型不需要把私有数据交给厂商训练就能让模型学会一个领域的知识。企业知识库问答、文档摘要、合同审查这类场景基本都是这个模式打底。2.2 落地流程和关键参数一个最小的RAG链路分四步第一步把知识文档切成小块Chunk。切块是个容易被小看的工程问题。块太小语义被切断检索不到完整上下文块太大噪声多浪费Token还可能让模型忽略关键信息。我自己的经验是中文通用文档从512到1024字符起步再根据问答效果微调。如果文档有明显的段落标题、章节结构优先按章节切而不是机械截断。第二步把每块文本向量化存进向量数据库。选Embedding模型时要注意和检索场景的匹配别拿对话模型顺手当向量模型用。目前主流向量库基本都支持常见的Embedding模型关键是向量维度、相似度算法这些参数要和你的检索场景匹配。第三步把用户问题也向量化做相似度检索拿出最相关的若干块。这里有两个参数常被忽略TopK取几块上下文。取少了信息不足取多了模型会淹没在信息里。建议从3到5块开始试试。相似度阈值低于阈值的片段宁可不要。否则把不相关的内容硬塞给模型反而诱导它胡说。第四步把检索结果和用户问题一起组装成带上下文的Prompt交给大模型生成答案。Prompt里要明确说清楚请只根据以下资料回答如果资料中没有请明确说不知道。没有这句话模型很容易又开始自由发挥。2.3 一个容易忽略的坑RAG不是加了就一定变好。检索质量差的时候效果可能比不用RAG还差。因为模型会优先相信你喂给它的材料如果喂进去的是无关片段它也会一本正经地解释。所以数据清洗、切分质量、检索阈值这些前置环节重要性往往比Prompt本身更关键。这是一个输入决定输出的模式——垃圾进垃圾出。我见过不少团队上来就调Prompt折腾一周效果还是不行最后发现是向量库里塞了一堆格式混乱、没去重的旧文档。先把数据治理好再谈模型能力。3. 模式二结构化输出与后置校验让模型按规矩说话3.1 为什么自由文本在工程里是灾难生成式AI默认返回人类读着舒服的自由文本。好看是好看了程序要消费却很麻烦。下游系统需要某个字段值去走审批流结果模型返回根据您的描述我认为状态可能是A不过也可能是B……这套逻辑根本接不上。工程上需要的不是漂亮话而是可解析、可校验、可重试的数据结构。所以模式二的核心是两层让模型尽量结构化输出然后在后置环节强行校验不合格就重试。这就像让实习生写完工作汇报部门助理负责检查格式、字段齐不齐、数值范围合不合理不合格就打回去重填。汇报可以写得灵活但交给领导之前必须符合固定模板。3.2 输出约束的三种做法第一种纯靠提示词约束。在Prompt里写死必须返回JSON格式为……再给一两个few-shot示例。零额外成本但模型服从度不是百分之百复杂Schema下经常出格式错误。第二种用模型的函数调用Function Calling或结构化输出能力。现在主流模型API基本都支持声明输出结构模型会尽量按结构生成。这一步比纯提示词约束可靠得多也省去很多解析麻烦。第三种在第二种基础上再加一层后置校验和重试。这一步很多人会漏。模型毕竟是概率模型哪怕99%服从那1%的坏格式在生产环境就是事故。3.3 校验器该做什么一个实用的校验器至少做四件事语法解析确保是合法JSON字段名称对得上。字段完整性必填字段一个不能少出现未知字段要决定是忽略还是报错。类型和取值范围检查status只能是open/closed/reviewing之一模型就算输出了Open也要归一化之后才放行。业务规则校验这个字段不能为空那个金额必须大于零。校验失败后不要把错误抛给用户。直接把错误信息连同上一次的生成结果一起反馈给模型让它修正重试。我在实践里发现带明确错误信息的重试成功率比单纯重新生成高很多通常一两次就能拿到合规输出。当然要设最大重试次数防止死循环烧钱。下面是最小骨架用Python风格伪代码示意换Java、C、C#都是一样的思路def generate_structured(prompt, schema): for attempt in range(3): raw model.call(prompt, output_schemaschema) result, error validate(raw, schema) if error is None: return result prompt f\n上次输出违反规则{error}请据此修正。 raise MaxRetryError(结构化输出重试耗尽)3.4 实操参数建议把温度temperature调低一点比如0.2甚至0会显著提升格式稳定性。代价是答案变保守少一些惊喜但对大多数业务场景来说稳定大于惊喜。另外Schema不要设计得太复杂。能拍平就不要嵌套嵌套最多两层。模型对深嵌套结构的生成能力会明显跳水这一点我踩过不止一次。实测下来温度从0.7调到0.2格式错误率能从大概15%降到2%以下代价是回答的创造性也低了但对业务系统来说这是划算的交换。4. 模式三候选-反思-择优循环用多次生成换质量4.1 单次生成的天花板模型再强单次生成也有天花板。复杂任务里它可能漏掉一个关键约束或者在推理中途悄悄跑偏。指望一遍Prompt搞定所有问题不太现实。这时候需要模式三先让模型生成多个候选再让同一个或另一个模型扮演批评者指出候选里的问题然后带着批评意见重新生成修订版最后再做质量择优。这个模式的哲学是别把宝押在一次随机采样上用多次采样和反馈逼近正确答案。它其实借鉴了软件开发里的Code Review你先写一版代码同事审核提意见你再改再合入主干。生成式AI当然干不了这么复杂的活但思路是通的。4.2 两种常见实现路径第一种同模型自反思。先生成初稿然后让同一个模型批评自己的初稿你刚才的回答有没有事实错误有没有遗漏需求再让它带着批评重新作答。实现简单不需要接第二个模型但批评的独立性有限——它很可能觉得自己写得还不错改进有限。第二种多模型互相评审。用一个更强、通常也更贵的模型当裁判对初稿打分并给修改建议。效果更好尤其适合内容质量要求高的场景但成本明显上升。我常用的组合是生成阶段用性价比高的模型评审修订阶段用更强的模型把成本花在刀刃上。无论哪种务必设置最大迭代轮数和终止条件。我见过团队把反思循环写成while True结果模型从第二轮开始反复道歉、越改越短白白烧Token。对多数场景一轮生成加一到两轮反思就够了再往后收获和成本的比值会急剧下降。4.3 什么时候不值得用如果回答今天天气怎么样你直接调天气API就好根本不用生成式AI。就算需要生成像把这段文字翻译成英文这种确定性较高的任务单次生成往往已经不错加反思纯属浪费。所以模式三不是越用越好。它的适用场景是任务复杂、错误代价高、有明确可检查性的内容生成比如合规摘要、客服话术、复杂代码审查意见。用之前先自问一句这个任务错了代价有多大如果代价不大单次生成就够了。5. 综合示例一个企业知识库问答助手如何把三个模式串起来5.1 场景设定与架构串接为了让上面三个模式不止停留在概念里我拿一个典型场景来组合演示企业内部知识库问答助手。用户问政策问题系统必须回答准确还得注明出处如果知识库没有对应内容必须老实说不知道不许编。流程可以这样走用户输入问题。上下文增强检索从向量库检索出TopK条相关文档片段附上文档ID。组装Prompt要求模型输出结构化JSON包含answer、sources数组、confidence字段。结构校验验证JSON合法、sources非空、confidence在0到1之间。失败则带校验信息重试成功则走候选反思模式。为了控制成本只对低置信度或不满足业务规则的答案做反思。最终返回答案把sources展示给用户。5.2 伪代码骨架def qa_assistant(question): chunks retrieve(question, top_k5) # 模式一检索增强 prompt build_prompt(question, chunks) schema AnswerSchema.alias(Answer) # 模式二结构化输出 answer generate_structured(prompt, schema) if answer is None: # 校验失败重试耗尽 return 抱歉暂时无法给出可靠答案请转人工。 if answer.confidence 0.6: # 模式三低置信度才反思 critique critique_model.criticize(answer) answer generate_structured( build_revised_prompt(question, chunks, answer, critique), schema ) return answer这个组合很有意思模式一保证模型有据可答模式二保证程序能消费结果模式三只在关键节点兜底。三个模式各管一段不会互相打架。5.3 这样组合的成本与取舍成本上RAG本身便宜只需要一次向量检索结构化输出和普通调用等价主要增量来自反思模式的重试。所以我刻意设计成低置信度才反思而不是每次都反思。延迟上完整链路多了一两次额外模型调用用户等待时间会从几百毫秒涨到两三秒。这在内部工具场景完全可以接受但如果做高并发的对外接口就要谨慎评估——可能需要把反思放到异步流程或者只对高风险请求启用。6. 写在一之后这套体系还会继续长6.1 后续系列想展开的方向这篇作为系列第一篇我刻意只收敛了三个最基础的模式。它们的共同点是都围绕调用单个模型这件事做文章还没深入工程侧。而生成式AI应用真正上线之后还有更多场景会反复出现——比如输入输出网关模式所有模型调用统一走一个中间层做鉴权、限流、日志、按需降级。缓存与复用模式同样或相似的请求没必要每次都重新生成特定场景可以用语义相似度命中后直接复用结果。多路投票模式让多个模型或多个策略分别生成结果最后用表决策略收口用三倍成本换更高准确率。还有Agent编排里的工具调用、任务拆解、记忆管理每个都值得单独展开。这些内容我会在后续的二三里继续写。你不用等我如果手上正在做AI应用可以直接按这个框架自己先试。6.2 我给刚上手的开发者的三条建议第一别急着一次把所有模式都套上去。先用最简单的直连调用跑通流程把数据、Prompt、校验先做扎实再按需叠加模式。模式是工具业务效果才是目标。第二任何模式落地前先在几条真实业务数据上跑一遍基线。把单次生成的效果、成本、延迟记下来加上模式后对比同一批数据。你会发现很多想当然的优化实际收益和成本完全不成正比。第三用数字说话而不是用感觉。AI应用工程本质上还是工程能量化错误率、重试率、置信度分布才能说服自己也说服团队。我在实际项目里最大的收获不是会了几个花哨的Prompt技巧而是养成了一套先测量、再优化的习惯。希望这篇能帮你少走一些弯路。下一篇我会重点写工程侧的模式尤其是输入输出网关和缓存复用这两块对成本控制最立竿见影。到时候见。
