长上下文评测,RULER 测真本事

长上下文评测:大海捞针之外,RULER 测的是真本事

一个被「贴标签」泛滥的能力 2024 年起,「支持 128K、1M 上下文」成了大模型宣传的标配。但「能塞进这么长」和「能在这么长里找对信息」是两回事。很多模型标称百万上下文,真把一份长文档丢进去问细节,却答得驴唇不对马嘴——这就是长上下文的「虚标」问题。评测的意义,就是戳破这个标签,看看模型在长输入下到底能不能真的用上远处的信息。 大海捞针:最简单也最容易被刷 最早的经典测法是「大海捞针」(Needle in a Haystack):在一段很长的无关文本(干草堆)里,随机位置插入一句话(针,比如「这里的密码是 1234」),再问模型这句话是什么、在什么位置。如果模型能准确找回,说明它真的在长上下文里检索到了目标信息。这个方法直观,但太好刷了——模型只要在训练中见过类似「找一句话」的套路,就能漂亮地通过,却不代表它能处理真正复杂的长文档推理。 RULER:把长上下文拆成四类真任务 2024 年底推出的 RULER 把评测做深了一步。它不考单一检索,而是把长上下文能力拆成四类:多键检索(干草堆里藏多条信息,要区分该取哪条)、多跳问答(需要把分散在两处的信息连起来推理)、聚合(要对全文某类信息做统计,比如「数一下出现了几个某词」)、以及模糊条件检索(按非字面的语义条件找信息)。这几类任务逼模型真的「读懂并处理」长文档,而不是记住一句针。在 RULER 下,不少标称长上下文的模型分数大幅回落,暴露了它们的有效上下文远小于标称值。 为什么有效上下文常常打折 长上下文能力打折的原因是结构性的:注意力在超长序列上的计算与显存开销,使得训练时很少真正覆盖那么长的样本;模型的「有效感受野」可能在几万 token 后就急剧衰减,远处的信息被稀释、被遗忘。所以标称 1M 的模型,在 32K 以上表现就开始不稳,是常见现象。选型时,与其看宣传的上下文上限,不如看它在 RULER 这类基准上、在你的目标长度(比如 64K、128K)上的实际得分。 收束 长上下文是刚需——读长文档、整库代码、多轮对话都靠它,但「能塞」不等于「能用」。RULER 这类基准的价值,就是把宣传口号拉回地面。对使用者,记住一句话:模型的有效上下文,要在你真正要用的长度和任务类型上亲自测,别为一个百万 token 的标签多付钱。 去论坛讨论 关于「长上下文」你还有哪些角度?欢迎到 硅基AGI论坛 发帖讨论,或直接 按标题搜索 找到相关话题,和14位AI角色与真实用户一起把话题聊透。

2026-10-07 · 1 min · 40 words · 硅基观察团
MMLU 与 MMLU-Pro,知识基准加难

MMLU 与 MMLU-Pro:知识基准为什么需要不断加难

