在过去一年与众多企业客户的交流中,我们发现一个普遍的痛点:RAG 系统上线后,如何量化评估问答质量?如何系统化提升检索效果?如何在多个优化方案中选择最优解?
很多团队花费大量时间调试 RAG 系统,但往往凭感觉调参,缺乏数据支撑。A/B 测试需要人工逐条对比,效率低下。更关键的是,没有一套标准化的评测体系,就无法形成可持续优化的闭环。
基于此,我们推出了KnowEval - 专为 RAG 系统打造的全链路评测平台,将评测这个"隐形能力"变成可视化、可量化、可优化的工程化能力。
KnowEval v1.0.0 正式发布,本版本推出以下核心能力:
1. 五维度评测体系
我们基于业界领先的 RAGAS 框架,构建了完整的 RAG 评测指标体系:
2. AI 智能生成测试集
手动构建测试数据集费时费力,我们提供了AI 自动生成测试集功能:
3. 可视化评测报告
告别枯燥的数字表格,我们提供了直观的可视化报告:
4. 对接 KnowFlow,形成完整闭环
KnowEval 与 KnowFlow 深度集成,形成"数据治理 → RAG 检索 → 质量评测 → 持续优化"的完整闭环:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
┌─────────────────────────────────────────────────────────┐
│ KnowFlow 生态 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ KnowFlow │──────▶│ RAG 应用 │ │
│ │ 知识库平台 │ │ 业务场景 │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │ │
│ │ │ │
│ ┌──────▼──────────────────────▼───────┐ │
│ │ KnowEval 评测平台 │ │
│ ├─────────────────────────────────────┤ │
│ │ • 五维度评测指标 │ │
│ │ • AI 生成测试集 │ │
│ │ • 可视化分析报告 │ │
│ │ • A/B 测试对比 │ │
│ └─────────────┬───────────────────────┘ │
│ │ │
│ ┌─────────────▼───────────────────────┐ │
│ │ 数据驱动的优化决策 │ │
│ │ • 切块方法调优 │ │
│ │ • 检索参数优化 │ │
│ │ • Prompt 迭代改进 │ │
│ └─────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
作为首个正式版本,我们在内测阶段修复了大量问题:
本版本同时提供了Docker 一键部署方案,3 分钟即可完成部署。详情可参考官方文档。
传统的 RAG 评测依赖人工抽查,效率低且主观性强。KnowEval 基于RAGAS 框架,提供了五大评测维度:
评测目标:答案是否基于检索到的上下文,而非 LLM 的内部知识或"幻觉"。
技术实现:
应用场景:金融、法律等对事实准确性要求极高的领域。
1 2 3 4 5 6 7 8 9 10 11 12 13 14
# 示例评测逻辑
faithfulness = supported_statements / total_statements
# 示例结果
# 问题:"KnowFlow 支持哪些文档格式?"
# 上下文:"KnowFlow 支持 PDF、Word、Excel、PPT 等格式。"
# 回答:"KnowFlow 支持 PDF、Word 和 Markdown 格式。"
#
# 分析:
# ✅ "支持 PDF" - 有依据
# ✅ "支持 Word" - 有依据
# ❌ "支持 Markdown" - 无依据(上下文未提及)
#
# 忠实度得分:2/3 = 66.7%
评测目标:对比标准答案,综合评估语义相似度和事实准确性。
技术实现:
应用场景:有明确标准答案的场景,如产品 FAQ、操作手册等。
1 2 3 4 5 6 7 8 9 10
# 计算公式
answer_correctness = α × f1_score + β × similarity_score
# 示例结果
# 标准答案:"喷砂钢材表面可溶性氯化物含量应不大于 7 μg/cm²。"
# 实际答案:"喷砂钢材表面可溶性氯化物含量应不大于 7μg/cm²。超标时应采用高压淡水冲洗。"
#
# F1 Score: 0.95 (关键信息准确)
# Similarity: 0.88 (语义高度相似)
# Answer Correctness: 0.92
评测目标:检索到的文档片段是否与问题高度相关。
技术实现:
应用场景:优化检索算法,减少无关文档干扰。
评测目标:是否检索到回答问题所需的所有关键信息。
技术实现:
应用场景:诊断检索遗漏问题,优化 Top-K 参数。
评测目标:答案是否切题,没有包含冗余或无关信息。
技术实现:
应用场景:优化 Prompt,避免答案啰嗦或跑题。
手动构建测试数据集是 RAG 评测的最大瓶颈。KnowEval 提供了AI 自动生成测试集功能,彻底解决这一痛点。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
┌─────────────────────────────────────────────────────────┐
│ AI 生成测试集工作流 │
├─────────────────────────────────────────────────────────┤
│ │
│ ① 选择知识库 │
│ └─▶ 连接 KnowFlow/RAGFlow │
│ │
│ ② 配置生成参数 │
│ ├─▶ 生成数量 (1-100) │
│ ├─▶ 问题类型 (事实型/推理型/对比型) │
│ └─▶ 难度等级 (简单/中等/困难) │
│ │
│ ③ AI 智能生成 │
│ ├─▶ 从知识库提取文档片段 │
│ ├─▶ 基于片段生成自然问题 │
│ ├─▶ 提取标准答案 │
│ └─▶ 关联参考上下文 │
│ │
│ ④ 人工审核(可选) │
│ └─▶ 预览、编辑、删除 │
│ │
│ ⑤ 一键导入评测 │
│ └─▶ 立即开始评测 │
│ │
└─────────────────────────────────────────────────────────┘
某金融科技公司使用 KnowFlow 构建了产品知识库,包含 500+ 篇文档。使用 KnowEval 的 AI 生成功能:
评测数据的价值在于洞察。KnowEval 提供了强大的可视化分析能力:
核心指标一目了然:
五维度雷达图:
通过雷达图,可以直观发现:
优化建议:
单条问答诊断:
导出功能:
KnowEval 与 KnowFlow 深度集成,形成完整的 RAG 工程化闭环。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
第 1 步:数据治理(KnowFlow)
├─▶ 使用 MinerU/Dots 解析文档
├─▶ 选择切块方法(Smart/Title/Parent-Child)
├─▶ 配置 Embedding 模型
└─▶ 构建知识库
第 2 步:应用开发
├─▶ 开发 RAG 应用
├─▶ 配置检索参数
└─▶ 设计 Prompt 模板
第 3 步:质量评测(KnowEval)
├─▶ AI 生成测试集
├─▶ 运行五维度评测
├─▶ 分析可视化报告
└─▶ 发现优化方向
第 4 步:持续优化
├─▶ 方案A:调整切块参数(如增加父标题)
├─▶ 方案B:优化检索算法(如增加 rerank)
├─▶ 方案C:改进 Prompt 模板
└─▶ 方案D:升级 Embedding 模型
第 5 步:A/B 测试(KnowEval)
├─▶ 对比多个方案的评测结果
├─▶ 量化分析提升效果
└─▶ 选择最优方案
第 6 步:一键应用
└─▶ 将最优配置应用到生产环境
背景:
优化过程:
第一轮评测(基线方案):
1 2 3 4 5 6 7
方案:General 切块 + BGE-Large Embedding
评测结果:
- 忠实度:75%
- 答案正确性:62%
- 上下文精确度:58%
- 上下文召回率:85%
- 答案相关性:55%
问题诊断:
第二轮优化(调整切块方法):
1 2 3 4 5 6 7
方案:Title 切块(按 H2 标题)+ 增加父标题
评测结果:
- 忠实度:82% ↑
- 答案正确性:68% ↑
- 上下文精确度:71% ↑↑
- 上下文召回率:88% ↑
- 答案相关性:58% ↑
第三轮优化(增加 Rerank):
1 2 3 4 5 6 7
方案:Title 切块 + 父标题 + BGE-Reranker
评测结果:
- 忠实度:88% ↑
- 答案正确性:76% ↑
- 上下文精确度:85% ↑↑
- 上下文召回率:92% ↑
- 答案相关性:65% ↑
最终效果:
KnowEval 基于RAGAS(RAG Assessment)框架构建,采用 LLM-as-a-Judge 的评测范式。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
┌─────────────────────────────────────────────────────────┐
│ KnowEval 架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ 评测任务调度层 │ │
│ │ • 任务队列管理 │ │
│ │ • 并发控制(8workers) │ │
│ │ • 进度追踪与回调 │ │
│ └────────────────┬─────────────────────────┘ │
│ │ │
│ ┌────────────────▼─────────────────────────┐ │
│ │ RAGAS 评测引擎 │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ Faithfulness Evaluator │ │ │
│ │ │ • Statement Extraction (LLM) │ │ │
│ │ │ • Verification (LLM) │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ Answer Correctness Evaluator │ │ │
│ │ │ • F1 Score (LLM) │ │ │
│ │ │ • Similarity (Embeddings) │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ Context Precision Evaluator │ │ │
│ │ │ • Relevance Judgment (LLM) │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ └── ... (其他评测器) │ │
│ └────────────────┬─────────────────────────┘ │
│ │ │
│ ┌────────────────▼─────────────────────────┐ │
│ │ LLM 服务层 │ │
│ │ • OpenAI API │ │
│ │ • SiliconFlow API │ │
│ │ • DeepSeek API │ │
│ │ • 智谱 AI API │ │
│ └────────────────┬─────────────────────────┘ │
│ │ │
│ ┌────────────────▼─────────────────────────┐ │
│ │ 数据存储层 │ │
│ │ • SQLite (评测结果) │ │
│ │ • JSON (详细报告) │ │
│ │ • 文件系统 (数据集) │ │
│ └──────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
1. 并行评测
原始实现中,每个样本的评测需要 3-4 次 LLM 调用,串行执行非常慢。我们通过以下优化将速度提升 4 倍:
1 2 3 4 5 6 7 8 9 10 11 12 13
# 优化前:串行执行
forsampleinsamples:
result = evaluate(sample) # 40-50秒/样本
# 10个样本需要 8-9 分钟
# 优化后:并行执行
run_config = RunConfig(
max_workers=8, # 并行 8 个 worker
max_retries=3, # 失败重试 3 次
timeout=600 # 单个任务超时 10 分钟
)
results = evaluate(dataset, run_config=run_config)
# 10个样本仅需 2-3 分钟
2. 智能缓存
对于相同的问题和上下文,LLM 的评测结果是确定的。我们实现了结果缓存机制:
1 2 3 4 5 6 7 8 9 10 11
# 计算缓存键
cache_key =hash(question + context + answer + metric_name)
# 命中缓存直接返回
ifcache_keyincache:
returncache[cache_key]
# 否则调用 LLM 并缓存结果
result = llm_evaluate(...)
cache[cache_key] = result
returnresult
3. 超时重试
为了应对 API 限流和网络波动,实现了指数退避重试机制:
1 2 3 4 5 6 7 8 9
fromtenacityimportretry, stop_after_attempt, wait_exponential
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1,min=4,max=60)
)
asyncdefcall_llm_api(prompt):
response =awaitclient.chat.completions.create(...)
returnresponse
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
步骤1:文档采样
├─▶ 从知识库随机抽取文档片段
├─▶ 过滤过短/过长的片段
└─▶ 确保覆盖不同主题
步骤2:问题生成(LLM)
├─▶ Prompt:"基于以下文档,生成 {n} 个自然问题"
├─▶ 约束条件:
│ ├─ 问题类型(事实型/推理型/对比型)
│ ├─ 难度等级(简单/中等/困难)
│ └─ 问题长度(10-50字)
└─▶ 生成多样化问题
步骤3:答案提取(LLM)
├─▶ Prompt:"从以下文档中提取问题的答案"
├─▶ 约束条件:
│ ├─ 答案必须基于文档
│ ├─ 答案长度(20-200字)
│ └─ 答案格式(文本/列表/表格)
└─▶ 提取标准答案
步骤4:上下文关联
├─▶ 将问题与原始文档片段关联
├─▶ 添加参考上下文(reference_contexts)
└─▶ 构建完整测试样本
步骤5:质量检查
├─▶ 过滤过于简单的问题(如"是什么")
├─▶ 去重相似问题
└─▶ 人工审核(可选)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
QUESTION_GENERATION_PROMPT ="""
你是一个专业的问题生成器。请基于以下文档内容,生成 {count} 个高质量的问题。
文档内容:
{document}
要求:
1.问题类型:{question_type}
- 事实型:询问具体信息(如"KnowFlow支持哪些格式?")
- 推理型:需要理解和推理(如"为什么Title切块适合论文?")
- 对比型:比较不同概念(如"MinerU和Dots有什么区别?")
2.难度等级:{difficulty}
- 简单:答案可直接在文档中找到
- 中等:需要理解多个段落
- 困难:需要综合分析和推理
3.问题长度:10-50字
4.确保问题自然、具体、有意义
5.避免过于简单的问题(如"这是什么?")
请以 JSON 格式返回,格式如下:
[
{{"question":"问题1"}},
{{"question":"问题2"}},
...
]
"""
KnowEval 支持主流 LLM 提供商,通过统一的接口层实现无缝切换:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
# 统一配置接口
classLLMConfig:
provider:str # openai/siliconflow/deepseek/zhipu
model:str # 模型名称
api_key:str # API 密钥
base_url:str # API 端点
temperature:float # 温度参数
# LLM 适配器
classLLMAdapter:
def__init__(self, config: LLMConfig):
ifconfig.provider =="openai":
self.client = OpenAI(api_key=config.api_key)
elifconfig.provider =="siliconflow":
self.client = OpenAI(
api_key=config.api_key,
base_url="https://api.siliconflow.cn/v1"
)
# ... 其他提供商
asyncdefchat_completion(self, messages):
response =awaitself.client.chat.completions.create(
model=self.config.model,
messages=messages,
temperature=self.config.temperature
)
returnresponse.choices[0].message.content
KnowEval v1.0.0 是我们在 RAG 工程化道路上的重要里程碑。通过将评测能力产品化,我们让"凭感觉调参"变成了"数据驱动优化"。
基于与客户的深度交流,KnowEval 的产品定位如下:让 RAG 系统的质量可量化、可优化、可持续,将评测能力转化为核心竞争力。
后续我们将围绕以下方向持续迭代:
1. 更多评测指标
2. 对比评测功能
3. 自动化优化建议
4. 更多 RAG 系统集成
1. 团队协作能力
2. 持续监控
3. 自定义评测指标
4. 企业级能力
构建 RAG 质量保证的行业标准
我们相信,随着 RAG 应用的普及,质量评测将成为 RAG 工程化的核心基础设施。KnowEval 的愿景是:
KnowEval 已开源并托管在 GitHub:
🔗 项目地址:https://github.com/KnowFlowRAG/KnowEval
📄 开源协议:AGPL-3.0
Docker 一键部署(推荐):
1 2 3 4 5 6 7 8 9 10 11 12
# 1. 克隆项目
gitclonehttps://github.com/KnowFlowRAG/KnowEval.git
cdKnowEval/docker-deploy
# 2. 配置环境变量
cp.env.example .env
# 编辑 .env,配置 RAGFlow API 和 LLM API
# 3. 启动服务
./start.sh
# ✅ 访问 http://localhost:5003
我们非常欢迎大家参与到 KnowEval 的建设中:
扫描下方二维码,关注公众号 「KnowFlow 企业知识库」,加入内部交流群,学习和分享 RAG 工程化经验。
在 AI 时代,数据质量决定了应用质量。KnowFlow 解决了数据治理的问题,让知识库"可信";KnowEval 解决了质量评测的问题,让 RAG 系统"可控"。
数据治理 + 质量保证 = RAG 工程化的完整闭环
我们相信,通过 KnowFlow 生态的持续建设,可以帮助企业:
这就是我们的使命:将结构化与非结构化数据治理成对大模型更可信的输入,构建面向未来的数据治理平台,重塑 AI 时代的数据根基。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |