2026/9/11 7:45:36
FEATURED · 精选文章 
做LLM应用的人应该都遇到过这种尴尬模型能力明明不差但输出格式不符合预期、逻辑条理混乱怎么改提示词都差点意思。第一反应通常是微调但一算成本——数据清洗、标注、训练环境、版本管理投入产出比立马劝退。最近我一直在研究 Microsoft SkillOpt 这类不改模型权重只优化提示词的思路跑通之后才意识到很多时候没有必要动模型把输入侧的 Markdown 提示词当作参数去搜索反而能用极低成本拿到很明显的效果提升。这篇文章就从我在实际项目中应用 SkillOpt 的经验出发完整拆解它的核心思路、工作原理并给出可以直接参考的实战步骤和踩坑记录。如果你正在做提示工程、RAG 应用、Agent 指令设计或者单纯不想为了调格式去烧显卡微调这篇应该能帮你省下不少时间。1. 为什么不改权重反而是优势1.1 微调的隐性成本不只是显卡的事很多团队动不动就想着微调但实际上微调这条路的隐性成本远超预期。首先是数据工程你需要一批覆盖各种边界情况的训练数据清洗、去重、构建输入输出对工作量不比写业务代码小。其次是评估流程微调前要有基线训练后要在多个维度上验收稍不注意就出现某个指标涨了其他指标全崩的情况。最后还有模型版本管理一个任务微调一版权重多个任务就是多个权重文件推理服务还要做版本路由整个工程复杂度直接上了一个台阶。我之前在一个工具链项目里为了把一个 JSON 输出格式调对尝试过 LoRA 微调从准备几千条样本到训练收敛前后折腾了两周。最后复盘发现大部分问题其实是提示词结构不清晰导致的模型权重根本没毛病。这个经历让我很明确一个结论在动权重之前先确认提示词侧已经优化到位了。而 SkillOpt 解决的正是这个确认的过程它把提示词优化从手工试错变成了可量化的搜索流程。另外从我个人的判断来说微调适合的是能力缺口型问题比如模型不知道某个领域知识、不会某种推理方式而表达不对型问题比如格式乱、逻辑散、步骤不清晰绝大多数是提示词设计问题。后者用提示优化来解决成本低、见效快、回滚也方便。SkillOpt 这类框架的价值就是让后者不再依赖个人经验而是通过系统化搜索找到更优的 Markdown 表达方式。1.2 SkillOpt 的定位把提示词当参数来搜索SkillOpt 的思路很有意思它不把提示词当作一段手写的文字而是当作一组可以被搜索和优化的参数。只不过这组参数不是连续浮点数而是离散的语言片段和结构组合。它做的工作是在 Markdown 格式的提示词空间里通过优化算法搜索出一段在特定任务上表现更好的指令文本。为什么是 Markdown因为现代大模型的训练语料里包含了大量的 Markdown 文档模型对这种结构化的标记语言有很强的理解能力。标题层级、列表、表格、引用块这些标记在模型眼里天然就带有逻辑结构的暗示。比如你让模型列出三个理由和让模型用二级标题加列表的形式给出理由后者的执行稳定性明显更好。SkillOpt 的聪明之处就是把提示词搜索空间限制在 Markdown 风格的结构化文本上既缩小了搜索范围又正好踩在模型的舒适区里。我实际跑下来的感受是这相当于请了一位提示词工程师助手它不停地在 Markdown 提示词的各个位置插入指令、调整顺序、改写措辞每次改动都在验证集上跑一遍评估然后保留效果更好的版本不断迭代。整个过程中模型权重完全不变变的只是输入进去的那段 Markdown 文本。最终产出的结果是可解释的能直接看到优化后的提示词长什么样也能理解它为什么更好这一点比微调之后黑盒生效要踏实得多。2. SkillOpt 的核心机制搜索空间、目标函数与优化器2.1 定义优化目标没有指标就没有优化方向任何优化过程都必须先有目标函数SkillOpt 也不例外。在使用它之前你需要明确定义什么样的提示词是好的。这个目标函数可以是自动计算的比如分类准确率、F1 值、BLEU 分数也可以是需要人工评判的比如回答的相关性、步骤的完整性。实际项目中我建议优先选择自动可算的指标因为每轮搜索都要评估大量候选人工评估根本忙不过来。我自己常用的一种做法是把任务输出设计成结构化格式然后写一个脚本自动比对。比如让模型输出 JSON脚本直接解析 JSON 字段比对字段是否存在、取值是否正确这样评估在几十毫秒内就能完成支持大规模搜索。相反如果你做的是开放域问答评估就得靠 LLM-as-a-Judge 或者人工抽样成本会高不少搜索轮次也要相应调小。目标函数定好之后剩下的就是等待优化器去寻找最大值。这里有个经验如果任务指标本身波动很大比如模型随机性导致同一提示词多次输出分数明显不同最好对每个候选跑多次取平均否则优化器容易被噪声误导。我在实践中至少会跑 3 次取平均虽然多了几倍调用量但搜索方向会稳定很多。2.2 搜索空间设计Markdown 结构就是天然的操作单元SkillOpt 的搜索空间不是凭空产生的它基于一个初始提示词模板然后在模板基础上做修改。你可以把初始提示词想象成一个 Markdown 文档里面有几个可以动的位置标题怎么写、有没有引言段落、要求列表用有序还是无序、是否包含示例、输出格式怎么约束、语气和角色设定放在哪里。优化器的操作可以理解为几类常见的编辑动作插入在某个位置插入新的指令片段比如请先分析再回答或如果无法判断请输出 default。删除去掉某些看似重要但实际会干扰模型的内容。改写替换某一句话的措辞比如把你需要改成请务必。重排调整段落或列表的顺序让关键指令更靠前或更靠后。结构化调整把某个段落改成表格、列表或引用块增强格式引导力。这些操作组合起来搜索空间其实是巨大的不可能靠穷举。SkillOpt 的做法是用 LLM 本身来生成候选提示词——把当前的提示词列表、对应的评估分数、还有修改指令一起喂给 LLM让它脑暴出新的候选版本。这有点像创新课上的头脑风暴但每一步都带着反馈信号方向感远比随机尝试要强。从实际操作的角度看初始提示词的质量对最终结果影响很大。从一个完全不合理的提示词开始搜索可能要花很多轮才能回到正轨从一个结构清晰的 Markdown 初始提示词开始优化器只需要做小幅微调就能看到收益。我通常会把角色设定 分步指令 输出格式约束 示例作为初始模板至少保证模型能跑通然后让 SkillOpt 在这个骨架上做优化。2.3 优化器如何工作LLM 引导的离散搜索过程理解 SkillOpt 的优化器可以打一个比方你要在森林里找海拔最高的点传统梯度下降假设地形是平滑的可以一步步往高处走但提示词空间不是平滑的一个小改动可能让效果暴跌另一个小改动可能让效果暴涨像悬崖峭壁一样。这时候你需要的不是梯度而是一个熟悉地形的向导——LLM 恰好扮演了这个向导它能根据历史候选的得分生成更有可能到达高处的下一步候选。具体流程大致是这样的。第一轮优化器拿到初始提示词直接评估得到基线分数。然后维护一个候选池里面是若干提示词及其分数。每一轮迭代优化器把候选池中得分较高的一些提示词、得分信息、以及请生成新的候选提示词的要求一起发给 LLMLLM 返回若干改写后的版本。这些新版本再去验证集上跑一遍评估得分好的进入下一轮候选池得分差的直接淘汰。如此反复候选池里的提示词质量就逐渐升高。实现层面有一个值得注意的细节就是多样性控制。如果 LLM 每次生成的候选都差不多搜索很容易陷入局部最优。我在配置时会把温度参数调高一些同时要求 LLM 每次尝试不同的修改角度比如这一轮强调调整结构下一轮强调换措辞。这样才能保证搜索覆盖面足够大有机会碰到更好的组合。3. 动手实战用 SkillOpt 优化一个 Markdown 提示词3.1 环境准备与安装流程这里我以实际项目中的一次实战为例来讲解任务是从用户评论中提取产品名—问题类型二元组。先说一下环境依赖SkillOpt 本身是个训练框架但它依赖 LLM 做候选生成和推理评估所以你需要准备两样东西——一个可以调用的大语言模型 API以及一个配置好 Python 3.9 的本地环境。安装过程比较常规克隆代码仓库后安装依赖即可。需要注意的一点是这个项目会涉及大量 LLM 调用所以要确认 API key 的配额足够否则跑一半欠费中断前面所有迭代都白费了。另外建议把结果保存路径单独建一个目录每轮优化结果都会落盘方便回溯比较。git clone https://github.com/microsoft/skillopt.git cd skillopt pip install -r requirements.txt安装完成后需要准备验证集。验证集不需要太大我建议 30~50 条就足够了关键是覆盖典型场景和边界场景。比如这个评论分析任务验证集里既要有一句话能直接提取的简单例子也要有包含多个产品名的复杂例子还要有无法识别之类的情况。验证集质量比数量重要得多因为优化器是在这几十条数据上做决策的如果验证集分布和真实场景差太远优化出来的提示词在线上效果也会打折扣。3.2 配置优化任务初始 Markdown 提示词与评估函数SkillOpt 的使用方式通常是一个 Python 脚本你需要在脚本里定义三个核心部分初始提示词、评估函数、优化配置。我写了一个简化版本的配置逻辑实际使用时可以在此基础上扩展。初始提示词我用的是 Markdown 结构这是整个优化的起点# 用户评论分析任务 你是一个专业的用户反馈分析助手。请从下面的用户评论中提取所有产品名-问题类型二元组。 ## 提取规则 1. 产品名必须是评论中明确提到的产品名称 2. 问题类型分为性能问题、兼容性问题、易用性问题、其他问题 3. 如果评论未提及任何具体产品请输出 未识别 ## 输出格式 严格按照以下 Markdown 表格格式输出 | 产品名 | 问题类型 | 问题描述 | | ------ | -------- | -------- | | 示例产品 | 性能问题 | 示例描述 | ## 用户评论 {input}评估函数我直接用 Python 解析模型输出的 Markdown 表格然后和人工标注的答案做比对计算准确率def evaluate(prediction, labels): try: tables model_output_to_table(prediction) correct 0 total len(labels) if labels else 0 for item in labels: if find_in_table(tables, item[product], item[issue_type]): correct 1 return correct / max(total, 1) except Exception: return 0.0配置优化器时有几个关键参数需要留意候选数建议 8~10 个每轮都让 LLM 生成足够多的候选可以保证探索空间迭代轮数建议 10~15 轮太少优化不充分太多边际收益递减温度参数调成 0.8~1.0保证候选多样性。整个过程跑完大概需要 100~200 次 LLM 调用成本在可控范围内。3.3 运行优化与结果解读所有配置写好之后直接运行脚本。日志中会输出每一轮的最佳得分、当前最优提示词、候选池变化等信息。我第一次跑的时候基线分数是 0.71优化到第 7 轮就到了 0.78之后几轮只有小幅波动说明已经接近收敛。最有价值的部分是查看最终优化出来的 Markdown 提示词它往往和人类手写的思路不太一样。比如我那个评论分析任务优化器做的三个改动让我印象很深第一它在角色设定后面加了一句不要虚构评论中未提到的信息这直接减少了很多幻觉输出第二它把提取规则从1, 2, 3改为带加粗标题的分段结构让每个规则看起来更独立模型执行时更容易逐条遵守第三它把如果评论未提及任何具体产品请输出未识别改成了一个独立的引用块相当于给了模型一个更醒目的兜底分支。这些都是很细微的变化但如果靠人手调可能要试很久才能想到。SkillOpt 的价值就在于它把这些改动系统性地试了一遍然后用分数证明哪些有效。实际使用中优化后的提示词可以直接替换原来的手写版本模型权重不用动推理服务不用重新部署成本几乎为零。这也是我现在遇到模型表现不理想时第一个会去尝试的方法。4. 实战中的坑与排查技巧实录4.1 常见问题速查表多次运行 SkillOpt 之后我整理了一份高频问题速查表基本覆盖了新手会遇到的大部分场景问题现象可能原因解决方法优化过程分数波动很大单次评估噪声大、模型随机性高每个候选跑 3 次取平均或把验证集条数加大到 40 条以上候选提示词大同小异LLM 温度设置过低、多样性约束不足调高温度到 0.9 以上在生成 prompt 中明确要求尝试不同的结构优化后期分数停滞搜索陷入局部最优重置候选池只保留最优提示词作为种子改变改写方向重新探索调用费用快速上涨迭代轮数过多、候选数过多初始先用 5 轮做可行性验证再根据收益决定是否加大轮数优化后的提示词在验证集效果好、在真实场景差验证集分布和真实场景不一致混入真实线上数据样本特别注意覆盖长尾场景和噪声输入模型输出格式不稳定初始提示词结构不够清晰在输出格式要求中加一句只输出表格不要输出解释性文字这个表里的每一条都是我实际踩过的坑。尤其是第一条我一开始不知道评估噪声会那么严重同一个提示词跑两次分数能差出 5 个百分点导致优化器被噪声带着跑方向很混乱。后来改成 3 次取平均之后整个优化曲线立刻平滑了很多方向感也清晰了。4.2 我总结的三个实操经验经验一从一个不算太差的初始提示词开始。初始提示词决定了搜索的起点如果起点太低优化器要花大量轮次去弥补基础能力上的缺失。我建议你的初始提示词至少包含角色设定、核心指令、输出格式约束三要素最好再加一两个示例。这样 SkillOpt 就专注于微调优化而不是从零构建。经验二验证集要小而精并且要反复审视。30 条精心挑选的样本效果远好于随便扔进去的 200 条。我每次用新任务前都会先人工过一遍验证集先确认这些样本不是互相矛盾的比如同样的输入有两种不同标注。标注不一致会直接扰乱优化器让它无所适从。经验三不要只盯着最优分数要看每一轮的变化轨迹。日志里保存的不仅仅是分数还有每一轮尝试过的提示词改动。这些改动轨迹能告诉你模型偏好什么样的表达方式这对后续做其他任务的提示设计也有参考价值。有时候一个分数没涨的改动反而给你提供了改进方向。4.3 成本控制与效率优化技巧如果你在团队里用 SkillOpt成本控制是一个绕不开的话题。我的建议是先用本地小模型做一轮初筛把明显没希望的候选淘汰掉再用生产级大模型对剩余的候选做精确评估。这种方式可以节省不少 API 费用。实际操作中我会在每一轮里先让小模型给所有候选打分只保留前 50% 的版本再用主模型做正式评估整体成本差不多能省三分之一而最终效果几乎没有差别。另外建议在配置优化参数时设置一个早停条件。比如连续 5 轮最优分数提升不超过 0.5 个百分点就自动停止。这个机制可以避免无谓的调用和等待尤其是在迭代后期收益已经很小的时候强制多跑只会增加成本。5. 这类方案的适用边界与未来扩展思路5.1 什么时候提示词优化救不了你虽然 SkillOpt 在很多场景下都能发挥奇效但它不是万能的。如果你的模型本身不具备某方面的能力比如一个 7B 模型不懂复杂数学推理或者训练语料里根本没有相关知识那再优化提示词也只是小幅改善不可能带来质的飞跃。这种情况就是权重大小和预训练数据的天花板问题提示词优化触及不到那个层面。另外如果任务的评估信号非常模糊比如需要大量人工主观判断的任务SkillOpt 的搜索会非常难收敛。因为优化器在每个候选上的得分不稳定它很难判断哪个方向更优。这种情况下我建议先把任务降级比如让模型输出中间结果和理由先评估中间结果的质量再判断最终输出的合理性相当于把模糊目标拆解成几个可验证的子目标。5.2 从提示优化到工作流优化的进阶方向SkillOpt 这类提示优化思路还有一个很自然的扩展方向——不只是一个提示词可以优化整个工作流里的多个环节都能优化。比如一个 RAG 应用查询改写是提示词、检索排序是逻辑、最终回答生成是提示词这三个环节如果分别用 SkillOpt 做提示优化再把优化后结果串联起来效果提升通常比只优化最终回答要明显得多。我自己的一个实践是把整个链路的各环节提示词分别优化一遍然后把各自的优化结果组合起来整体评估发现组合后的效果比任一环节单独优化都强。这说明提示优化是可以分模块进行的特别适合模块化开发的应用架构。后续 SkillOpt 如果能做多环节联合搜索应该会把这个能力推向更大的应用空间。跑完整个流程之后我个人的体会是SkillOpt 这类方案最打动我的不是某个任务上的分数提升而是它改变了我对模型优化这件事的理解。模型权重不是唯一可以优化的对象输入侧的表达同样值得被当成一等公民来对待。如果你现在正被某个提示词效果不佳的问题困扰不妨先别急着上微调给它配一个 SkillOpt 类的搜索流程很可能几轮迭代就能帮你打开新思路。最后再分享一个小技巧定期把优化过程中那些虽然没用上但很有意思的提示词变体存档它们是理解模型行为最鲜活的第一手资料。
不微调模型也能提效？用 SkillOpt 把 Markdown 提示词当参数搜索优化
做LLM应用的人应该都遇到过这种尴尬模型能力明明不差但输出格式不符合预期、逻辑条理混乱怎么改提示词都差点意思。第一反应通常是微调但一算成本——数据清洗、标注、训练环境、版本管理投入产出比立马劝退。最近我一直在研究 Microsoft SkillOpt 这类不改模型权重只优化提示词的思路跑通之后才意识到很多时候没有必要动模型把输入侧的 Markdown 提示词当作参数去搜索反而能用极低成本拿到很明显的效果提升。这篇文章就从我在实际项目中应用 SkillOpt 的经验出发完整拆解它的核心思路、工作原理并给出可以直接参考的实战步骤和踩坑记录。如果你正在做提示工程、RAG 应用、Agent 指令设计或者单纯不想为了调格式去烧显卡微调这篇应该能帮你省下不少时间。1. 为什么不改权重反而是优势1.1 微调的隐性成本不只是显卡的事很多团队动不动就想着微调但实际上微调这条路的隐性成本远超预期。首先是数据工程你需要一批覆盖各种边界情况的训练数据清洗、去重、构建输入输出对工作量不比写业务代码小。其次是评估流程微调前要有基线训练后要在多个维度上验收稍不注意就出现某个指标涨了其他指标全崩的情况。最后还有模型版本管理一个任务微调一版权重多个任务就是多个权重文件推理服务还要做版本路由整个工程复杂度直接上了一个台阶。我之前在一个工具链项目里为了把一个 JSON 输出格式调对尝试过 LoRA 微调从准备几千条样本到训练收敛前后折腾了两周。最后复盘发现大部分问题其实是提示词结构不清晰导致的模型权重根本没毛病。这个经历让我很明确一个结论在动权重之前先确认提示词侧已经优化到位了。而 SkillOpt 解决的正是这个确认的过程它把提示词优化从手工试错变成了可量化的搜索流程。另外从我个人的判断来说微调适合的是能力缺口型问题比如模型不知道某个领域知识、不会某种推理方式而表达不对型问题比如格式乱、逻辑散、步骤不清晰绝大多数是提示词设计问题。后者用提示优化来解决成本低、见效快、回滚也方便。SkillOpt 这类框架的价值就是让后者不再依赖个人经验而是通过系统化搜索找到更优的 Markdown 表达方式。1.2 SkillOpt 的定位把提示词当参数来搜索SkillOpt 的思路很有意思它不把提示词当作一段手写的文字而是当作一组可以被搜索和优化的参数。只不过这组参数不是连续浮点数而是离散的语言片段和结构组合。它做的工作是在 Markdown 格式的提示词空间里通过优化算法搜索出一段在特定任务上表现更好的指令文本。为什么是 Markdown因为现代大模型的训练语料里包含了大量的 Markdown 文档模型对这种结构化的标记语言有很强的理解能力。标题层级、列表、表格、引用块这些标记在模型眼里天然就带有逻辑结构的暗示。比如你让模型列出三个理由和让模型用二级标题加列表的形式给出理由后者的执行稳定性明显更好。SkillOpt 的聪明之处就是把提示词搜索空间限制在 Markdown 风格的结构化文本上既缩小了搜索范围又正好踩在模型的舒适区里。我实际跑下来的感受是这相当于请了一位提示词工程师助手它不停地在 Markdown 提示词的各个位置插入指令、调整顺序、改写措辞每次改动都在验证集上跑一遍评估然后保留效果更好的版本不断迭代。整个过程中模型权重完全不变变的只是输入进去的那段 Markdown 文本。最终产出的结果是可解释的能直接看到优化后的提示词长什么样也能理解它为什么更好这一点比微调之后黑盒生效要踏实得多。2. SkillOpt 的核心机制搜索空间、目标函数与优化器2.1 定义优化目标没有指标就没有优化方向任何优化过程都必须先有目标函数SkillOpt 也不例外。在使用它之前你需要明确定义什么样的提示词是好的。这个目标函数可以是自动计算的比如分类准确率、F1 值、BLEU 分数也可以是需要人工评判的比如回答的相关性、步骤的完整性。实际项目中我建议优先选择自动可算的指标因为每轮搜索都要评估大量候选人工评估根本忙不过来。我自己常用的一种做法是把任务输出设计成结构化格式然后写一个脚本自动比对。比如让模型输出 JSON脚本直接解析 JSON 字段比对字段是否存在、取值是否正确这样评估在几十毫秒内就能完成支持大规模搜索。相反如果你做的是开放域问答评估就得靠 LLM-as-a-Judge 或者人工抽样成本会高不少搜索轮次也要相应调小。目标函数定好之后剩下的就是等待优化器去寻找最大值。这里有个经验如果任务指标本身波动很大比如模型随机性导致同一提示词多次输出分数明显不同最好对每个候选跑多次取平均否则优化器容易被噪声误导。我在实践中至少会跑 3 次取平均虽然多了几倍调用量但搜索方向会稳定很多。2.2 搜索空间设计Markdown 结构就是天然的操作单元SkillOpt 的搜索空间不是凭空产生的它基于一个初始提示词模板然后在模板基础上做修改。你可以把初始提示词想象成一个 Markdown 文档里面有几个可以动的位置标题怎么写、有没有引言段落、要求列表用有序还是无序、是否包含示例、输出格式怎么约束、语气和角色设定放在哪里。优化器的操作可以理解为几类常见的编辑动作插入在某个位置插入新的指令片段比如请先分析再回答或如果无法判断请输出 default。删除去掉某些看似重要但实际会干扰模型的内容。改写替换某一句话的措辞比如把你需要改成请务必。重排调整段落或列表的顺序让关键指令更靠前或更靠后。结构化调整把某个段落改成表格、列表或引用块增强格式引导力。这些操作组合起来搜索空间其实是巨大的不可能靠穷举。SkillOpt 的做法是用 LLM 本身来生成候选提示词——把当前的提示词列表、对应的评估分数、还有修改指令一起喂给 LLM让它脑暴出新的候选版本。这有点像创新课上的头脑风暴但每一步都带着反馈信号方向感远比随机尝试要强。从实际操作的角度看初始提示词的质量对最终结果影响很大。从一个完全不合理的提示词开始搜索可能要花很多轮才能回到正轨从一个结构清晰的 Markdown 初始提示词开始优化器只需要做小幅微调就能看到收益。我通常会把角色设定 分步指令 输出格式约束 示例作为初始模板至少保证模型能跑通然后让 SkillOpt 在这个骨架上做优化。2.3 优化器如何工作LLM 引导的离散搜索过程理解 SkillOpt 的优化器可以打一个比方你要在森林里找海拔最高的点传统梯度下降假设地形是平滑的可以一步步往高处走但提示词空间不是平滑的一个小改动可能让效果暴跌另一个小改动可能让效果暴涨像悬崖峭壁一样。这时候你需要的不是梯度而是一个熟悉地形的向导——LLM 恰好扮演了这个向导它能根据历史候选的得分生成更有可能到达高处的下一步候选。具体流程大致是这样的。第一轮优化器拿到初始提示词直接评估得到基线分数。然后维护一个候选池里面是若干提示词及其分数。每一轮迭代优化器把候选池中得分较高的一些提示词、得分信息、以及请生成新的候选提示词的要求一起发给 LLMLLM 返回若干改写后的版本。这些新版本再去验证集上跑一遍评估得分好的进入下一轮候选池得分差的直接淘汰。如此反复候选池里的提示词质量就逐渐升高。实现层面有一个值得注意的细节就是多样性控制。如果 LLM 每次生成的候选都差不多搜索很容易陷入局部最优。我在配置时会把温度参数调高一些同时要求 LLM 每次尝试不同的修改角度比如这一轮强调调整结构下一轮强调换措辞。这样才能保证搜索覆盖面足够大有机会碰到更好的组合。3. 动手实战用 SkillOpt 优化一个 Markdown 提示词3.1 环境准备与安装流程这里我以实际项目中的一次实战为例来讲解任务是从用户评论中提取产品名—问题类型二元组。先说一下环境依赖SkillOpt 本身是个训练框架但它依赖 LLM 做候选生成和推理评估所以你需要准备两样东西——一个可以调用的大语言模型 API以及一个配置好 Python 3.9 的本地环境。安装过程比较常规克隆代码仓库后安装依赖即可。需要注意的一点是这个项目会涉及大量 LLM 调用所以要确认 API key 的配额足够否则跑一半欠费中断前面所有迭代都白费了。另外建议把结果保存路径单独建一个目录每轮优化结果都会落盘方便回溯比较。git clone https://github.com/microsoft/skillopt.git cd skillopt pip install -r requirements.txt安装完成后需要准备验证集。验证集不需要太大我建议 30~50 条就足够了关键是覆盖典型场景和边界场景。比如这个评论分析任务验证集里既要有一句话能直接提取的简单例子也要有包含多个产品名的复杂例子还要有无法识别之类的情况。验证集质量比数量重要得多因为优化器是在这几十条数据上做决策的如果验证集分布和真实场景差太远优化出来的提示词在线上效果也会打折扣。3.2 配置优化任务初始 Markdown 提示词与评估函数SkillOpt 的使用方式通常是一个 Python 脚本你需要在脚本里定义三个核心部分初始提示词、评估函数、优化配置。我写了一个简化版本的配置逻辑实际使用时可以在此基础上扩展。初始提示词我用的是 Markdown 结构这是整个优化的起点# 用户评论分析任务 你是一个专业的用户反馈分析助手。请从下面的用户评论中提取所有产品名-问题类型二元组。 ## 提取规则 1. 产品名必须是评论中明确提到的产品名称 2. 问题类型分为性能问题、兼容性问题、易用性问题、其他问题 3. 如果评论未提及任何具体产品请输出 未识别 ## 输出格式 严格按照以下 Markdown 表格格式输出 | 产品名 | 问题类型 | 问题描述 | | ------ | -------- | -------- | | 示例产品 | 性能问题 | 示例描述 | ## 用户评论 {input}评估函数我直接用 Python 解析模型输出的 Markdown 表格然后和人工标注的答案做比对计算准确率def evaluate(prediction, labels): try: tables model_output_to_table(prediction) correct 0 total len(labels) if labels else 0 for item in labels: if find_in_table(tables, item[product], item[issue_type]): correct 1 return correct / max(total, 1) except Exception: return 0.0配置优化器时有几个关键参数需要留意候选数建议 8~10 个每轮都让 LLM 生成足够多的候选可以保证探索空间迭代轮数建议 10~15 轮太少优化不充分太多边际收益递减温度参数调成 0.8~1.0保证候选多样性。整个过程跑完大概需要 100~200 次 LLM 调用成本在可控范围内。3.3 运行优化与结果解读所有配置写好之后直接运行脚本。日志中会输出每一轮的最佳得分、当前最优提示词、候选池变化等信息。我第一次跑的时候基线分数是 0.71优化到第 7 轮就到了 0.78之后几轮只有小幅波动说明已经接近收敛。最有价值的部分是查看最终优化出来的 Markdown 提示词它往往和人类手写的思路不太一样。比如我那个评论分析任务优化器做的三个改动让我印象很深第一它在角色设定后面加了一句不要虚构评论中未提到的信息这直接减少了很多幻觉输出第二它把提取规则从1, 2, 3改为带加粗标题的分段结构让每个规则看起来更独立模型执行时更容易逐条遵守第三它把如果评论未提及任何具体产品请输出未识别改成了一个独立的引用块相当于给了模型一个更醒目的兜底分支。这些都是很细微的变化但如果靠人手调可能要试很久才能想到。SkillOpt 的价值就在于它把这些改动系统性地试了一遍然后用分数证明哪些有效。实际使用中优化后的提示词可以直接替换原来的手写版本模型权重不用动推理服务不用重新部署成本几乎为零。这也是我现在遇到模型表现不理想时第一个会去尝试的方法。4. 实战中的坑与排查技巧实录4.1 常见问题速查表多次运行 SkillOpt 之后我整理了一份高频问题速查表基本覆盖了新手会遇到的大部分场景问题现象可能原因解决方法优化过程分数波动很大单次评估噪声大、模型随机性高每个候选跑 3 次取平均或把验证集条数加大到 40 条以上候选提示词大同小异LLM 温度设置过低、多样性约束不足调高温度到 0.9 以上在生成 prompt 中明确要求尝试不同的结构优化后期分数停滞搜索陷入局部最优重置候选池只保留最优提示词作为种子改变改写方向重新探索调用费用快速上涨迭代轮数过多、候选数过多初始先用 5 轮做可行性验证再根据收益决定是否加大轮数优化后的提示词在验证集效果好、在真实场景差验证集分布和真实场景不一致混入真实线上数据样本特别注意覆盖长尾场景和噪声输入模型输出格式不稳定初始提示词结构不够清晰在输出格式要求中加一句只输出表格不要输出解释性文字这个表里的每一条都是我实际踩过的坑。尤其是第一条我一开始不知道评估噪声会那么严重同一个提示词跑两次分数能差出 5 个百分点导致优化器被噪声带着跑方向很混乱。后来改成 3 次取平均之后整个优化曲线立刻平滑了很多方向感也清晰了。4.2 我总结的三个实操经验经验一从一个不算太差的初始提示词开始。初始提示词决定了搜索的起点如果起点太低优化器要花大量轮次去弥补基础能力上的缺失。我建议你的初始提示词至少包含角色设定、核心指令、输出格式约束三要素最好再加一两个示例。这样 SkillOpt 就专注于微调优化而不是从零构建。经验二验证集要小而精并且要反复审视。30 条精心挑选的样本效果远好于随便扔进去的 200 条。我每次用新任务前都会先人工过一遍验证集先确认这些样本不是互相矛盾的比如同样的输入有两种不同标注。标注不一致会直接扰乱优化器让它无所适从。经验三不要只盯着最优分数要看每一轮的变化轨迹。日志里保存的不仅仅是分数还有每一轮尝试过的提示词改动。这些改动轨迹能告诉你模型偏好什么样的表达方式这对后续做其他任务的提示设计也有参考价值。有时候一个分数没涨的改动反而给你提供了改进方向。4.3 成本控制与效率优化技巧如果你在团队里用 SkillOpt成本控制是一个绕不开的话题。我的建议是先用本地小模型做一轮初筛把明显没希望的候选淘汰掉再用生产级大模型对剩余的候选做精确评估。这种方式可以节省不少 API 费用。实际操作中我会在每一轮里先让小模型给所有候选打分只保留前 50% 的版本再用主模型做正式评估整体成本差不多能省三分之一而最终效果几乎没有差别。另外建议在配置优化参数时设置一个早停条件。比如连续 5 轮最优分数提升不超过 0.5 个百分点就自动停止。这个机制可以避免无谓的调用和等待尤其是在迭代后期收益已经很小的时候强制多跑只会增加成本。5. 这类方案的适用边界与未来扩展思路5.1 什么时候提示词优化救不了你虽然 SkillOpt 在很多场景下都能发挥奇效但它不是万能的。如果你的模型本身不具备某方面的能力比如一个 7B 模型不懂复杂数学推理或者训练语料里根本没有相关知识那再优化提示词也只是小幅改善不可能带来质的飞跃。这种情况就是权重大小和预训练数据的天花板问题提示词优化触及不到那个层面。另外如果任务的评估信号非常模糊比如需要大量人工主观判断的任务SkillOpt 的搜索会非常难收敛。因为优化器在每个候选上的得分不稳定它很难判断哪个方向更优。这种情况下我建议先把任务降级比如让模型输出中间结果和理由先评估中间结果的质量再判断最终输出的合理性相当于把模糊目标拆解成几个可验证的子目标。5.2 从提示优化到工作流优化的进阶方向SkillOpt 这类提示优化思路还有一个很自然的扩展方向——不只是一个提示词可以优化整个工作流里的多个环节都能优化。比如一个 RAG 应用查询改写是提示词、检索排序是逻辑、最终回答生成是提示词这三个环节如果分别用 SkillOpt 做提示优化再把优化后结果串联起来效果提升通常比只优化最终回答要明显得多。我自己的一个实践是把整个链路的各环节提示词分别优化一遍然后把各自的优化结果组合起来整体评估发现组合后的效果比任一环节单独优化都强。这说明提示优化是可以分模块进行的特别适合模块化开发的应用架构。后续 SkillOpt 如果能做多环节联合搜索应该会把这个能力推向更大的应用空间。跑完整个流程之后我个人的体会是SkillOpt 这类方案最打动我的不是某个任务上的分数提升而是它改变了我对模型优化这件事的理解。模型权重不是唯一可以优化的对象输入侧的表达同样值得被当成一等公民来对待。如果你现在正被某个提示词效果不佳的问题困扰不妨先别急着上微调给它配一个 SkillOpt 类的搜索流程很可能几轮迭代就能帮你打开新思路。最后再分享一个小技巧定期把优化过程中那些虽然没用上但很有意思的提示词变体存档它们是理解模型行为最鲜活的第一手资料。 