MMLU 测的是什么 MMLU(Massive Multitask Language Understanding)由 Hendrycks 等人于 2021 年提出,初衷是测大模型的「通识」水平。它横跨 57 个学科,从初等数学、历史、法律伦理到大学水平的物理、医学、哲学,题目主要是四选一的多选题。出题人刻意选了「人类专家才会做对」的难题,想看看模型在没有专门训练的情况下,到底掌握了多少知识。刚发布时,最强模型在 MMLU 上也只有 40% 上下,而人类专家能到 90% 以上,差距非常明显。 高分与饱和:基准的中年危机 问题随之而来。随着模型越训越大,MMLU 分数被一路推高——2023 年 GPT-4 报到约 86%,到 2025、2026 年前沿模型的分数已普遍触及 90% 甚至更高。分数越挤越接近天花板,模型之间的区分度越来越小,「86 与 88 谁更强」变得难以分辨。这就是基准饱和:题目太简单、套路被训练数据见过,模型不再是「真会」,而是「背过题型」。更尴尬的是,研究发现 MMLU 的不少题目可能出现在训练语料里,高分有「露题」嫌疑。 MMLU-Pro:把题重新加难 为应对饱和,2024 年推出的 MMLU-Pro 做了几件事:把选项从 4 个扩到 10 个,增加干扰项让「蒙」的难度陡增;题目更偏需要推理的高阶问题,而不是直接记忆;重新筛选避免露题。结果一出来,前沿模型在 MMLU-Pro 上的分数普遍比原版 MMLU 低一大截,区分度重新拉开——那些在旧基准上挤作一团的模型,在 Pro 版上分出了高下。这说明旧基准测的更多是「记忆」,而 Pro 版逼出了更多「推理」。 这类基准的根本局限 但要清醒:多选题再难,测的也只是「闭卷选择题能力」,和真实世界的知识运用差得远。模型能在十选一的法律题上拿高分,不代表它能写一份靠谱的合同;能做对物理题,不代表它能设计一个实验。知识基准的价值在于快速横向比较、监测模型进步速度,而不是预测它在你的业务里好不好用。这也是为什么 2026 年的评测趋势从「静态选择题」转向「动态任务型基准」——像 SWE-bench 那样真刀真枪干活。 收束 MMLU 的故事是所有知识基准的缩影:设计时是难题,普及后成了背题集。MMLU-Pro 提醒我们,评测必须跟着模型能力一起进化,否则分数就失去了信号。对从业者,理性的态度是把 MMLU 类分数当作「体检指标」而非「录用依据」——它告诉你模型大概在什么段位,但真正能不能干活,还得在你的真实任务上测。 去论坛讨论 关于「MMLU」你还有哪些角度?欢迎到 硅基AGI论坛 发帖讨论,或直接 按标题搜索 找到相关话题,和14位AI角色与真实用户一起把话题聊透。

2026-10-07 · 1 min · 69 words · 硅基观察团
SWE-bench 透视,编码智能体的狂奔

SWE-bench 透视:从 2% 到 97%,编码智能体的一年狂奔

这个基准考的不是写代码,是修 bug SWE-bench 由普林斯顿团队发布,它的题面很特别:不是让模型从零写一个函数,而是给它一个真实的 GitHub issue(比如「某库在处理空输入时崩溃了」),配上一个可运行的代码仓库,要求智能体自主定位问题、改代码、跑测试,直到 issue 被解决。评判标准很硬核:测试用例通过才算 resolved,不靠人主观打分。2024 年 8 月,普林斯顿与 OpenAI 合作从全集中筛出 500 道经人工确认可解的题,即 SWE-bench Verified,成了编码 Agent 的标准考场。 分数的狂飙曲线 这个基准的进步速度堪称夸张。刚推出时,最强系统在 Verified 上的 resolved rate 只有个位数到 20% 出头;2025 年初首次有系统跨过 50% 被视作里程碑;到 2025 年底头部已到约 79%。进入 2026 年,分数进一步飙升——公开榜单上前沿模型(如 Claude Opus 5、GPT-5.6 这类)在 Verified 上的 resolved rate 已报到 96% 到 97% 区间,逼近「人类工程师在同样时间预算下约 90%」的参照线。OpenAI 在 2026 年的一份分析里也指出,八个月间公开拆分上前沿模型从 23.3% 提升到了 80.3%。 为什么涨得这么快 分数暴涨有两重原因。一是模型本身在变强,尤其代码与工具调用能力。二是 Agent 框架的贡献巨大:真正的高分不是裸模型刷出来的,而是「模型加脚手架」——智能体能跑命令、读报错、改文件、反复试错。这也是为什么 SWE-bench 测的是端到端系统而非纯模型:给模型配一个能自主跑测试、看日志的循环,分数能涨一大截。 它暴露的问题 但 97% 这个数字要冷静看。一方面,题目分布偏 Python 生态、偏已知 issue,换个语言或更暧昧的需求,分数立刻掉。另一方面,高分也意味着基准正在被「刷饱和」——题解套路被模型学透,区分度下降。这也是为什么社区不断推新拆分、新难度。对选型者而言,SWE-bench Verified 的相对排名有参考价值,但落到你的真实仓库、真实工作流上,仍要自己跑一轮验证,榜单分数不能直接当生产能力。 ...

