这次我们聊一个听起来有点绕、但确实是当前 AI 工程里最值得投入的方向Making AI Smarter with AI也就是“用 AI 来让 AI 变强”。先解释一下这个标题。它不是某个具体开源项目的名字而是一类工程方法论的统称当你不再满足于“用现成大模型跑推理”而是开始用大模型生成训练数据、用模型评估模型、用 Agent 调度工具、用强化反馈优化策略时你实际上就是在做“用 AI 增强 AI”这件事。这类思路在当前 AI 应用开发里几乎无处不在。很多人以为把模型拉起来、调通 API 就算完成部署但实际上真正决定一个 AI 系统上限的是后面这几层数据质量怎么来、效果怎么评估、模型跑偏了怎么修正、复杂任务怎么拆解。这些问题单独靠“换个更大的模型”解决不了必须有一套“AI 辅助 AI”的工程闭环。这篇文章会把这条技术路线拆成几个可以落地的方向来讲包括合成数据生成、LLM as Judge 自动评估、AI Agent 工具调用增强、提示词自动优化。每个方向都会给出思路、适用场景、代码示例和验证方法。如果你正在做 AI 应用开发、AI 模型部署或者准备把大模型接进自己的业务系统这篇内容可以直接当一份工程参考来看。1. 核心能力速览先把“用 AI 增强 AI”涉及的几个主流技术路线整理成一张表。按照当前 GPT 类应用和开源大模型生态的常见实践可以分成四个层次技术方向核心思路典型应用工程门槛合成数据生成用大模型生成训练/评测数据提升小模型效果微调、领域适配、数据增强低需要 API 或本地模型LLM as Judge用模型自动评估模型输出质量批量评测、效果回归、内容审核低接口调用即可AI Agent 工具调用让模型自主调用搜索、代码、数据库等工具智能体、自动化任务、工作流引擎中需要设计工具协议提示词自动优化用模型迭代改进提示词替代人工调参RAG 优化、提示词工程、推理增强中需要评估闭环强化学习反馈根据用户反馈/任务成功率更新策略推荐系统、对话策略、个性化生成高需要训练基础设施如果你关心的是本地部署那么合成数据生成和 LLM as Judge 这两条路线最轻量一台普通 GPU 机器或者纯 CPU 环境都能跑起来。Agent 工具调用则依赖具体框架比如 Function Calling 或 ReAct 模式。强化学习反馈路线最重需要你有模型训练的基础设施和稳定反馈数据源一般团队不建议上来就碰。这篇文章重点展开前四个方向最后一个只做原理说明不给出完整训练方案。2. 适用场景与使用边界先说清楚什么场景适合“用 AI 增强 AI”什么场景不适合。适合的场景有三个共同点有明确的评估标准、有可重复的任务流程、有足够的历史数据或中间结果可供分析。比如内容审核系统需要大量标注样本但人工标注成本高可以用大模型预标注再做人工抽检。企业知识库问答回答质量参差不齐需要自动评估检索效果和生成质量。代码生成助手需要判断生成代码能否通过测试用模型先做静态评估再接入编译运行验证。客服机器人需要根据用户反馈持续优化话术和工具调用策略。不适合的场景也有三个特征没有量化标准、涉及高风险决策、数据隐私边界不清楚。比如医疗诊断建议、法律意见、金融投资决策这类场景里 AI 只能做辅助不能形成“AI 评估 AI”的自动化闭环。合规上必须保留人工审核节点。使用边界必须明确合成数据不能完全替代真实数据它只能扩充分布覆盖自动评估不能完全替代人工评估尤其在主观质量项上Agent 自动调用工具时涉及外部系统操作必须加权限控制和审计日志。任何涉及人脸、声音、版权素材的内容生成都必须确认授权来源。3. 技术路线一合成数据生成这条路线解决的核心问题是真实数据不够、太贵、或者不好拿。3.1 原理用一个能力强的大模型比如 GPT-4 级别或者开源大模型生成训练样本再用这些样本去微调一个更小、更便宜、更快的小模型。常见做法有三种直接生成让大模型根据主题和格式要求生成问答对、摘要、分类样本。改写增强让大模型把已有样本改写成不同风格、不同难度、不同表述。反事实生成让大模型生成“边界情况”样本比如错误答案、模糊表述、对抗样本用于增强模型的鲁棒性。3.2 代码示例下面给出一段通用的大模型生成合成数据的 Python 示例假设你已经有一个可访问的 OpenAI 兼容接口本地也可以用 vLLM、Ollama 等框架启动同类型服务。import json import random from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) topics [Python 列表与字典区别, SQL 索引优化, Docker 容器网络模式] prompt_template 你是一个数据生成器。请为下面的技术主题生成 5 个高质量的面试问答对。 要求 1. 问题由浅入深覆盖基础概念和实际应用。 2. 答案准确不超过 150 字。 3. 输出 JSON 数组每个元素包含 question 和 answer 字段。 主题{topic} for topic in topics: user_prompt prompt_template.format(topictopic) response client.chat.completions.create( modelyour-model-name, messages[{role: user, content: user_prompt}], temperature0.8, max_tokens1500 ) content response.choices[0].message.content try: data json.loads(content) for item in data: print(json.dumps({topic: topic, **item}, ensure_asciiFalse)) except json.JSONDecodeError: print(解析失败原始输出, content)3.3 验证方式合成数据生成完不能直接用必须先做质量抽检。建议流程是随机抽 50 到 100 条人工检查准确性。检查类别分布确认没有某类样本过少。用小模型按合成数据微调在真实测试集上对比微调前后的效果。如果真实测试集提升不明显优先检查数据质量而不是继续增加数据量。4. 技术路线二LLM as Judge 自动评估这条路线解决的核心问题是生成结果好不好不能每次都靠人看。4.1 原理让一个模型当裁判给另一个模型的输出打分或者给出判断。最常见的应用是批量评测同一批问题比较不同模型或不同提示词的效果。效果回归每次更新提示词或微调版本后自动跑一遍测试集确认没有变差。内容审核让模型判断输出是否包含违规内容。评估方式可以分成三类打分式给模型输出打 1 到 5 分。对比式给出两个候选结果让模型选择哪个更好。多维式分别评估准确性、相关性、完整性、安全性等维度。4.2 代码示例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) judge_prompt 你是一个严谨的 AI 输出评估器。请对下面的问答对进行评估。 问题{question} 参考答案{reference} 待评估答案{candidate} 请从准确性、完整性、相关性三个维度打分每个维度 1-5 分。 输出 JSON 格式包含 scores 和 reason 字段。 question 什么是 RAG reference RAGRetrieval-Augmented Generation是一种将检索与生成结合的架构。 candidate RAG 是一种让模型上网搜索再回答的技术。 response client.chat.completions.create( modelyour-judge-model, messages[ {role: user, content: judge_prompt.format( questionquestion, referencereference, candidatecandidate )} ], temperature0, max_tokens500 ) print(response.choices[0].message.content)4.3 注意事项LLM as Judge 的准确性不是百分之百。常见问题包括位置偏好两个候选结果放前面和放后面模型判断会漂移。长度偏好模型倾向于认为长的答案更好。自我偏好模型对自己生成的答案打分偏高。缓解方法是多次交换顺序、增加随机种子、结合规则校验。关键业务场景一定要保留人工抽检节点不能完全自动化。5. 技术路线三AI Agent 工具调用增强这条路线解决的核心问题是模型只知道“怎么说”但不知道“怎么做”。5.1 原理给模型注册外部工具包括搜索引擎、代码执行器、数据库查询、HTTP 请求、文件读写等。模型在推理时根据用户请求决定调用哪个工具、传什么参数然后把工具返回结果继续加工最终给出答案。工程上需要做三件事工具定义用 JSON Schema 描述函数名、参数、返回值。工具注册启动时把工具列表注入模型上下文。工具执行模型返回 tool call 指令后由代码层负责真正执行。import json def search_knowledge_base(query: str) - str: # 实际调用内部知识库 return 根据知识库RAG 的完整流程包括索引构建、检索、重排和生成。 tools [ { type: function, function: { name: search_knowledge_base, description: 检索企业内部知识库, parameters: { type: object, properties: { query: { type: string, description: 检索关键词 } }, required: [query] } } } ] response client.chat.completions.create( modelyour-agent-model, messages[{role: user, content: 请解释一下 RAG 的工作流程}], toolstools, tool_choiceauto ) message response.choices[0].message if message.tool_calls: for tool_call in message.tool_calls: arguments json.loads(tool_call.function.arguments) result search_knowledge_base(**arguments) print(工具调用结果, result)5.2 工程注意点Agent 工具的稳定性是最大问题。一个工具调用链里有四五个环节任何一个环节超时、报错、返回格式不对整个任务就会断掉。建议每个工具调用都要有超时控制。工具返回值要精简不要一股脑塞进上下文。给模型提供工具失败时的备选路径。加日志记录每次工具调用参数和结果。6. 技术路线四提示词自动优化这条路线解决的是“提示词调不准”的问题。人工调提示词效率低、不稳定而用模型自动优化提示词本质上是让模型帮你做一次小规模的搜索实验。6.1 原理把“提示词优化”当成一个生成任务给定任务描述和少量示例让模型生成候选提示词再在测试集上跑一轮评估选出效果最好的版本。这个过程可以迭代多次。6.2 代码示例optimizer_prompt 你是一个提示词工程专家。请根据任务描述改进下面的提示词重点是提高模型输出的准确率。 任务描述{task_description} 当前提示词{current_prompt} 失败示例{failure_examples} 请输出改进后的提示词并简短说明修改理由。 improved_prompt_payload { model: your-optimizer-model, messages: [ {role: user, content: optimizer_prompt.format( task_description从用户问题中提取结构化查询条件, current_prompt请提取用户问题中的关键信息, failure_examples用户问‘上个月销售额最高的三个城市’模型漏掉了时间范围‘上个月’ )} ], temperature: 0.7 }优化后的提示词还需要放到测试集上跑批量评测用第 4 节的 LLM as Judge 来判断提升是否真实。注意防止过拟合如果优化只对少数几个测试样本有效说明提示词被“记住”了而不是真正变强了。7. 环境准备工作与部署思路“用 AI 增强 AI”的工程实现并不需要一套特殊的硬件环境但它对开发流程有要求。这里给出一套通用环境准备清单。7.1 基础环境操作系统LinuxUbuntu 20.04/22.04 或 CentOS 7Windows 也能跑但生产环境建议 Linux。语言环境Python 3.9 以上。模型服务可以选择 OpenAI 兼容接口也可以用 vLLM、Ollama、TGI 等框架本地起模型。数据库如果要做批量评测和结果记录建议准备一个 PostgreSQL 或 MySQL不推荐用文本文件存储评测结果。任务队列批量任务多时建议引入 Celery 或 Redis Queue避免同步调用把服务卡住。7.2 本地模型服务示例# 用 vLLM 启动一个 OpenAI 兼容接口模型名称和路径按实际替换 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name your-model-name \ --host 127.0.0.1 \ --port 8000 \ --gpu-memory-utilization 0.9启动后可以用 curl 验证接口curl http://127.0.0.1:8000/v1/models如果看到模型列表返回说明服务可用。8. 接口 API 与批量任务设计在“用 AI 增强 AI”的工程实践中接口 API 是连接各模块的骨架批量任务则是提高效率的关键。8.1 接口设计建议分成两层模型服务接口和业务封装接口。模型服务接口直接对接推理框架业务封装接口负责校验参数、组装提示词、解析结果、记录日志。app.post(/api/evaluate) async def evaluate(request: EvaluateRequest): 集成 LLM as Judge 的评估接口 result await judge_chain.run( questionrequest.question, referencerequest.reference, candidaterequest.candidate ) return { status: ok, result: result }8.2 批量任务设计批量任务建议按“目录输入 结果输出 失败重试”的方式组织。mkdir -p {inputs,outputs,logs}# 批量处理目录下所有待评测文件 import glob import json from pathlib import Path input_dir Path(./inputs) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) for file_path in sorted(input_dir.glob(*.json)): task_id file_path.stem log_path output_dir / f{task_id}.result.json # 如果结果已存在跳过断点续跑 if log_path.exists(): continue try: data json.loads(file_path.read_text(encodingutf-8)) result process_single_task(data) log_path.write_text( json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8 ) except Exception as exc: with open(output_dir / f{task_id}.error.log, w) as f: f.write(str(exc))批量任务建议加三道保险结果文件按任务 ID 命名方便断点续跑。每个任务独立记录日志和错误信息。失败任务不阻塞后续任务。9. 资源占用与性能观察方法“用 AI 增强 AI”涉及多轮模型调用资源占用比单次推理高得多。实际观察重点不是单次推理速度而是整条链路的吞吐量和稳定性。9.1 显存观察如果使用本地模型服务可以用 nvidia-smi 观察显存。需要注意模型加载后显存就占住了调用过程中显存波动不会特别大。更值得关注的是请求并发时的排队情况。建议观察四个指标模型加载后的静态显存占用。单请求推理时峰值显存。并发请求数提升后是否出现 OOM。批量任务中是否存在显存泄漏表现为长时间运行后显存持续上升。9.2 降低资源占用的手段用小模型做评估用大模型做生成。对评估任务设置 max_tokens 上限避免模型输出过多无效内容。批量请求做并发控制不要一次性打满服务。缓存重复请求结果比如相同问题、相同提示词和相同参数的结果。10. 常见问题与排查方法问题现象可能原因排查方式解决方案调用模型接口超时模型服务并发已满或单请求生成过长查看服务日志和时间线降低并发、限制 max_tokens、扩容合成数据格式解析失败模型返回了非 JSON 文本打印原始输出在提示词中约束输出格式增加重试解析逻辑LLM as Judge 打分不稳定位置偏好、长度偏好多次打乱顺序取平均交换顺序、增加温度、结合规则校验Agent 工具调用返回空值工具执行异常或参数解析错误查看工具调用日志捕获工具异常、对参数做 schema 校验批量任务跑到一半卡住某个任务依赖外部接口无响应检查超时配置为每个任务增加超时和重试机制显存不足模型过大或并发过高nvidia-smi 观察显存启用 vLLM 的 continuous batching、降低并发优化后的提示词只对测试集有效评测集过小、过拟合增加测试集多样性扩充测试集用不同来源数据验证11. 最佳实践与合规提醒工程上建议记住这几点第一次跑通时用最小配置少量数据、单条请求、小模型。保留一组固定的回归测试集每次改动提示词或模型版本后自动跑一遍。模型服务、业务服务、评测服务分层部署方便独立升级。每个请求都带上 request_id日志里能串联生成过程、评估结果和最终决策。批量任务必须可断点续跑否则数据量大时重来成本太高。涉及用户数据时优先本地部署数据不离开内网。工具调用涉及外部系统操作时必须加权限控制、操作审计和审批环节。合规方面再强调一次合成数据不得包含未授权的个人信息人脸、声音、版权素材的使用必须确认授权自动评估不能用于医疗、法律、金融等高风险决策的最终判定对外发布或商用前必须有完整的效果复核流程。“用 AI 增强 AI”不是一篇概念文章能讲完的但开头推荐的四个方向已经覆盖了大部分实际工程需要合成数据解决数据短缺LLM as Judge 解决效果评估Agent 工具调用解决能力边界提示词自动优化解决调参效率。建议第一次实践就从“LLM as Judge 批量评估”开始因为它最容易落地、风险最低、见效最快。先把评估闭环跑起来后面再做数据生成和提示词优化路线就顺了。 用AI增强AI：从合成数据到自动评估的工程实践指南
这次我们聊一个听起来有点绕、但确实是当前 AI 工程里最值得投入的方向Making AI Smarter with AI也就是“用 AI 来让 AI 变强”。先解释一下这个标题。它不是某个具体开源项目的名字而是一类工程方法论的统称当你不再满足于“用现成大模型跑推理”而是开始用大模型生成训练数据、用模型评估模型、用 Agent 调度工具、用强化反馈优化策略时你实际上就是在做“用 AI 增强 AI”这件事。这类思路在当前 AI 应用开发里几乎无处不在。很多人以为把模型拉起来、调通 API 就算完成部署但实际上真正决定一个 AI 系统上限的是后面这几层数据质量怎么来、效果怎么评估、模型跑偏了怎么修正、复杂任务怎么拆解。这些问题单独靠“换个更大的模型”解决不了必须有一套“AI 辅助 AI”的工程闭环。这篇文章会把这条技术路线拆成几个可以落地的方向来讲包括合成数据生成、LLM as Judge 自动评估、AI Agent 工具调用增强、提示词自动优化。每个方向都会给出思路、适用场景、代码示例和验证方法。如果你正在做 AI 应用开发、AI 模型部署或者准备把大模型接进自己的业务系统这篇内容可以直接当一份工程参考来看。1. 核心能力速览先把“用 AI 增强 AI”涉及的几个主流技术路线整理成一张表。按照当前 GPT 类应用和开源大模型生态的常见实践可以分成四个层次技术方向核心思路典型应用工程门槛合成数据生成用大模型生成训练/评测数据提升小模型效果微调、领域适配、数据增强低需要 API 或本地模型LLM as Judge用模型自动评估模型输出质量批量评测、效果回归、内容审核低接口调用即可AI Agent 工具调用让模型自主调用搜索、代码、数据库等工具智能体、自动化任务、工作流引擎中需要设计工具协议提示词自动优化用模型迭代改进提示词替代人工调参RAG 优化、提示词工程、推理增强中需要评估闭环强化学习反馈根据用户反馈/任务成功率更新策略推荐系统、对话策略、个性化生成高需要训练基础设施如果你关心的是本地部署那么合成数据生成和 LLM as Judge 这两条路线最轻量一台普通 GPU 机器或者纯 CPU 环境都能跑起来。Agent 工具调用则依赖具体框架比如 Function Calling 或 ReAct 模式。强化学习反馈路线最重需要你有模型训练的基础设施和稳定反馈数据源一般团队不建议上来就碰。这篇文章重点展开前四个方向最后一个只做原理说明不给出完整训练方案。2. 适用场景与使用边界先说清楚什么场景适合“用 AI 增强 AI”什么场景不适合。适合的场景有三个共同点有明确的评估标准、有可重复的任务流程、有足够的历史数据或中间结果可供分析。比如内容审核系统需要大量标注样本但人工标注成本高可以用大模型预标注再做人工抽检。企业知识库问答回答质量参差不齐需要自动评估检索效果和生成质量。代码生成助手需要判断生成代码能否通过测试用模型先做静态评估再接入编译运行验证。客服机器人需要根据用户反馈持续优化话术和工具调用策略。不适合的场景也有三个特征没有量化标准、涉及高风险决策、数据隐私边界不清楚。比如医疗诊断建议、法律意见、金融投资决策这类场景里 AI 只能做辅助不能形成“AI 评估 AI”的自动化闭环。合规上必须保留人工审核节点。使用边界必须明确合成数据不能完全替代真实数据它只能扩充分布覆盖自动评估不能完全替代人工评估尤其在主观质量项上Agent 自动调用工具时涉及外部系统操作必须加权限控制和审计日志。任何涉及人脸、声音、版权素材的内容生成都必须确认授权来源。3. 技术路线一合成数据生成这条路线解决的核心问题是真实数据不够、太贵、或者不好拿。3.1 原理用一个能力强的大模型比如 GPT-4 级别或者开源大模型生成训练样本再用这些样本去微调一个更小、更便宜、更快的小模型。常见做法有三种直接生成让大模型根据主题和格式要求生成问答对、摘要、分类样本。改写增强让大模型把已有样本改写成不同风格、不同难度、不同表述。反事实生成让大模型生成“边界情况”样本比如错误答案、模糊表述、对抗样本用于增强模型的鲁棒性。3.2 代码示例下面给出一段通用的大模型生成合成数据的 Python 示例假设你已经有一个可访问的 OpenAI 兼容接口本地也可以用 vLLM、Ollama 等框架启动同类型服务。import json import random from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) topics [Python 列表与字典区别, SQL 索引优化, Docker 容器网络模式] prompt_template 你是一个数据生成器。请为下面的技术主题生成 5 个高质量的面试问答对。 要求 1. 问题由浅入深覆盖基础概念和实际应用。 2. 答案准确不超过 150 字。 3. 输出 JSON 数组每个元素包含 question 和 answer 字段。 主题{topic} for topic in topics: user_prompt prompt_template.format(topictopic) response client.chat.completions.create( modelyour-model-name, messages[{role: user, content: user_prompt}], temperature0.8, max_tokens1500 ) content response.choices[0].message.content try: data json.loads(content) for item in data: print(json.dumps({topic: topic, **item}, ensure_asciiFalse)) except json.JSONDecodeError: print(解析失败原始输出, content)3.3 验证方式合成数据生成完不能直接用必须先做质量抽检。建议流程是随机抽 50 到 100 条人工检查准确性。检查类别分布确认没有某类样本过少。用小模型按合成数据微调在真实测试集上对比微调前后的效果。如果真实测试集提升不明显优先检查数据质量而不是继续增加数据量。4. 技术路线二LLM as Judge 自动评估这条路线解决的核心问题是生成结果好不好不能每次都靠人看。4.1 原理让一个模型当裁判给另一个模型的输出打分或者给出判断。最常见的应用是批量评测同一批问题比较不同模型或不同提示词的效果。效果回归每次更新提示词或微调版本后自动跑一遍测试集确认没有变差。内容审核让模型判断输出是否包含违规内容。评估方式可以分成三类打分式给模型输出打 1 到 5 分。对比式给出两个候选结果让模型选择哪个更好。多维式分别评估准确性、相关性、完整性、安全性等维度。4.2 代码示例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) judge_prompt 你是一个严谨的 AI 输出评估器。请对下面的问答对进行评估。 问题{question} 参考答案{reference} 待评估答案{candidate} 请从准确性、完整性、相关性三个维度打分每个维度 1-5 分。 输出 JSON 格式包含 scores 和 reason 字段。 question 什么是 RAG reference RAGRetrieval-Augmented Generation是一种将检索与生成结合的架构。 candidate RAG 是一种让模型上网搜索再回答的技术。 response client.chat.completions.create( modelyour-judge-model, messages[ {role: user, content: judge_prompt.format( questionquestion, referencereference, candidatecandidate )} ], temperature0, max_tokens500 ) print(response.choices[0].message.content)4.3 注意事项LLM as Judge 的准确性不是百分之百。常见问题包括位置偏好两个候选结果放前面和放后面模型判断会漂移。长度偏好模型倾向于认为长的答案更好。自我偏好模型对自己生成的答案打分偏高。缓解方法是多次交换顺序、增加随机种子、结合规则校验。关键业务场景一定要保留人工抽检节点不能完全自动化。5. 技术路线三AI Agent 工具调用增强这条路线解决的核心问题是模型只知道“怎么说”但不知道“怎么做”。5.1 原理给模型注册外部工具包括搜索引擎、代码执行器、数据库查询、HTTP 请求、文件读写等。模型在推理时根据用户请求决定调用哪个工具、传什么参数然后把工具返回结果继续加工最终给出答案。工程上需要做三件事工具定义用 JSON Schema 描述函数名、参数、返回值。工具注册启动时把工具列表注入模型上下文。工具执行模型返回 tool call 指令后由代码层负责真正执行。import json def search_knowledge_base(query: str) - str: # 实际调用内部知识库 return 根据知识库RAG 的完整流程包括索引构建、检索、重排和生成。 tools [ { type: function, function: { name: search_knowledge_base, description: 检索企业内部知识库, parameters: { type: object, properties: { query: { type: string, description: 检索关键词 } }, required: [query] } } } ] response client.chat.completions.create( modelyour-agent-model, messages[{role: user, content: 请解释一下 RAG 的工作流程}], toolstools, tool_choiceauto ) message response.choices[0].message if message.tool_calls: for tool_call in message.tool_calls: arguments json.loads(tool_call.function.arguments) result search_knowledge_base(**arguments) print(工具调用结果, result)5.2 工程注意点Agent 工具的稳定性是最大问题。一个工具调用链里有四五个环节任何一个环节超时、报错、返回格式不对整个任务就会断掉。建议每个工具调用都要有超时控制。工具返回值要精简不要一股脑塞进上下文。给模型提供工具失败时的备选路径。加日志记录每次工具调用参数和结果。6. 技术路线四提示词自动优化这条路线解决的是“提示词调不准”的问题。人工调提示词效率低、不稳定而用模型自动优化提示词本质上是让模型帮你做一次小规模的搜索实验。6.1 原理把“提示词优化”当成一个生成任务给定任务描述和少量示例让模型生成候选提示词再在测试集上跑一轮评估选出效果最好的版本。这个过程可以迭代多次。6.2 代码示例optimizer_prompt 你是一个提示词工程专家。请根据任务描述改进下面的提示词重点是提高模型输出的准确率。 任务描述{task_description} 当前提示词{current_prompt} 失败示例{failure_examples} 请输出改进后的提示词并简短说明修改理由。 improved_prompt_payload { model: your-optimizer-model, messages: [ {role: user, content: optimizer_prompt.format( task_description从用户问题中提取结构化查询条件, current_prompt请提取用户问题中的关键信息, failure_examples用户问‘上个月销售额最高的三个城市’模型漏掉了时间范围‘上个月’ )} ], temperature: 0.7 }优化后的提示词还需要放到测试集上跑批量评测用第 4 节的 LLM as Judge 来判断提升是否真实。注意防止过拟合如果优化只对少数几个测试样本有效说明提示词被“记住”了而不是真正变强了。7. 环境准备工作与部署思路“用 AI 增强 AI”的工程实现并不需要一套特殊的硬件环境但它对开发流程有要求。这里给出一套通用环境准备清单。7.1 基础环境操作系统LinuxUbuntu 20.04/22.04 或 CentOS 7Windows 也能跑但生产环境建议 Linux。语言环境Python 3.9 以上。模型服务可以选择 OpenAI 兼容接口也可以用 vLLM、Ollama、TGI 等框架本地起模型。数据库如果要做批量评测和结果记录建议准备一个 PostgreSQL 或 MySQL不推荐用文本文件存储评测结果。任务队列批量任务多时建议引入 Celery 或 Redis Queue避免同步调用把服务卡住。7.2 本地模型服务示例# 用 vLLM 启动一个 OpenAI 兼容接口模型名称和路径按实际替换 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name your-model-name \ --host 127.0.0.1 \ --port 8000 \ --gpu-memory-utilization 0.9启动后可以用 curl 验证接口curl http://127.0.0.1:8000/v1/models如果看到模型列表返回说明服务可用。8. 接口 API 与批量任务设计在“用 AI 增强 AI”的工程实践中接口 API 是连接各模块的骨架批量任务则是提高效率的关键。8.1 接口设计建议分成两层模型服务接口和业务封装接口。模型服务接口直接对接推理框架业务封装接口负责校验参数、组装提示词、解析结果、记录日志。app.post(/api/evaluate) async def evaluate(request: EvaluateRequest): 集成 LLM as Judge 的评估接口 result await judge_chain.run( questionrequest.question, referencerequest.reference, candidaterequest.candidate ) return { status: ok, result: result }8.2 批量任务设计批量任务建议按“目录输入 结果输出 失败重试”的方式组织。mkdir -p {inputs,outputs,logs}# 批量处理目录下所有待评测文件 import glob import json from pathlib import Path input_dir Path(./inputs) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) for file_path in sorted(input_dir.glob(*.json)): task_id file_path.stem log_path output_dir / f{task_id}.result.json # 如果结果已存在跳过断点续跑 if log_path.exists(): continue try: data json.loads(file_path.read_text(encodingutf-8)) result process_single_task(data) log_path.write_text( json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8 ) except Exception as exc: with open(output_dir / f{task_id}.error.log, w) as f: f.write(str(exc))批量任务建议加三道保险结果文件按任务 ID 命名方便断点续跑。每个任务独立记录日志和错误信息。失败任务不阻塞后续任务。9. 资源占用与性能观察方法“用 AI 增强 AI”涉及多轮模型调用资源占用比单次推理高得多。实际观察重点不是单次推理速度而是整条链路的吞吐量和稳定性。9.1 显存观察如果使用本地模型服务可以用 nvidia-smi 观察显存。需要注意模型加载后显存就占住了调用过程中显存波动不会特别大。更值得关注的是请求并发时的排队情况。建议观察四个指标模型加载后的静态显存占用。单请求推理时峰值显存。并发请求数提升后是否出现 OOM。批量任务中是否存在显存泄漏表现为长时间运行后显存持续上升。9.2 降低资源占用的手段用小模型做评估用大模型做生成。对评估任务设置 max_tokens 上限避免模型输出过多无效内容。批量请求做并发控制不要一次性打满服务。缓存重复请求结果比如相同问题、相同提示词和相同参数的结果。10. 常见问题与排查方法问题现象可能原因排查方式解决方案调用模型接口超时模型服务并发已满或单请求生成过长查看服务日志和时间线降低并发、限制 max_tokens、扩容合成数据格式解析失败模型返回了非 JSON 文本打印原始输出在提示词中约束输出格式增加重试解析逻辑LLM as Judge 打分不稳定位置偏好、长度偏好多次打乱顺序取平均交换顺序、增加温度、结合规则校验Agent 工具调用返回空值工具执行异常或参数解析错误查看工具调用日志捕获工具异常、对参数做 schema 校验批量任务跑到一半卡住某个任务依赖外部接口无响应检查超时配置为每个任务增加超时和重试机制显存不足模型过大或并发过高nvidia-smi 观察显存启用 vLLM 的 continuous batching、降低并发优化后的提示词只对测试集有效评测集过小、过拟合增加测试集多样性扩充测试集用不同来源数据验证11. 最佳实践与合规提醒工程上建议记住这几点第一次跑通时用最小配置少量数据、单条请求、小模型。保留一组固定的回归测试集每次改动提示词或模型版本后自动跑一遍。模型服务、业务服务、评测服务分层部署方便独立升级。每个请求都带上 request_id日志里能串联生成过程、评估结果和最终决策。批量任务必须可断点续跑否则数据量大时重来成本太高。涉及用户数据时优先本地部署数据不离开内网。工具调用涉及外部系统操作时必须加权限控制、操作审计和审批环节。合规方面再强调一次合成数据不得包含未授权的个人信息人脸、声音、版权素材的使用必须确认授权自动评估不能用于医疗、法律、金融等高风险决策的最终判定对外发布或商用前必须有完整的效果复核流程。“用 AI 增强 AI”不是一篇概念文章能讲完的但开头推荐的四个方向已经覆盖了大部分实际工程需要合成数据解决数据短缺LLM as Judge 解决效果评估Agent 工具调用解决能力边界提示词自动优化解决调参效率。建议第一次实践就从“LLM as Judge 批量评估”开始因为它最容易落地、风险最低、见效最快。先把评估闭环跑起来后面再做数据生成和提示词优化路线就顺了。