「ResearchBuddy」——测试报告

1 系统弹性与稳定性评估

系统弹性与稳定性评估为系统评估的核心对象，包括限流测试、熔断测试、故障恢复测试

1.1 限流测试

验证令牌桶限流器是否正确拒绝超过阈值的请求，保护系统不被流量洪峰冲垮。

测试配置

在1s内并发20个请求，测试结果如下

📊 限流测试结果 (20 个并发请求)

请求 1-5: ✅ 通过 (前5个请求消耗令牌)
请求 6-20: ⛔ 被限流 (令牌耗尽)

统计:
总请求: 20
允许: 5
拒绝: 15
拦截率: 75%
响应时间: <10ms (拒绝请求快速返回)
限流器状态: tokens_available=0

验证矩阵

1.2 熔断测试

验证熔断器在连续失败后自动打开，快速失败防止级联故障，并在服务恢复后自动闭合。

测试配置

将LLM配置修改为错误模型名，模拟一直请求失败的情形，测试结果如下

📊 熔断测试结果

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段 1: 触发熔断
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第1次: ❌ 失败 (Model not exist)
第2次: ❌ 失败 (Model not exist)
第3次: ❌ 失败 (Model not exist)
🔌 熔断器触发 OPEN (failures: 3)
第4次: ⛔ 快速失败 (熔断打开) - 响应时间: 5ms

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段 2: 等待恢复
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⏳ 等待 30s...
🔄 熔断器进入半开状态 (HALF-OPEN)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段 3: 自动恢复
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第7次: ✅ 请求成功 (半开试探通过)
🔌 熔断器闭合 (CLOSED)

验证矩阵

1.3 故障恢复测试

验证系统在 LLM API 恢复后能否自动恢复正常服务，无需人工干预。

熔断30s后自动恢复，结果如下

📊 故障恢复测试结果

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段 1: 正常运行
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ 请求成功 (熔断器: CLOSED)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段 2-3: 触发熔断
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第1次: ❌ 失败
第2次: ❌ 失败
第3次: ❌ 失败
🔌 熔断器触发 OPEN

第4次: ⛔ 快速失败 (5ms)
第5次: ⛔ 快速失败 (4ms)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段 4: 修复服务 + 等待恢复
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔧 修复模型名: invalid_model → qwen-plus
⏳ 等待 30s...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段 5: 自动恢复
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔄 半开状态 (HALF-OPEN)
✅ 请求成功 (熔断器恢复: CLOSED)
📊 服务完全恢复

验证矩阵

1.4 综合测试结果

2性能基准与压力测试

2.1 RAG质量评估

建立了三层评估体系：

1）离线评估（自动化）：

• Recall@K：前 K 个结果中包含相关论文的比例
• MRR：第一个相关论文的排名倒数的平均值
• NDCG：考虑排序位置的归一化折损累计增益

2）在线评估（人工）：

• 构建了 10 个主题的测试集，每个主题标注 5 篇相关论文
• 每次迭代后跑测试集，人工抽查 20% 的结果

3）端到端评估：

• 用 LLM-as-Judge 对生成的综述打分
• 评估维度：相关性、完整性、逻辑连贯性

向量检索 vs 重排序对比

人工评估结果

端到端评估

2.2 系统性能评估测试

性能评估测试集包含 50 个不同的研究主题，覆盖 5 个领域，每个领域 10 个主题。

测试集详细构成

为什么是 50 个？

测试主题示例

AI/ML（10 个）

• "Transformer attention mechanism"

• "Large language model fine-tuning"

• "Reinforcement learning from human feedback"

• "Few-shot learning in computer vision"

• "Graph neural networks for molecular property prediction"

• "Diffusion models for image generation"

• "Federated learning privacy protection"

• "Self-supervised learning in NLP"

• "Generative adversarial networks in medical imaging"

• "Meta-learning for few-shot classification"

中英文混合（10 个）

• "基于大语言模型的代码生成"（中文）

• "Vision Transformer 在图像分类中的应用"（中文）

• "GPT for code generation"