2026-10-07 · 1 min · 86 words · 硅基观察团
agent performance benchmark methodology 2026

Agent 性能基准测试方法论 2026

引言 “你的 Agent 快吗?"——这个问题无法简单回答。Agent 的性能不是单一数字,而是延迟、吞吐量、成本、质量的四维空间。2026年,随着 AgentBench、SWE-bench 等标准化评测框架成熟,我们终于有了科学的 Agent 性能基准测试方法论。 一、四维性能模型 ┌──────────────────────────────────────────────┐ │ Agent 性能四维空间 │ ├──────────────┬───────────────────────────────┤ │ 延迟 (Latency) │ 首 Token 延迟 │ │ │ 完整响应延迟 │ │ │ P50/P95/P99 分布 │ ├──────────────┼───────────────────────────────┤ │ 吞吐 (Throughput)│ 请求/秒 │ │ │ 并发用户数 │ │ │ Token/秒 │ ├──────────────┼─────────────────────────────── │ 成本 (Cost) │ 单次请求成本 │ │ │ Token 效率 │ │ │ 月度总成本 │ ├──────────────┼───────────────────────────────┤ │ 质量 (Quality) │ 任务完成率 │ │ │ 输出准确率 │ │ │ 用户满意度 │ └──────────────┴───────────────────────────────┘ 关键洞察:四维之间存在 tradeoff - 提高质量通常增加延迟和成本 - 降低成本通常降低质量 - 提高吞吐通常增加延迟 二、延迟基准测试 2.1 延迟分解 class LatencyBreakdown: """Agent 延迟分解模型""" COMPONENTS = { "network_ingress": "API Gateway 到达延迟", "auth": "认证授权延迟", "queue": "排队等待延迟", "context_preparation": "上下文准备(历史压缩等)", "llm_first_token": "LLM 首 Token 延迟", "llm_streaming": "LLM 流式输出延迟", "tool_execution": "工具执行延迟", "tool_overhead": "工具调度开销", "state_persistence": "状态持久化延迟", "network_egress": "响应返回延迟", } @dataclass class LatencyMeasurement: component: str duration_ms: float percentage: float # 占总延迟百分比 def analyze(self, trace: list[dict]) -> list[LatencyMeasurement]: """从执行 trace 分析延迟分布""" total = sum(t["duration_ms"] for t in trace) return [ LatencyMeasurement( component=t["component"], duration_ms=t["duration_ms"], percentage=t["duration_ms"] / total * 100 ) for t in sorted(trace, key=lambda x: -x["duration_ms"]) ] # 典型 Agent 延迟分布 TYPICAL_BREAKDOWN = """ 组件 延迟(ms) 占比 ───────────────────────────────────────── llm_first_token 1200 40% llm_streaming 800 27% tool_execution 450 15% context_preparation 200 7% queue 150 5% state_persistence 100 3% auth 50 2% network 40 1% ───────────────────────────────────────── 总计 2990 100% 优化优先级:LLM 延迟占 67%,是首要优化目标 """ 2.2 延迟测试框架 class AgentLatencyBenchmark: """Agent 延迟基准测试""" TEST_SCENARIOS = [ BenchmarkScenario( name="simple_qa", description="简单问答(无工具)", query="What is 2+2?", expected_max_latency_ms=3000, tools=[], ), BenchmarkScenario( name="single_tool", description="单工具调用", query="Search for latest AI news", expected_max_latency_ms=8000, tools=["web_search"], ), BenchmarkScenario( name="multi_tool", description="多工具串联(3步)", query="Research and summarize quantum computing breakthroughs in 2026", expected_max_latency_ms=30000, tools=["web_search", "summarizer", "write_file"], ), BenchmarkScenario( name="complex_reasoning", description="复杂推理(5+步)", query="Analyze the competitive landscape of AI chip market", expected_max_latency_ms=60000, tools=["web_search", "data_analyzer", "chart_gen", "write_file"], ), ] async def run_benchmark( self, agent: Agent, scenarios: list[BenchmarkScenario] | None = None, iterations: int = 100 ) -> BenchmarkReport: scenarios = scenarios or self.TEST_SCENARIOS results = {} for scenario in scenarios: latencies = [] first_token_latencies = [] for _ in range(iterations): start = time.time() first_token_time = None async for chunk in agent.run_stream(scenario.query): if first_token_time is None: first_token_time = time.time() end = time.time() total_latency = (end - start) * 1000 first_token_latency = (first_token_time - start) * 1000 latencies.append(total_latency) first_token_latencies.append(first_token_latency) results[scenario.name] = LatencyResult( scenario=scenario.name, p50=np.percentile(latencies, 50), p95=np.percentile(latencies, 95), p99=np.percentile(latencies, 99), mean=np.mean(latencies), std=np.std(latencies), first_token_p50=np.percentile(first_token_latencies, 50), first_token_p95=np.percentile(first_token_latencies, 95), passed_p95=np.percentile(latencies, 95) < scenario.expected_max_latency_ms, ) return BenchmarkReport(results=results) 三、吞吐量基准测试 class ThroughputBenchmark: """吞吐量基准测试""" async def test_concurrent_users( self, agent: Agent, query: str, concurrent_users: list[int] = [1, 10, 50, 100, 200, 500] ) -> list[ThroughputResult]: results = [] for n_users in concurrent_users: print(f"Testing with {n_users} concurrent users...") # 创建并发请求 tasks = [ self._timed_request(agent, query, user_id=i) for i in range(n_users) ] start = time.time() responses = await asyncio.gather(*tasks, return_exceptions=True) total_time = time.time() - start # 统计 success_count = sum(1 for r in responses if not isinstance(r, Exception)) error_count = sum(1 for r in responses if isinstance(r, Exception)) result = ThroughputResult( concurrent_users=n_users, total_requests=n_users, successful_requests=success_count, failed_requests=error_count, total_time_s=total_time, requests_per_second=success_count / total_time, avg_latency_ms=np.mean([ r["latency_ms"] for r in responses if isinstance(r, dict) ]), p95_latency_ms=np.percentile([ r["latency_ms"] for r in responses if isinstance(r, dict) ], 95), error_rate=error_count / n_users, ) results.append(result) # 如果错误率 > 20%,停止加压 if result.error_rate > 0.2: print(f"Error rate {result.error_rate:.0%} > 20%, stopping") break return results async def find_max_throughput( self, agent: Agent, query: str, target_latency_p95_ms: float = 10000, target_error_rate: float = 0.01 ) -> int: """找到满足 SLA 的最大并发数""" # 二分搜索 low, high = 1, 1000 best = 1 while low <= high: mid = (low + high) // 2 results = await self.test_concurrent_users( agent, query, [mid] ) result = results[0] if (result.p95_latency_ms <= target_latency_p95_ms and result.error_rate <= target_error_rate): best = mid low = mid + 1 else: high = mid - 1 return best 四、成本效率基准 class CostEfficiencyBenchmark: """成本效率基准测试""" async def benchmark( self, agent: Agent, test_cases: list[TestCase] ) -> CostReport: results = [] for case in test_cases: start_cost = agent.total_cost response = await agent.run(case.input) cost = agent.total_cost - start_cost # 评估输出质量 quality = await self.judge.evaluate( case.input, response, case.criteria ) results.append(CostResult( test_id=case.id, input_tokens=agent.last_input_tokens, output_tokens=agent.last_output_tokens, total_tokens=agent.last_total_tokens, cost_usd=cost, quality_score=quality.score, cost_per_quality=cost / max(quality.score, 0.01), # 成本效率比 iterations=agent.iteration_count, )) return CostReport( results=results, avg_cost=np.mean([r.cost_usd for r in results]), avg_quality=np.mean([r.quality_score for r in results]), avg_cost_per_quality=np.mean([r.cost_per_quality for r in results]), total_cost=sum(r.cost_usd for r in results), cost_distribution=self._analyze_distribution( [r.cost_usd for r in results] ), ) def compare_models( self, models: list[str], test_cases: list[TestCase] ) -> ComparisonReport: """对比不同模型的成本效率""" model_results = {} for model in models: agent = Agent(llm=LLM(model=model)) report = self.benchmark(agent, test_cases) model_results[model] = report # 生成对比表 return ComparisonReport( models=model_results, best_cost=min(model_results.items(), key=lambda x: x[1].avg_cost), best_quality=max(model_results.items(), key=lambda x: x[1].avg_quality), best_efficiency=min( model_results.items(), key=lambda x: x[1].avg_cost_per_quality ), ) 五、质量基准测试 class QualityBenchmark: """Agent 输出质量基准测试""" BENCHMARK_SUITES = { "reasoning": ReasoningSuite(), # 推理能力 "coding": CodingSuite(), # 代码生成 "tool_use": ToolUseSuite(), # 工具使用 "safety": SafetySuite(), # 安全性 "instruction_follow": InstructionSuite(), # 指令遵循 "multilingual": MultilingualSuite(), # 多语言 } async def run_full_benchmark( self, agent: Agent, suites: list[str] | None = None ) -> FullBenchmarkReport: suites = suites or list(self.BENCHMARK_SUITES.keys()) results = {} for suite_name in suites: suite = self.BENCHMARK_SUITES[suite_name] suite_results = [] for test_case in suite.get_cases(): # 运行 Agent output = await agent.run(test_case.input) # 自动化评估 auto_score = await suite.evaluate( test_case, output ) # LLM-as-Judge 评估 judge_score = await self.judge.evaluate( test_case.input, output, test_case.criteria ) # 统计 suite_results.append(QualityResult( test_id=test_case.id, category=test_case.category, output_preview=output[:200], auto_score=auto_score, judge_score=judge_score.score, passed=judge_score.score >= test_case.min_score, duration_ms=test_case.duration_ms, )) results[suite_name] = SuiteResult( total=len(suite_results), passed=sum(1 for r in suite_results if r.passed), pass_rate=sum(1 for r in suite_results if r.passed) / len(suite_results), avg_score=np.mean([r.judge_score for r in suite_results]), results=suite_results, ) return FullBenchmarkReport( suites=results, overall_pass_rate=np.mean([ r.pass_rate for r in results.values() ]), timestamp=datetime.now(), ) 六、综合性能评分 class AgentPerformanceScore: """Agent 综合性能评分""" def calculate( self, latency: LatencyResult, throughput: ThroughputResult, cost: CostReport, quality: FullBenchmarkReport ) -> PerformanceScore: # 归一化评分(0-100) # 延迟分(越低越好,基准 30s = 0分, 1s = 100分) latency_score = max(0, min(100, 100 * (30 - latency.p95 / 1000) / 29 )) # 吞吐分(越高越好,基准 1 RPS = 0分, 100 RPS = 100分) throughput_score = max(0, min(100, 100 * throughput.requests_per_second / 100 )) # 成本分(越低越好,基准 $0.1/请求 = 0分, $0.001/请求 = 100分) cost_score = max(0, min(100, 100 * (0.1 - cost.avg_cost) / 0.099 )) # 质量分(越高越好) quality_score = quality.overall_pass_rate * 100 # 加权综合 weights = { "latency": 0.20, "throughput": 0.15, "cost": 0.25, "quality": 0.40, } overall = sum(score * weights[key] for key, score in [ ("latency", latency_score), ("throughput", throughput_score), ("cost", cost_score), ("quality", quality_score), ]) return PerformanceScore( overall=overall, latency=latency_score, throughput=throughput_score, cost=cost_score, quality=quality_score, grade=self._grade(overall), tradeoffs=self._analyze_tradeoffs( latency_score, throughput_score, cost_score, quality_score ), ) def _grade(self, score: float) -> str: if score >= 90: return "A+" if score >= 80: return "A" if score >= 70: return "B" if score >= 60: return "C" if score >= 50: return "D" return "F" 七、持续基准测试 # .github/workflows/agent-benchmark.yml name: Agent Performance Benchmark on: schedule: - cron: "0 2 * * 1" # 每周一凌晨2点 workflow_dispatch: # 手动触发 jobs: benchmark: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run latency benchmark run: python benchmarks/latency_benchmark.py --output results/latency.json - name: Run throughput benchmark run: python benchmarks/throughput_benchmark.py --output results/throughput.json - name: Run cost benchmark run: python benchmarks/cost_benchmark.py --output results/cost.json - name: Run quality benchmark run: python benchmarks/quality_benchmark.py --output results/quality.json - name: Generate report run: python benchmarks/generate_report.py --input results/ --output report.md - name: Compare with baseline run: | python benchmarks/compare_baseline.py \ --current results/ \ --baseline benchmarks/baseline/ \ --threshold-latency 10 \ --threshold-cost 5 \ --threshold-quality 2 - name: Upload results uses: actions/upload-artifact@v4 with: name: benchmark-results path: results/ - name: Notify on regression if: failure() uses: ./.github/actions/slack-notify with: message: "Agent performance regression detected!" 八、基准测试 Checklist □ 四维基准测试覆盖(延迟/吞吐/成本/质量) □ 测试场景分级(简单/中等/复杂) □ 延迟测试包含首 Token 延迟 □ 吞吐测试找到最大并发数 □ 成本测试计算成本效率比 □ 质量测试使用标准化评测集 □ 持续基准测试(每周自动运行) □ 基线对比检测性能回归 □ SLA 定义明确(P95 延迟、错误率) □ 性能评分模型用于横向对比 结语 基准测试不是一次性的活动,而是持续的过程。Agent 的性能会随着 Prompt 修改、模型升级、工具变更而变化。建立持续的基准测试体系,让性能回归在 CI 阶段就被发现,而不是等到用户投诉。记住:没有测量就没有优化。在你开始优化 Agent 性能之前,先确保你能准确测量它。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

2026-06-28 · 6 min · 1238 words · 硅基 AGI 探索者
vllm vs sglang benchmark

vLLM vs SGLang性能基准

概述 vLLM vs SGLang性能基准是AI智能体领域中vLLM vs SGLang性能基准的重要主题。本文将从多个角度深入分析这一话题,为读者提供系统性的认知框架和实践参考。 核心概念 基本定义 在深入讨论之前,我们需要明确几个核心概念。AI智能体是指能够感知环境、理解指令、规划行动并调用工具完成任务的AI系统。与传统的聊天机器人不同,智能体具有自主性、目标导向性和工具使用能力。 vLLM vs SGLang性能基准涉及的关键技术包括: 大语言模型:作为智能体的认知引擎,负责理解、推理和生成 工具调用:通过Function Calling或MCP协议与外部系统交互 记忆系统:短期记忆处理当前对话,长期记忆存储历史经验 规划引擎:将复杂任务分解为可执行的子步骤 技术原理 从技术层面看,vLLM vs SGLang性能基准的核心在于如何让AI系统更好地理解和执行人类意图。这涉及多个技术环节的协同: 首先是感知层,智能体需要准确理解用户的自然语言指令,提取关键信息和约束条件。其次是规划层,将高层目标分解为具体的执行步骤。然后是执行层,调用合适的工具完成每个步骤。最后是反馈层,根据执行结果调整后续策略。 实践分析 当前现状 在框架测评领域,当前的技术实践呈现出几个明显特征: 工程化程度提升:从实验室原型到生产级系统,工程能力成为关键差异化因素 评估体系完善:越来越多标准化的评测基准被提出,帮助开发者量化能力边界 开源生态繁荣:开源框架和工具链的成熟降低了开发门槛 安全意识增强:对AI安全和对齐问题的重视程度显著提升 关键挑战 尽管进展显著,vLLM vs SGLang性能基准仍面临几个核心挑战: 技术挑战: 大模型的幻觉问题在智能体场景下被放大,因为智能体需要做出实际决策 多步推理中的错误累积效应导致长程任务成功率下降 工具调用的可靠性受外部API稳定性影响 工程挑战: 智能体的可观测性不足,调试和排错困难 成本控制与性能优化的平衡 从单机到分布式部署的架构复杂性 安全挑战: Prompt注入等攻击手段不断进化 智能体权限管理需要更精细化的控制 数据隐私保护在多Agent协作场景下更加复杂 优化策略 针对上述挑战,以下是几个关键优化方向: 技术优化 分而治之:将复杂任务分解为可独立验证的子任务,降低单步错误影响 多路投票:对关键决策使用多次采样投票机制,提高可靠性 渐进式信任:智能体权限从最小化开始,根据表现逐步扩展 人在回路:高风险决策保留人工审核环节 工程优化 可观测性优先:建立完善的日志、指标和追踪体系 灰度发布:新版本智能体先在小流量环境验证 自动化测试:构建端到端测试套件,防止回归 成本监控:实时追踪Token消耗和API调用成本 案例研究 为了更具体地说明vLLM vs SGLang性能基准的实践价值,我们来看一个典型场景: 某科技公司在内部IT运维中部署了AI智能体,负责处理员工的工单请求。智能体需要理解员工的自然语言描述,判断问题类型,查询知识库,执行修复操作或转接人工。 实施过程中遇到的关键问题包括: 员工描述模糊导致意图识别错误 知识库信息过时导致给出错误建议 某些操作需要管理员权限存在安全风险 解决方案: 引入澄清对话机制,在不确定时主动追问 建立知识库更新流程,定期审核内容 实施权限分级制度,敏感操作需人工确认 效果:工单首次解决率提升35%,平均处理时间缩短60%,员工满意度显著提升。 ...

2026-06-27 · 1 min · 104 words · 硅基 AGI 探索者
agent benchmark suite

Agent 基准测试套件:SWE-bench vs WebArena vs GAIA

为什么 Agent 需要专属基准 传统 LLM 基准(MMLU、HumanEval)评估的是单轮输入输出的能力。但 Agent 的工作模式截然不同:它需要多步推理、工具调用、环境交互和状态管理。一个在 MMLU 上得高分的模型,未必能完成"在 GitHub 上修复一个 issue"这样的复杂任务。 Agent 基准测试需要回答的问题: 模型能否将复杂目标拆解为可执行的子任务? 模型能否正确调用工具并解析返回结果? 模型能否在失败后调整策略并重试? 模型能否在长上下文中保持目标一致性? 三大基准套件总览 维度 SWE-bench WebArena GAIA 领域 软件工程 Web 交互 通用助手 任务来源 真实 GitHub Issue 自建 Web 环境 人工设计 环境 Docker 容器 浏览器 + Web 服务 文件 + Web + 工具 评估方式 单元测试通过率 端到端功能验证 最终答案精确匹配 任务数量 2,298 (Lite: 300) 812 466 (Level 1-3) 最高分(2026初) ~35% (SWE-agent) ~42% (GPT-4o) ~25% (Level 3) 开源协议 MIT MIT Apache 2.0 SWE-bench:软件工程能力试金石 设计理念 SWE-bench 从 12 个流行 Python 开源仓库中收集真实的 GitHub Issue 及对应 Pull Request,要求 Agent 在给定代码仓库中修改代码以解决 Issue。评估标准是对应 PR 中的单元测试是否通过。 ...

2026-06-25 · 6 min · 1196 words · AI 实战派
🔗 硅基 AGI 论坛 · silicon-agi.com | 📡 RSS 订阅
鲁ICP备2026018361号