1. 项目概述为什么我们需要一个“技能检索”的基准最近和几个做LLM Agent的朋友聊天大家普遍有个感觉现在给Agent“装技能”越来越像开盲盒了。我们手里有一堆工具函数、API接口、甚至是微调好的小模型统称为“技能”。当用户问“帮我分析一下这份财报”时Agent需要从它的技能库里精准地找到“财报分析”、“数据可视化”、“生成报告”这几个技能并按正确顺序调用。这个过程就是“技能检索”。听起来简单但实际做起来坑太多了。技能描述怎么写是写“分析财务报表”还是“进行财务数据解析与趋势可视化”技能多了以后怎么避免检索到相似但错误的技能比如“发送邮件”和“群发营销邮件”可能就是两个完全不同的技能一个需要附件权限一个涉及用户列表管理。更头疼的是评估你怎么知道你的检索系统真的找对了人工看100个案例那太主观了而且规模上不去。这就是SkillRet这个大型基准出现的背景。它不是又一个玩具数据集而是瞄准了LLM Agent落地中最实际、也最混乱的一环——技能管理。我第一次看到这个项目标题时就觉得它戳中了痛点。一个大规模的基准意味着它有足够的复杂度和多样性来模拟真实世界专注于“检索”意味着它要解决的是“找得准”这个核心问题而不是泛泛地评估Agent的最终输出。对于任何正在或计划构建复杂LLM Agent的团队来说无论是做自动化办公助手、智能客服还是更垂直的行业应用SkillRet都提供了一个难得的“标尺”和“练兵场”。它能帮你客观地比较不同检索方法的好坏暴露出你技能库设计中的缺陷最终让你的Agent从“有时能蒙对”进化到“稳定可靠地找到正确工具”。2. 核心需求与设计思路拆解2.1 技能检索面临的三大核心挑战要理解SkillRet的价值得先明白在LLM Agent中做技能检索到底难在哪。根据我过去在多个项目中的经验主要可以归结为三个层面第一语义鸿沟。用户的请求是自然语言千变万化而技能的定义往往是开发者用相对固定、专业的术语描述的。比如用户说“把我上周开会记的要点整理成邮件发给老王”这个请求背后可能隐含了“读取文档”、“文本总结”、“邮件起草”、“添加收件人”等多个技能。如何将用户模糊、多意图的请求映射到技能库中离散、精确的技能条目上是第一个大难题。传统的基于关键词匹配的方法在这里完全失效。第二技能描述的模糊性与歧义性。我们自己定义技能时常常会不自觉地陷入两种极端要么过于简略如“处理数据”导致多个技能都能匹配要么过于冗长和具体把实现细节都写了进去使得技能描述本身就成了一个“小文档”反而增加了检索的难度。一个良好的技能描述应该在“功能性”这个技能能干什么和“区分性”这个技能和其他技能有何不同之间取得平衡。SkillRet基准必须能检验不同描述风格下检索器的鲁棒性。3. 评估的客观性与可扩展性。很多团队评估检索效果还停留在“人工抽查几个case看着还行”的阶段。这既不客观也无法规模化。一个科学的基准需要定义清晰的、可量化的评估指标。对于技能检索我们不能只看最终任务是否成功因为任务失败可能是执行错误而非检索错误。我们需要在“检索”这个环节就设立检查点比如通过“技能命中率”、“排序质量Mean Reciprocal Rank, MRR”等指标来单独衡量检索模块的性能。SkillRet的设计必须让这种隔离评估成为可能。2.2 SkillRet基准的预期设计目标基于上述挑战一个理想的技能检索基准我认为应该具备以下几个设计目标这也是我推测SkillRet项目会努力实现的方向大规模与高质量技能库不能是几十几百个那样没有压力测试的意义。至少需要数千甚至上万个技能涵盖通用领域如文件操作、网络搜索、信息处理和多个垂直领域如金融、法律、医疗。每个技能都需要有精心构造的、多角度的描述包括功能摘要、输入输出格式、使用约束等。真实的用户查询模拟用于测试检索器的用户查询Query不能是凭空编造的而应该源于真实场景的对话记录或任务指令。这些查询应该具有多样性包括简单指令、复合指令、含有指代和省略的模糊指令等。细粒度的标注与评估对于每一个用户查询都需要标注出“应该被检索到的正确技能集合”而且这个集合可能包含多个技能并有潜在的调用顺序。评估体系要能处理这种一对多、有顺序的复杂情况而不仅仅是简单的分类准确率。支持多种检索范式对比基准应该能公平地评估不同的检索技术路线。例如密集检索Dense Retrieval使用像BERT、Sentence-BERT或最新的Embedding模型将查询和技能描述映射到向量空间进行相似度计算。稀疏检索Sparse Retrieval如BM25基于关键词词频进行匹配。混合检索Hybrid Retrieval结合密集和稀疏检索的优点。LLM即检索器LLM-as-a-Retriever直接让大语言模型根据上下文选择技能或生成用于检索的查询改写。提供基线系统与排行榜一个好的基准会自带几个强有力的基线方法比如用Contriever、BGE等热门Embedding模型搭建的检索系统并设立一个公开的排行榜Leaderboard。这能快速让社区了解当前技术的“水位线”并激发大家迭代优化。3. 技能检索的核心技术实现路径3.1 技能库的构建与表征这是整个基准的地基也是最耗费精力的部分。一个混乱的技能库会让再好的检索器也无用武之地。技能元数据设计一个标准的技能条目远不止一个名字和一句话描述。它应该是一个结构化的数据对象。我认为一个完备的技能元数据可能包括skill_id: 唯一标识符。name: 简短、明确的技能名称如send_email。description: 核心的功能性描述用自然语言写成这是检索匹配的主要依据。input_schema: 技能所需的输入参数及其类型、格式、是否必填。例如{recipient: string, subject: string, body: string, attachments: listfile_path}。output_schema: 技能执行后的返回结果描述。constraints: 使用限制如“需要网络连接”、“仅支持PDF文件”、“单次处理不超过100条记录”。category: 技能分类如communication,data_processing,web_operation用于分层检索或后过滤。example_queries: 2-3个最能触发该技能的用户查询示例这对训练检索模型或做few-shot提示非常有帮助。技能描述的撰写艺术这里有个实操心得描述要写给“检索模型”看而不是只写给“人”看。这意味着要避免使用只有项目组内部才懂的“黑话”或缩写。要使用通用、清晰的语言并主动预判用户的多种说法。例如对于一个“将表格数据生成柱状图”的技能描述可以是“本技能接收一个结构化的数据表格如CSV、JSON根据指定列生成直观的柱状图并进行基础美化支持设置标题、轴标签和颜色主题。” 这个描述包含了核心动作“生成柱状图”、输入“结构化数据表格”、和关键特性“设置标题、轴标签”能较好地覆盖用户可能说的“画个柱状图”、“把数据可视化一下”、“给我个数据对比图”等多种查询。3.2 检索器的核心架构选型目前主流的技能检索架构可以归纳为以下三种各有优劣1. 双塔编码器Dual-Encoder架构这是目前工业界最主流、性价比最高的方案。它使用两个独立的编码器通常是同一个预训练模型的两个副本分别将用户查询Query和技能描述Skill编码成固定长度的向量Embedding。然后计算这两个向量的余弦相似度或点积作为相关性分数。优点速度快适合大规模技能库。一旦编码完成查询到来时只需做一次编码和一次向量相似度计算通常借助FAISS、Milvus等向量数据库。缺点由于查询和技能在编码时完全独立无法进行深度的交互式匹配对于复杂、多意图的查询可能捕捉不到细微差别。实操要点模型的选择至关重要。Sentence-BERT系列、OpenAI的text-embedding-ada-002、以及国内智源、商汤等开源的BGEBAAI General Embedding模型都是热门选择。关键是要在SkillRet这样的基准上进行微调Fine-tuning让模型学会在“技能检索”这个特定任务上拉近相关查询和技能的向量距离推远不相关的。2. 交叉编码器Cross-Encoder架构这种架构将查询和技能描述拼接在一起送入同一个编码器如BERT进行联合编码直接输出一个相关性分数。优点精度通常比双塔架构更高因为模型能实时看到查询和技能的完整交互信息。缺点速度慢。每次检索都需要将查询与每一个候选技能进行拼接和计算当技能库很大时比如1万个技能计算开销无法承受。因此它通常用作“重排序器Re-ranker”在双塔架构快速召回Top-K例如50个候选技能后再用交叉编码器对这50个结果进行精排选出最相关的几个。在SkillRet中的应用基准可以设计评估环节既评估“召回率”双塔架构从万级技能中找出Top-50的能力也评估“精排精度”交叉编码器从Top-50中选出Top-3的能力从而全面衡量一个检索系统的性能。3. 生成式检索Generative Retrieval或LLM直接调用这是一种较新的思路。不依赖传统的“编码-检索”模式而是将技能库视为一个“知识”让大语言模型如GPT-4直接根据上下文和指令输出它认为应该调用的技能ID或名称。优点极其灵活。LLM可以理解非常复杂的指令处理指代和省略甚至能进行一定的逻辑推理判断是否需要组合多个技能。缺点成本高、速度慢、输出不稳定可能产生技能库外的幻觉结果。并且严重依赖于Prompt工程和上下文窗口大小技能库描述如何有效地喂给LLM是个难题。SkillRet的检验价值这个基准非常适合用来检验这种方法的实际效果。通过构造需要复杂推理才能关联到正确技能的查询可以测试LLM作为检索器的上限和可靠性边界。3.3 评估指标体系的建立光有数据和模型不够还得有尺子来量。SkillRet需要一套多维度的评估指标体系。核心检索指标Hit RateK (命中率K):对于单个查询如果正确的技能出现在检索结果的前K个中则记为命中。对所有查询取平均。这是最直观的指标1, 3, 5, 10 分别衡量了系统在最严格到较宽松条件下的表现。Mean Reciprocal Rank (MRR平均倒数排名):对于每个查询计算正确技能在结果列表中排名的倒数例如排名第1则倒数为1排名第3则倒数为1/3。对所有查询取平均。这个指标对排名更敏感鼓励系统把正确答案尽量排在前面。Normalized Discounted Cumulative Gain (nDCG):当单个查询对应多个正确技能且有顺序重要性时MRR和Hit Rate就不够用了。nDCG可以评估返回列表的排序质量给予高排名位置的正确技能更高权重。面向最终任务的指标虽然SkillRet聚焦检索但检索的最终目的是服务任务完成。因此可以设计一个“下游任务成功率”的间接评估。例如给定查询和检索到的技能让一个固定的、能力已知的“技能执行器”去执行然后判断最终输出是否符合预期。这能反映出检索到的技能是否不仅相关而且是“可执行”的。实操心得指标的选择要与业务目标对齐。如果你的Agent场景对响应速度要求极高如实时对话那么Hit Rate1和MRR就比Hit Rate10更重要。如果你的场景中技能调用有严格的顺序或依赖关系那么就需要引入nDCG或自定义的排序损失来优化模型。4. 基于SkillRet基准的典型工作流程与实验假设我们现在拿到了SkillRet基准的测试集如何用它来评估和优化我们自己的技能检索系统呢下面是一个完整的实操流程。4.1 环境准备与数据加载首先我们需要搭建实验环境。这里以Python为例使用流行的Transformers库和Sentence-Transformers库。# 创建环境并安装基础依赖 conda create -n skillret_benchmark python3.9 conda activate skillret_benchmark pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 根据CUDA版本调整 pip install transformers sentence-transformers datasets faiss-cpu pandas scikit-learn # 如果需要GPU版本的FAISS加速 # pip install faiss-gpu接着模拟加载SkillRet数据。基准数据通常会以JSON或JSONL格式提供。import json from datasets import load_dataset # 假设SkillRet以Hugging Face Datasets形式提供 # dataset load_dataset(skillret/benchmark) # 这里我们模拟本地加载 def load_skillret_data(data_path): with open(data_path, r, encodingutf-8) as f: data [json.loads(line) for line in f] return data # 加载技能库 skills_data load_skillret_data(skills.jsonl) # 技能库通常是一个列表每个元素是一个技能字典 skills {s[skill_id]: s for s in skills_data} # 加载测试查询集 test_queries load_skillret_data(test_queries.jsonl) # 每个查询可能形如{query_id: q001, text: 帮我给团队发个会议通知时间是明天下午三点, relevant_skills: [send_email, schedule_meeting], ...}4.2 实现一个基于双塔模型的基线检索系统我们选用sentence-transformers库中的all-MiniLM-L6-v2模型作为基线这是一个在通用语料上训练好的轻量级句子编码模型。from sentence_transformers import SentenceTransformer, util import numpy as np class DualEncoderRetriever: def __init__(self, skills_dict, model_nameall-MiniLM-L6-v2): self.model SentenceTransformer(model_name) self.skills skills_dict # 为所有技能生成嵌入向量 self.skill_texts [f{s[name]} {s[description]} for s in self.skills.values()] self.skill_ids list(self.skills.keys()) print(fEncoding {len(self.skill_texts)} skills...) self.skill_embeddings self.model.encode(self.skill_texts, convert_to_tensorTrue, show_progress_barTrue) def retrieve(self, query_text, top_k10): # 编码查询 query_embedding self.model.encode(query_text, convert_to_tensorTrue) # 计算余弦相似度 cos_scores util.cos_sim(query_embedding, self.skill_embeddings)[0] # 获取Top-K索引 top_results np.argsort(-cos_scores.cpu().numpy())[:top_k] # 返回结果 retrieved_skills [] for idx in top_results: skill_id self.skill_ids[idx] skill_info self.skills[skill_id].copy() skill_info[score] float(cos_scores[idx]) retrieved_skills.append(skill_info) return retrieved_skills # 初始化检索器 retriever DualEncoderRetriever(skills)4.3 在测试集上进行评估现在我们用测试查询集来评估这个基线系统的性能。def evaluate_retriever(retriever, test_queries, top_k_list[1, 3, 5, 10]): hit_rates {k: 0 for k in top_k_list} reciprocal_ranks [] for query in test_queries: query_text query[text] ground_truth_ids set(query[relevant_skills]) # 假设标注了相关技能ID集合 retrieved retriever.retrieve(query_text, top_kmax(top_k_list)) retrieved_ids [item[skill_id] for item in retrieved] # 计算Hit RateK for k in top_k_list: if any(gt_id in retrieved_ids[:k] for gt_id in ground_truth_ids): hit_rates[k] 1 # 计算Reciprocal Rank (取第一个相关技能的排名) rr 0 for rank, skill_id in enumerate(retrieved_ids, start1): if skill_id in ground_truth_ids: rr 1.0 / rank break reciprocal_ranks.append(rr) # 计算平均值 num_queries len(test_queries) for k in hit_rates: hit_rates[k] / num_queries mrr np.mean(reciprocal_ranks) print( Evaluation Results ) for k in top_k_list: print(fHit Rate{k}: {hit_rates[k]:.4f}) print(fMRR: {mrr:.4f}) return hit_rates, mrr # 运行评估 hit_rates, mrr evaluate_retriever(retriever, test_queries)这个简单的基线能给我们一个性能底线。如果SkillRet基准设计得足够有挑战性这个通用模型的Hit Rate1可能不会太高这就显示了领域微调的必要性。4.4 进阶在SkillRet数据上微调检索模型为了提升性能我们需要用SkillRet或其训练集来微调双塔模型让模型学会“技能检索”这个特定任务的语义空间。from sentence_transformers import InputExample, losses, datasets from torch.utils.data import DataLoader # 1. 准备训练数据假设有训练集格式为 (query, positive_skill, negative_skill) train_examples [] # 模拟加载训练数据 train_data load_skillret_data(train_pairs.jsonl) for item in train_data: # item: {query: ..., pos_skill_text: ..., neg_skill_text: ...} example InputExample(texts[item[query], item[pos_skill_text]], label1.0) train_examples.append(example) # 对于负样本我们可以将其与查询作为负面对 # 在实际中可能需要更复杂的负采样策略如难负例挖掘 example_neg InputExample(texts[item[query], item[neg_skill_text]], label0.0) train_examples.append(example_neg) # 2. 创建数据加载器 train_dataloader DataLoader(train_examples, shuffleTrue, batch_size16) # 使用MultipleNegativesRankingLoss这是训练双塔检索模型的常用损失函数 train_loss losses.MultipleNegativesRankingLoss(modelretriever.model) # 3. 微调模型 num_epochs 3 warmup_steps int(len(train_dataloader) * num_epochs * 0.1) retriever.model.fit(train_objectives[(train_dataloader, train_loss)], epochsnum_epochs, warmup_stepswarmup_steps, output_path./fine_tuned_model, show_progress_barTrue) # 4. 加载微调后的模型并重新编码技能库 fine_tuned_model SentenceTransformer(./fine_tuned_model) retriever_finetuned DualEncoderRetriever(skills) retriever_finetuned.model fine_tuned_model retriever_finetuned.skill_embeddings fine_tuned_model.encode(retriever_finetuned.skill_texts, convert_to_tensorTrue, show_progress_barTrue) # 5. 再次评估对比性能提升 print(\n Evaluation After Fine-Tuning ) hit_rates_ft, mrr_ft evaluate_retriever(retriever_finetuned, test_queries)通过对比微调前后的指标我们可以直观地看到领域自适应带来的性能增益。这也是SkillRet基准的核心价值之一为这种优化迭代提供可靠的量化反馈。5. 常见问题、挑战与优化策略在实际使用SkillRet基准或构建技能检索系统时会遇到一系列典型问题。下面是我根据经验总结的一些“坑”和应对思路。5.1 技能库动态更新的挑战问题技能库不是一成不变的。随着Agent能力扩展新技能会不断加入。每次新增技能都重新对所有技能进行编码和构建向量索引成本很高尤其是在生产环境中。解决方案增量更新使用支持增量索引的向量数据库如Milvus、Weaviate。当新增技能时只需编码新技能并插入索引无需重建整个库。技能聚类与分层检索对技能进行聚类如按category字段。检索时先快速确定最相关的几个类别粗排再在类别内进行精细检索精排。这样新增技能只影响其所属类别的索引。元学习或持续学习研究如何让检索模型能够快速适应新技能而无需在全量数据上重新训练。但这仍是前沿研究方向。5.2 处理复杂、多意图的查询问题用户查询“帮我查一下北京明天的天气然后总结成一句话告诉我再设个下午5点的提醒”。这个查询包含了“天气查询”、“文本总结”、“设置提醒”三个技能。简单的检索可能只命中其中一个。优化策略查询分解Query Decomposition在检索前先用一个LLM如GPT-4或一个专门训练的分类器将复杂查询分解成多个原子子查询。然后对每个子查询分别进行技能检索。技能组合检索将技能库中的常见组合如“天气查询”“信息总结”也视为一种“复合技能”加入库中。检索时系统可以同时检索原子技能和预定义的复合技能。检索后重排与规划检索系统返回一个较长的候选列表如Top-20。然后由一个“规划模块”可以是规则引擎或LLM来分析整个查询从候选列表中挑选并排序出需要执行的技能序列。5.3 冷启动与少样本技能问题新上线的技能或者只有很少调用示例的技能容易被检索系统忽略或排名靠后因为模型没有足够的数据学习其表征。优化策略利用技能元数据在编码时不仅使用技能描述还将category、input_schema中的参数名等结构化信息也拼接进去为模型提供更多信号。数据增强为少样本技能人工构造或使用LLM生成更多样化的example_queries用于训练检索模型。基于内容的初始权重在向量检索的基础上引入基于技能描述与查询文本字面匹配的分数如BM25分数进行加权融合。对于新技能可以适当提高字面匹配的权重。5.4 评估中的“灰色地带”问题有些用户查询可能对应多个技能且这些技能在某种程度上都“相关”但完美解决需要的是一个特定的技能或组合。人工标注的“标准答案”可能无法覆盖所有合理情况导致评估有偏差。应对思路引入人工评估在自动评估指标之外定期对模型检索结果进行人工抽样评估判断其“实用性”而不仅仅是“匹配性”。设置多级相关性标注在基准构建时不仅标注“相关”或“不相关”还可以标注“完全相关”、“部分相关”、“边缘相关”等等级并使用像nDCG这样能处理分级相关性的指标。关注失败案例定期分析检索失败的案例特别是那些“模型认为相关但标注为不相关”或反之的案例。这往往是改进系统或修正标注的黄金机会。构建一个强大的技能检索系统远不止是调用一个Embedding API那么简单。它涉及对语义的深刻理解、对系统工程的精细设计以及对评估指标的审慎选择。SkillRet这样的基准正是将这一过程从“艺术”推向“科学”的关键一步。它迫使我们去思考、去量化、去比较最终推动整个LLM Agent生态向更可靠、更实用的方向发展。从我个人的经验来看在Agent项目中投入在技能检索模块上的优化时间其回报率往往是最高的因为它直接决定了Agent能力触达的准确性和广度。
1. 项目概述为什么我们需要一个“技能检索”的基准最近和几个做LLM Agent的朋友聊天大家普遍有个感觉现在给Agent“装技能”越来越像开盲盒了。我们手里有一堆工具函数、API接口、甚至是微调好的小模型统称为“技能”。当用户问“帮我分析一下这份财报”时Agent需要从它的技能库里精准地找到“财报分析”、“数据可视化”、“生成报告”这几个技能并按正确顺序调用。这个过程就是“技能检索”。听起来简单但实际做起来坑太多了。技能描述怎么写是写“分析财务报表”还是“进行财务数据解析与趋势可视化”技能多了以后怎么避免检索到相似但错误的技能比如“发送邮件”和“群发营销邮件”可能就是两个完全不同的技能一个需要附件权限一个涉及用户列表管理。更头疼的是评估你怎么知道你的检索系统真的找对了人工看100个案例那太主观了而且规模上不去。这就是SkillRet这个大型基准出现的背景。它不是又一个玩具数据集而是瞄准了LLM Agent落地中最实际、也最混乱的一环——技能管理。我第一次看到这个项目标题时就觉得它戳中了痛点。一个大规模的基准意味着它有足够的复杂度和多样性来模拟真实世界专注于“检索”意味着它要解决的是“找得准”这个核心问题而不是泛泛地评估Agent的最终输出。对于任何正在或计划构建复杂LLM Agent的团队来说无论是做自动化办公助手、智能客服还是更垂直的行业应用SkillRet都提供了一个难得的“标尺”和“练兵场”。它能帮你客观地比较不同检索方法的好坏暴露出你技能库设计中的缺陷最终让你的Agent从“有时能蒙对”进化到“稳定可靠地找到正确工具”。2. 核心需求与设计思路拆解2.1 技能检索面临的三大核心挑战要理解SkillRet的价值得先明白在LLM Agent中做技能检索到底难在哪。根据我过去在多个项目中的经验主要可以归结为三个层面第一语义鸿沟。用户的请求是自然语言千变万化而技能的定义往往是开发者用相对固定、专业的术语描述的。比如用户说“把我上周开会记的要点整理成邮件发给老王”这个请求背后可能隐含了“读取文档”、“文本总结”、“邮件起草”、“添加收件人”等多个技能。如何将用户模糊、多意图的请求映射到技能库中离散、精确的技能条目上是第一个大难题。传统的基于关键词匹配的方法在这里完全失效。第二技能描述的模糊性与歧义性。我们自己定义技能时常常会不自觉地陷入两种极端要么过于简略如“处理数据”导致多个技能都能匹配要么过于冗长和具体把实现细节都写了进去使得技能描述本身就成了一个“小文档”反而增加了检索的难度。一个良好的技能描述应该在“功能性”这个技能能干什么和“区分性”这个技能和其他技能有何不同之间取得平衡。SkillRet基准必须能检验不同描述风格下检索器的鲁棒性。3. 评估的客观性与可扩展性。很多团队评估检索效果还停留在“人工抽查几个case看着还行”的阶段。这既不客观也无法规模化。一个科学的基准需要定义清晰的、可量化的评估指标。对于技能检索我们不能只看最终任务是否成功因为任务失败可能是执行错误而非检索错误。我们需要在“检索”这个环节就设立检查点比如通过“技能命中率”、“排序质量Mean Reciprocal Rank, MRR”等指标来单独衡量检索模块的性能。SkillRet的设计必须让这种隔离评估成为可能。2.2 SkillRet基准的预期设计目标基于上述挑战一个理想的技能检索基准我认为应该具备以下几个设计目标这也是我推测SkillRet项目会努力实现的方向大规模与高质量技能库不能是几十几百个那样没有压力测试的意义。至少需要数千甚至上万个技能涵盖通用领域如文件操作、网络搜索、信息处理和多个垂直领域如金融、法律、医疗。每个技能都需要有精心构造的、多角度的描述包括功能摘要、输入输出格式、使用约束等。真实的用户查询模拟用于测试检索器的用户查询Query不能是凭空编造的而应该源于真实场景的对话记录或任务指令。这些查询应该具有多样性包括简单指令、复合指令、含有指代和省略的模糊指令等。细粒度的标注与评估对于每一个用户查询都需要标注出“应该被检索到的正确技能集合”而且这个集合可能包含多个技能并有潜在的调用顺序。评估体系要能处理这种一对多、有顺序的复杂情况而不仅仅是简单的分类准确率。支持多种检索范式对比基准应该能公平地评估不同的检索技术路线。例如密集检索Dense Retrieval使用像BERT、Sentence-BERT或最新的Embedding模型将查询和技能描述映射到向量空间进行相似度计算。稀疏检索Sparse Retrieval如BM25基于关键词词频进行匹配。混合检索Hybrid Retrieval结合密集和稀疏检索的优点。LLM即检索器LLM-as-a-Retriever直接让大语言模型根据上下文选择技能或生成用于检索的查询改写。提供基线系统与排行榜一个好的基准会自带几个强有力的基线方法比如用Contriever、BGE等热门Embedding模型搭建的检索系统并设立一个公开的排行榜Leaderboard。这能快速让社区了解当前技术的“水位线”并激发大家迭代优化。3. 技能检索的核心技术实现路径3.1 技能库的构建与表征这是整个基准的地基也是最耗费精力的部分。一个混乱的技能库会让再好的检索器也无用武之地。技能元数据设计一个标准的技能条目远不止一个名字和一句话描述。它应该是一个结构化的数据对象。我认为一个完备的技能元数据可能包括skill_id: 唯一标识符。name: 简短、明确的技能名称如send_email。description: 核心的功能性描述用自然语言写成这是检索匹配的主要依据。input_schema: 技能所需的输入参数及其类型、格式、是否必填。例如{recipient: string, subject: string, body: string, attachments: listfile_path}。output_schema: 技能执行后的返回结果描述。constraints: 使用限制如“需要网络连接”、“仅支持PDF文件”、“单次处理不超过100条记录”。category: 技能分类如communication,data_processing,web_operation用于分层检索或后过滤。example_queries: 2-3个最能触发该技能的用户查询示例这对训练检索模型或做few-shot提示非常有帮助。技能描述的撰写艺术这里有个实操心得描述要写给“检索模型”看而不是只写给“人”看。这意味着要避免使用只有项目组内部才懂的“黑话”或缩写。要使用通用、清晰的语言并主动预判用户的多种说法。例如对于一个“将表格数据生成柱状图”的技能描述可以是“本技能接收一个结构化的数据表格如CSV、JSON根据指定列生成直观的柱状图并进行基础美化支持设置标题、轴标签和颜色主题。” 这个描述包含了核心动作“生成柱状图”、输入“结构化数据表格”、和关键特性“设置标题、轴标签”能较好地覆盖用户可能说的“画个柱状图”、“把数据可视化一下”、“给我个数据对比图”等多种查询。3.2 检索器的核心架构选型目前主流的技能检索架构可以归纳为以下三种各有优劣1. 双塔编码器Dual-Encoder架构这是目前工业界最主流、性价比最高的方案。它使用两个独立的编码器通常是同一个预训练模型的两个副本分别将用户查询Query和技能描述Skill编码成固定长度的向量Embedding。然后计算这两个向量的余弦相似度或点积作为相关性分数。优点速度快适合大规模技能库。一旦编码完成查询到来时只需做一次编码和一次向量相似度计算通常借助FAISS、Milvus等向量数据库。缺点由于查询和技能在编码时完全独立无法进行深度的交互式匹配对于复杂、多意图的查询可能捕捉不到细微差别。实操要点模型的选择至关重要。Sentence-BERT系列、OpenAI的text-embedding-ada-002、以及国内智源、商汤等开源的BGEBAAI General Embedding模型都是热门选择。关键是要在SkillRet这样的基准上进行微调Fine-tuning让模型学会在“技能检索”这个特定任务上拉近相关查询和技能的向量距离推远不相关的。2. 交叉编码器Cross-Encoder架构这种架构将查询和技能描述拼接在一起送入同一个编码器如BERT进行联合编码直接输出一个相关性分数。优点精度通常比双塔架构更高因为模型能实时看到查询和技能的完整交互信息。缺点速度慢。每次检索都需要将查询与每一个候选技能进行拼接和计算当技能库很大时比如1万个技能计算开销无法承受。因此它通常用作“重排序器Re-ranker”在双塔架构快速召回Top-K例如50个候选技能后再用交叉编码器对这50个结果进行精排选出最相关的几个。在SkillRet中的应用基准可以设计评估环节既评估“召回率”双塔架构从万级技能中找出Top-50的能力也评估“精排精度”交叉编码器从Top-50中选出Top-3的能力从而全面衡量一个检索系统的性能。3. 生成式检索Generative Retrieval或LLM直接调用这是一种较新的思路。不依赖传统的“编码-检索”模式而是将技能库视为一个“知识”让大语言模型如GPT-4直接根据上下文和指令输出它认为应该调用的技能ID或名称。优点极其灵活。LLM可以理解非常复杂的指令处理指代和省略甚至能进行一定的逻辑推理判断是否需要组合多个技能。缺点成本高、速度慢、输出不稳定可能产生技能库外的幻觉结果。并且严重依赖于Prompt工程和上下文窗口大小技能库描述如何有效地喂给LLM是个难题。SkillRet的检验价值这个基准非常适合用来检验这种方法的实际效果。通过构造需要复杂推理才能关联到正确技能的查询可以测试LLM作为检索器的上限和可靠性边界。3.3 评估指标体系的建立光有数据和模型不够还得有尺子来量。SkillRet需要一套多维度的评估指标体系。核心检索指标Hit RateK (命中率K):对于单个查询如果正确的技能出现在检索结果的前K个中则记为命中。对所有查询取平均。这是最直观的指标1, 3, 5, 10 分别衡量了系统在最严格到较宽松条件下的表现。Mean Reciprocal Rank (MRR平均倒数排名):对于每个查询计算正确技能在结果列表中排名的倒数例如排名第1则倒数为1排名第3则倒数为1/3。对所有查询取平均。这个指标对排名更敏感鼓励系统把正确答案尽量排在前面。Normalized Discounted Cumulative Gain (nDCG):当单个查询对应多个正确技能且有顺序重要性时MRR和Hit Rate就不够用了。nDCG可以评估返回列表的排序质量给予高排名位置的正确技能更高权重。面向最终任务的指标虽然SkillRet聚焦检索但检索的最终目的是服务任务完成。因此可以设计一个“下游任务成功率”的间接评估。例如给定查询和检索到的技能让一个固定的、能力已知的“技能执行器”去执行然后判断最终输出是否符合预期。这能反映出检索到的技能是否不仅相关而且是“可执行”的。实操心得指标的选择要与业务目标对齐。如果你的Agent场景对响应速度要求极高如实时对话那么Hit Rate1和MRR就比Hit Rate10更重要。如果你的场景中技能调用有严格的顺序或依赖关系那么就需要引入nDCG或自定义的排序损失来优化模型。4. 基于SkillRet基准的典型工作流程与实验假设我们现在拿到了SkillRet基准的测试集如何用它来评估和优化我们自己的技能检索系统呢下面是一个完整的实操流程。4.1 环境准备与数据加载首先我们需要搭建实验环境。这里以Python为例使用流行的Transformers库和Sentence-Transformers库。# 创建环境并安装基础依赖 conda create -n skillret_benchmark python3.9 conda activate skillret_benchmark pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 根据CUDA版本调整 pip install transformers sentence-transformers datasets faiss-cpu pandas scikit-learn # 如果需要GPU版本的FAISS加速 # pip install faiss-gpu接着模拟加载SkillRet数据。基准数据通常会以JSON或JSONL格式提供。import json from datasets import load_dataset # 假设SkillRet以Hugging Face Datasets形式提供 # dataset load_dataset(skillret/benchmark) # 这里我们模拟本地加载 def load_skillret_data(data_path): with open(data_path, r, encodingutf-8) as f: data [json.loads(line) for line in f] return data # 加载技能库 skills_data load_skillret_data(skills.jsonl) # 技能库通常是一个列表每个元素是一个技能字典 skills {s[skill_id]: s for s in skills_data} # 加载测试查询集 test_queries load_skillret_data(test_queries.jsonl) # 每个查询可能形如{query_id: q001, text: 帮我给团队发个会议通知时间是明天下午三点, relevant_skills: [send_email, schedule_meeting], ...}4.2 实现一个基于双塔模型的基线检索系统我们选用sentence-transformers库中的all-MiniLM-L6-v2模型作为基线这是一个在通用语料上训练好的轻量级句子编码模型。from sentence_transformers import SentenceTransformer, util import numpy as np class DualEncoderRetriever: def __init__(self, skills_dict, model_nameall-MiniLM-L6-v2): self.model SentenceTransformer(model_name) self.skills skills_dict # 为所有技能生成嵌入向量 self.skill_texts [f{s[name]} {s[description]} for s in self.skills.values()] self.skill_ids list(self.skills.keys()) print(fEncoding {len(self.skill_texts)} skills...) self.skill_embeddings self.model.encode(self.skill_texts, convert_to_tensorTrue, show_progress_barTrue) def retrieve(self, query_text, top_k10): # 编码查询 query_embedding self.model.encode(query_text, convert_to_tensorTrue) # 计算余弦相似度 cos_scores util.cos_sim(query_embedding, self.skill_embeddings)[0] # 获取Top-K索引 top_results np.argsort(-cos_scores.cpu().numpy())[:top_k] # 返回结果 retrieved_skills [] for idx in top_results: skill_id self.skill_ids[idx] skill_info self.skills[skill_id].copy() skill_info[score] float(cos_scores[idx]) retrieved_skills.append(skill_info) return retrieved_skills # 初始化检索器 retriever DualEncoderRetriever(skills)4.3 在测试集上进行评估现在我们用测试查询集来评估这个基线系统的性能。def evaluate_retriever(retriever, test_queries, top_k_list[1, 3, 5, 10]): hit_rates {k: 0 for k in top_k_list} reciprocal_ranks [] for query in test_queries: query_text query[text] ground_truth_ids set(query[relevant_skills]) # 假设标注了相关技能ID集合 retrieved retriever.retrieve(query_text, top_kmax(top_k_list)) retrieved_ids [item[skill_id] for item in retrieved] # 计算Hit RateK for k in top_k_list: if any(gt_id in retrieved_ids[:k] for gt_id in ground_truth_ids): hit_rates[k] 1 # 计算Reciprocal Rank (取第一个相关技能的排名) rr 0 for rank, skill_id in enumerate(retrieved_ids, start1): if skill_id in ground_truth_ids: rr 1.0 / rank break reciprocal_ranks.append(rr) # 计算平均值 num_queries len(test_queries) for k in hit_rates: hit_rates[k] / num_queries mrr np.mean(reciprocal_ranks) print( Evaluation Results ) for k in top_k_list: print(fHit Rate{k}: {hit_rates[k]:.4f}) print(fMRR: {mrr:.4f}) return hit_rates, mrr # 运行评估 hit_rates, mrr evaluate_retriever(retriever, test_queries)这个简单的基线能给我们一个性能底线。如果SkillRet基准设计得足够有挑战性这个通用模型的Hit Rate1可能不会太高这就显示了领域微调的必要性。4.4 进阶在SkillRet数据上微调检索模型为了提升性能我们需要用SkillRet或其训练集来微调双塔模型让模型学会“技能检索”这个特定任务的语义空间。from sentence_transformers import InputExample, losses, datasets from torch.utils.data import DataLoader # 1. 准备训练数据假设有训练集格式为 (query, positive_skill, negative_skill) train_examples [] # 模拟加载训练数据 train_data load_skillret_data(train_pairs.jsonl) for item in train_data: # item: {query: ..., pos_skill_text: ..., neg_skill_text: ...} example InputExample(texts[item[query], item[pos_skill_text]], label1.0) train_examples.append(example) # 对于负样本我们可以将其与查询作为负面对 # 在实际中可能需要更复杂的负采样策略如难负例挖掘 example_neg InputExample(texts[item[query], item[neg_skill_text]], label0.0) train_examples.append(example_neg) # 2. 创建数据加载器 train_dataloader DataLoader(train_examples, shuffleTrue, batch_size16) # 使用MultipleNegativesRankingLoss这是训练双塔检索模型的常用损失函数 train_loss losses.MultipleNegativesRankingLoss(modelretriever.model) # 3. 微调模型 num_epochs 3 warmup_steps int(len(train_dataloader) * num_epochs * 0.1) retriever.model.fit(train_objectives[(train_dataloader, train_loss)], epochsnum_epochs, warmup_stepswarmup_steps, output_path./fine_tuned_model, show_progress_barTrue) # 4. 加载微调后的模型并重新编码技能库 fine_tuned_model SentenceTransformer(./fine_tuned_model) retriever_finetuned DualEncoderRetriever(skills) retriever_finetuned.model fine_tuned_model retriever_finetuned.skill_embeddings fine_tuned_model.encode(retriever_finetuned.skill_texts, convert_to_tensorTrue, show_progress_barTrue) # 5. 再次评估对比性能提升 print(\n Evaluation After Fine-Tuning ) hit_rates_ft, mrr_ft evaluate_retriever(retriever_finetuned, test_queries)通过对比微调前后的指标我们可以直观地看到领域自适应带来的性能增益。这也是SkillRet基准的核心价值之一为这种优化迭代提供可靠的量化反馈。5. 常见问题、挑战与优化策略在实际使用SkillRet基准或构建技能检索系统时会遇到一系列典型问题。下面是我根据经验总结的一些“坑”和应对思路。5.1 技能库动态更新的挑战问题技能库不是一成不变的。随着Agent能力扩展新技能会不断加入。每次新增技能都重新对所有技能进行编码和构建向量索引成本很高尤其是在生产环境中。解决方案增量更新使用支持增量索引的向量数据库如Milvus、Weaviate。当新增技能时只需编码新技能并插入索引无需重建整个库。技能聚类与分层检索对技能进行聚类如按category字段。检索时先快速确定最相关的几个类别粗排再在类别内进行精细检索精排。这样新增技能只影响其所属类别的索引。元学习或持续学习研究如何让检索模型能够快速适应新技能而无需在全量数据上重新训练。但这仍是前沿研究方向。5.2 处理复杂、多意图的查询问题用户查询“帮我查一下北京明天的天气然后总结成一句话告诉我再设个下午5点的提醒”。这个查询包含了“天气查询”、“文本总结”、“设置提醒”三个技能。简单的检索可能只命中其中一个。优化策略查询分解Query Decomposition在检索前先用一个LLM如GPT-4或一个专门训练的分类器将复杂查询分解成多个原子子查询。然后对每个子查询分别进行技能检索。技能组合检索将技能库中的常见组合如“天气查询”“信息总结”也视为一种“复合技能”加入库中。检索时系统可以同时检索原子技能和预定义的复合技能。检索后重排与规划检索系统返回一个较长的候选列表如Top-20。然后由一个“规划模块”可以是规则引擎或LLM来分析整个查询从候选列表中挑选并排序出需要执行的技能序列。5.3 冷启动与少样本技能问题新上线的技能或者只有很少调用示例的技能容易被检索系统忽略或排名靠后因为模型没有足够的数据学习其表征。优化策略利用技能元数据在编码时不仅使用技能描述还将category、input_schema中的参数名等结构化信息也拼接进去为模型提供更多信号。数据增强为少样本技能人工构造或使用LLM生成更多样化的example_queries用于训练检索模型。基于内容的初始权重在向量检索的基础上引入基于技能描述与查询文本字面匹配的分数如BM25分数进行加权融合。对于新技能可以适当提高字面匹配的权重。5.4 评估中的“灰色地带”问题有些用户查询可能对应多个技能且这些技能在某种程度上都“相关”但完美解决需要的是一个特定的技能或组合。人工标注的“标准答案”可能无法覆盖所有合理情况导致评估有偏差。应对思路引入人工评估在自动评估指标之外定期对模型检索结果进行人工抽样评估判断其“实用性”而不仅仅是“匹配性”。设置多级相关性标注在基准构建时不仅标注“相关”或“不相关”还可以标注“完全相关”、“部分相关”、“边缘相关”等等级并使用像nDCG这样能处理分级相关性的指标。关注失败案例定期分析检索失败的案例特别是那些“模型认为相关但标注为不相关”或反之的案例。这往往是改进系统或修正标注的黄金机会。构建一个强大的技能检索系统远不止是调用一个Embedding API那么简单。它涉及对语义的深刻理解、对系统工程的精细设计以及对评估指标的审慎选择。SkillRet这样的基准正是将这一过程从“艺术”推向“科学”的关键一步。它迫使我们去思考、去量化、去比较最终推动整个LLM Agent生态向更可靠、更实用的方向发展。从我个人的经验来看在Agent项目中投入在技能检索模块上的优化时间其回报率往往是最高的因为它直接决定了Agent能力触达的准确性和广度。