• "LLaMA 模型微调"（中文）

• "ReAct agent with tool calling"

• "AI agent planning and reasoning"

• "Transformer 注意力机制"（中文）

• "强化学习在游戏中的应用"（中文）

• "Neural network quantization and pruning"

• "对比学习在语音识别中的应用"（中文）

其他领域（30 个）

• 系统、网络、理论、数学等领域的典型研究主题，为了使篇幅不显得冗长，这里不再做一一展示。

测试结果

2.3 并发处理测试

2.2.1 异步任务队列架构

并发测试场景

测试结果

📊 并发测试结果
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
场景 1: 轻负载 (5 并发, 2 Workers)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
任务提交响应: 平均 45ms | P95 78ms | P99 120ms
任务完成时间: 平均 85s | P95 110s | P99 135s
Worker 利用率: 45%
CPU 利用率: 30%
内存利用率: 2.1GB

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
场景 2: 中负载 (20 并发, 4 Workers)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
任务提交响应: 平均 52ms | P95 95ms | P99 145ms
任务完成时间: 平均 92s | P95 125s | P99 160s
Worker 利用率: 78%
CPU 利用率: 55%
内存利用率: 3.8GB

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
场景 3: 高负载 (50 并发, 4 Workers)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
任务提交响应: 平均 68ms | P95 120ms | P99 180ms
任务完成时间: 平均 105s | P95 145s | P99 190s
Worker 利用率: 95% (接近饱和)
CPU 利用率: 72%
内存利用率: 5.2GB
队列积压: 最多 15 个任务

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
场景 4: 突发流量 (100 并发, 4 Workers)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
任务提交响应: 平均 85ms | P95 150ms | P99 220ms
任务完成时间: 平均 120s | P95 170s | P99 210s
Worker 利用率: 100% (饱和)
CPU 利用率: 85%
内存利用率: 6.8GB
限流触发次数: 75 次 (限流生效)
队列积压: 最多 45 个任务
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

并发处理关键指标

2.4 缓存命中率

测试方法：

• 运行 50 个不同主题的查询

• 每个主题重复查询 3 次

• 分别记录 L1、L2、L3 的命中情况

📊 缓存命中率测试 (50 个主题 × 3 次)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

首次查询 (无缓存):
总请求: 50
缓存命中: 0
实际执行: 50
平均耗时: 95s

第二次查询:
总请求: 50
L1 命中: 10 (20%)
L2 命中: 32 (64%)
L3 命中: 8 (16%)
总命中率: 100%
平均耗时: 8s

第三次查询:
总请求: 50
L1 命中: 35 (70%)
L2 命中: 15 (30%)
L3 命中: 0 (0%)
总命中率: 100%
平均耗时: 2s
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

缓存命中率统计

缓存命中带来的性能提升

3成本评估

3.1 智能路由

模型定价（阿里云百炼）

单次任务 Token 消耗完整分析

场景：5 篇论文，生成完整综述（2000 字）

单次任务的成本=输入成本+输出成本=0.263

智能路由策略比全部用qwen-max节省成本49%

各阶段成本占比

单次任务成本分解 (¥0.263):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
生成综述: ████████████████████████████████████████ 68% (¥0.18)
阅读 5 篇: ████████████████████████ 23% (¥0.06)
对比分析: ██████ 8% (¥0.022)
分析 + 筛选: █ 1% (¥0.001)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
输入成本: 60% (¥0.157) | 输出成本: 40% (¥0.106)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

3.2 缓存策略

根据前面缓存命中率测试结果

选用稳态命中率进行成本评估

稳态成本 = 首次成本 × (1 - 命中率) + 缓存成本 × 命中率
= ¥0.263 × 5% + ¥0.001 × 95%
= ¥0.01315 + ¥0.00095
= ¥0.0141

100次任务缓存成本计算

基于这个数据，在稳态场景下，单次任务的真实成本约为¥0.014，相比首次执行的 ¥0.263，节省了94.7%。

对于企业场景（6000 任务/月），月成本从无缓存的 ¥1,578 降至¥138，节省超过 90%。