Dingo：AI-Ready 数据全链路质量评测框架

• Dingo SaaS： https://dingo.openxlab.org.cn/
• Dingo SDK： MigoXLab/dingo（欢迎点个 Star）

背景介绍

行业演进：从“数据可观测”到“AI 全链路可评测”

传统数据质量主要关注完整性、唯一性、格式一致性和字段合法性；进入大模型时代后，评测对象和质量标准都发生了变化。把视野放到整个行业，这条赛道大致经历了三代范式：

大多数玩家是“从一端切入”的：要么专注预训练数据清洗（如 Cleanlab、Lilac），要么专注应用层评测（如 Ragas、Langfuse）。Dingo 的差异化在于用一套框架贯穿全链路——从预训练数据 → 文档解析 → RAG → Agent → 生产监控，用统一的“规则 + LLM 混合评测”范式覆盖，避免团队为每一段链路拼装多个割裂的工具。

我们也主动划清边界：不与全链路可观测性平台正面竞争 tracing 基础设施，Dingo 的核心竞争力是质量评测的深度和标准化，可以作为评测消费者接在这些平台之后。

一张图看清 Dingo 的站位

横轴是评测发生的位置（离线数据 ↔ 在线应用），纵轴是评测手段（规则/确定性 ↔ 语义/LLM）。多数产品聚集在某一两个象限，而 Dingo 的目标是把四个象限用同一套范式串起来。

演进带来的三类核心能力要求

因此，AI 数据质量评测需要同时具备三类能力：可解释且低成本的规则评测、能够理解语义的 LLM 评测，以及覆盖离线实验和线上运行的持续观测能力。下表按评测对象展开：

阶段一：预训练数据评估

行业坐标： 这一阶段对应 2022–2024 年整个行业的注意力焦点——当时模型能力的主要瓶颈是数据，所有人都在卷预训练/微调数据的去重、去毒和配比。Dingo 的起点正踩在这个节拍上。

早期的大模型数据质量工作主要集中在预训练和微调数据集。面对海量语料，核心目标是在训练前识别并隔离低质量样本，减少噪声数据对模型效果的影响，同时降低无效训练带来的算力成本。

Dingo 在这一阶段提供：

• 常见文本质量规则，包括特殊字符、格式异常、内容长度、重复模式等检查
• 基于 LLM 的语义质量评估，用于处理规则难以覆盖的可读性、相关性和内容价值判断
• 针对不同字段配置不同指标，并保留样本级问题原因
• 本地执行与 Spark 分布式执行，兼顾快速验证和大规模数据处理
• 输出质量统计、问题分布和低质量样本，形成“评测—清洗—复评”的数据治理闭环

阶段二：多模态、Agent 与标准化评测

行业坐标： 2024 年之后，模型已经足够强，行业注意力从“训练数据”迁移到“应用层”——RAG 幻觉、Agent 可靠性成为新的瓶颈。Dingo 的能力扩展与这条行业曲线同步。

随着 AI 应用从模型训练走向真实业务，评测对象已从单条文本扩展到文档、图片、检索上下文、模型回答、工具调用和完整 Agent 轨迹。质量评测也从“判断一条数据好不好”，演进为“判断一条应用链路是否可靠”。

• 文档与多模态： 评估 OCR、版面分析、表格、公式、标题层级和图文关联等解析质量
• RAG： 分别评估检索相关性、上下文覆盖度、回答相关性、事实忠实度和引用支撑情况
• Agent： 评估任务完成度、步骤效率、计划遵循、工具与参数正确性、错误恢复和循环行为
• AI4S 科研工作流： 评估科研数据、文献检索、证据链、工具调用和研究报告质量
• 标准化评测： 将标准条款或验收要求转化为指标组，沉淀可复现的评测配置、样本证据和报告
• 在线监控： 通过 API/SDK 异步接收生产 Trace，持续观察指标趋势，不介入业务请求链路

功能介绍

为什么选择 Dingo？

• 生产级质量检查： 从预训练数据集到 RAG 系统，确保你的 AI 获得高质量数据
• 多数据源集成： 无缝连接本地文件、SQL 数据库（PostgreSQL/MySQL/SQLite）、Hugging Face 数据集和 S3 存储
• 多字段评估： 对不同字段并行应用不同的质量规则（例如：对 isbn 字段进行 ISBN 验证，对 title 字段进行文本质量检查）
• RAG 系统评估： 使用 5 个学术支持的指标全面评估检索和生成质量
• LLM、规则和智能体混合： 结合快速启发式规则（30+ 内置规则）和基于 LLM 的深度评估
• 灵活执行： 本地运行快速迭代，或使用 Spark 扩展到数十亿级数据集
• 丰富报告： 详细的质量报告，带有 GUI 可视化和字段级洞察

竞品对比：全链路覆盖是最大差异点

把主流玩家放在同一张表里，最直观的结论是：大家各自强在某一段，而 Dingo 的价值在于“一栏栏连起来”。

说明：上表为面向本次分享的定性对比，各产品能力持续演进，实际选型请以最新版本为准。Dingo 不追求在单一维度上超过所有专精工具，而是用一套统一范式提供“够深且连贯”的全链路覆盖。

架构图

Dingo 使用示例

SDK 模式：评估 LLM 对话数据

from dingo.config.input_args import EvaluatorLLMArgs
from dingo.io.input import Data
from dingo.model.llm.text_quality.llm_text_quality_v5 import LLMTextQualityV5
from dingo.model.rule.rule_common import RuleSpecialCharacter

data = Data(
    data_id="123",
    prompt="hello, introduce the world",
    content="�I am 8 years old. ^I love apple because:",
)


def llm():
    LLMTextQualityV5.dynamic_config = EvaluatorLLMArgs(
        key="YOUR_API_KEY",
        api_url="https://api.openai.com/v1/chat/completions",
        model="gpt-4o",
    )
    res = LLMTextQualityV5.eval(data)
    print(res)


def rule():
    res = RuleSpecialCharacter().eval(data)
    print(res)


rule()
llm()

SDK 模式：评估数据集

from dingo.config import InputArgs
from dingo.exec import Executor

# Evaluate a dataset from Hugging Face
if __name__ == '__main__':
    input_data = {
        "input_path": "tatsu-lab/alpaca",  # Dataset from Hugging Face
        "dataset": {
            "source": "hugging_face",
            "format": "plaintext"  # Format: plaintext
        },
        "executor": {
            "result_save": {
                "bad": True  # Save evaluation results
            }
        },
        "evaluator": [
            {
                "evals": [
                    {"name": "RuleColonEnd"},
                    {"name": "RuleSpecialCharacter"}
                ]
            }
        ]
    }

    input_args = InputArgs(**input_data)
    executor = Executor.exec_map["local"](input_args)
    result = executor.execute()
    print(result)

CLI 模式

dingo eval --input .github/env/local_plaintext.json

.github/env/local_plaintext.json 配置示例：

{
  "input_path": "test/data/test_local_plaintext.txt",
  "dataset": {
    "source": "local",
    "format": "plaintext"
  },
  "evaluator": [
    {
      "evals": [{ "name": "RuleColonEnd" }]
    }
  ]
}

MCP Server 模式

# Start MCP server (SSE transport, default port 8000)
dingo serve

# stdio transport (for Claude Desktop)
dingo serve --transport stdio

Dingo SaaS 平台介绍

Dingo SaaS 是基于开源项目 Dingo 构建的企业级数据质量评估与管理平台。它将 Dingo 强大的数据质量评估能力产品化，提供 Web 界面、API 服务和完整的数据管理工作流。

核心特性

• 数据集管理： 支持多种数据源（本地文件、Hugging Face、S3 等）
• 指标配置： 灵活管理评估规则和 LLM 评估器
• 实验执行： 支持实验创建、执行、停止和日志查看
• 可视化报告： 提供交互式仪表盘和详细的质量分析
• API 与 SDK： 提供 RESTful API 和 Python SDK

功能演示

Dingo SaaS 平台提供 “Quick Try” 和 “Full Pipeline” 两种评测模式，满足不同场景需求：

Quick Try 模式 - 快速验证

• 适用场景： 单条数据质量快速检查、规则调试、Prompt 工程验证
• 操作流程：
  1. 在平台首页选择“Quick Try”
  2. 选择评估指标（如 LLMTextQualityV5、RuleSpecialCharacter 等）
  3. 输入待评测文本/图片等（支持纯文本/JSON 格式）
  4. 即时获取评分和详细诊断报告
• 优势： 秒级响应，无需创建实验，适合开发阶段快速迭代

Full Pipeline 模式 - 批量评测

• 适用场景： 大规模数据集质量评估、模型对比实验、生产环境监控
• 操作流程：
  1. 上传数据集（支持本地文件、Hugging Face、S3 等多源）
  2. 配置评估规则组合（可混合 LLM 评估器和规则评估器）
  3. 创建实验并执行（支持本地/Spark 分布式执行）
  4. 查看可视化报告（字段级质量分布、问题样本定位、趋势分析）
• 优势： 提供完整的实验管理和报告导出功能

Online Evaluation 模式 - 生产质量监控

• 适用场景： 外部 LLM、RAG 或 Agent 系统的线上质量观测
• 接入方式： 业务系统通过 API/SDK 异步提交 Trace，平台在后台执行评测
• 分析能力： 查看指标均值、最大值、最小值、时间趋势和单条 Trace 的评测明细
• 架构特点： Dingo 作为评测消费者，不代理模型请求，不向线上调用链路增加同步时延或单点风险

如何新增一个评测指标（Metric）

指标是 Dingo 的最小可复用资产。新增一个指标通常分两步：先做指标设计（想清楚“评什么、怎么算”），再做工程实现（把设计翻译成一个可注册、可复用的类）。这一节先讲设计方法论，再讲两类指标的代码落地，最后给出一条“零代码”的快速路径。

第一步：指标设计——把“质量”翻译成“可计算的公式”

设计一个新指标，本质是在两个正交的视角上给它定位：“评哪种质量”（质量维度） 和 “评什么对象”（链路阶段与应用场景）。先想清楚这两点，再落到公式与实现，思路就不会乱。

视角一：按质量维度看——指标“评的是哪一种好坏”。 这是可跨链路阶段复用的原子维度，也是 Dingo 中 quality_dimension 的分类思路：

视角二：按评测对象看——指标“用在链路的哪个环节”。 这对应 Dingo 的全链路主线，每个阶段各有关注重点：

定位好“维度”和“场景”之后，再用下面七个问题把单个指标设计具体化。这套结构直接来自 Dingo 现有 RAG 指标的设计范式（参见开源仓库 docs/rag_evaluation_metrics_zh.md）：

关于“计算公式”——这是指标设计中最需要打磨的部分。 好的公式让分数可解释、可对比、可复现。Dingo 的 RAG 指标示范了三种典型的量化范式，可作为设计新指标时的模板：

• 拆解—判定—比例法（适合“覆盖/忠实”类）。先把文本拆成原子陈述，逐条判定，再算比例：

Faithfulness  = 上下文支持的陈述数 / 答案总陈述数 × 10
Context Recall = 上下文能支撑的参考陈述数 / 参考答案总陈述数 × 10

二者互为镜像：Faithfulness 防“多说”（编造），Context Recall 防“少说”（遗漏）。

• 语义相似度法（适合“相关性”类）。把文本映射为向量，用余弦相似度度量：

Answer Relevancy = (1/N) × Σ cosine_sim(E_gi, E_o)
# 由答案反推 N 个问题，计算它们与原问题的平均相似度；需额外配置 embedding 模型

• 位置加权法（适合“排序质量”类）。不仅看相关与否，还看相关项是否靠前：

Context Precision = Σ(Precision@k × v_k) / 相关项总数
# v_k 为第 k 位是否相关（0/1），Precision@k 为前 k 项中相关项占比

设计小结： 规则难以覆盖的语义判断，交给 LLM 指标；能用确定性规则表达的（长度、字符、格式、循环调用、Token 消耗等），优先用规则指标——它零成本、可解释、可复现。同一质量维度也可以“规则 + LLM”双管齐下，先用规则做低成本初筛，再用 LLM 做深度研判。

第二步（A）：实现一个规则指标（Rule）

规则指标继承 BaseRule，用 @Model.rule_register(...) 装饰器注册，只需实现 eval 方法。返回的 EvalDetail 中 status=True 表示“命中问题/未通过”。

from dingo.io.input import Data, RequiredField
from dingo.io.output.eval_detail import EvalDetail, QualityLabel
from dingo.model.model import Model
from dingo.model.rule.base import BaseRule


# 注册：metric_type（质量维度）, group（可被指标组批量引用）
@Model.rule_register("QUALITY_BAD_EFFECTIVENESS", ["qa_standard_v1"])
class RuleContentTooShort(BaseRule):
    """内容长度过短检测：低于阈值判为低质量样本。"""

    # 用于自动生成指标文档
    _metric_info = {
        "category": "Rule-Based TEXT Quality Metrics",
        "quality_dimension": "EFFECTIVENESS",
        "metric_name": "RuleContentTooShort",
        "description": "检测内容长度是否过短",
    }

    # 声明该指标依赖哪些输入字段
    _required_fields = [RequiredField.CONTENT]

    @classmethod
    def eval(cls, input_data: Data) -> EvalDetail:
        res = EvalDetail(metric=cls.__name__)
        min_len = 10  # 也可从 cls.dynamic_config.threshold 读取，做成可配置阈值
        if len((input_data.content or "").strip()) < min_len:
            res.status = True  # True = 命中问题
            res.label = [f"{cls.metric_type}.{cls.__name__}"]
            res.reason = [f"内容长度不足 {min_len} 个字符"]
        else:
            res.label = [QualityLabel.QUALITY_GOOD]
        return res

第二步（B）：实现一个 LLM 指标

LLM 指标继承 BaseOpenAI，用 @Model.llm_register(...) 注册。基类已用模板方法封装了“调用 LLM → 重试 → 解析”的通用流程，因此只需实现两个方法：build_messages（把设计好的评分 Prompt 组装成消息）和 process_response（把模型返回解析成 EvalDetail）。

import json
from typing import List

from dingo.io.input import Data, RequiredField
from dingo.io.output.eval_detail import EvalDetail
from dingo.model.model import Model
from dingo.model.llm.base_openai import BaseOpenAI


@Model.llm_register("LLMAnswerCompleteness")
class LLMAnswerCompleteness(BaseOpenAI):
    """答案完整性：判断回答是否覆盖了问题的全部关键要点。"""

    _metric_info = {
        "category": "RAG Evaluation Metrics",
        "metric_name": "LLMAnswerCompleteness",
        "description": "评估答案是否完整覆盖了问题的关键要点",
    }

    _required_fields = [RequiredField.PROMPT, RequiredField.CONTENT]

    @classmethod
    def build_messages(cls, input_data: Data) -> List:
        # 把第一步设计的“评分标准 + 计算公式”写进 Prompt
        prompt = f"""你是严格的评审专家。请判断【答案】是否完整覆盖了【问题】的关键要点。
按覆盖比例给出 0-10 分（覆盖比例 × 10），并指出缺失的要点。

问题：{input_data.prompt}
答案：{input_data.content}

只返回 JSON：{{"score": 0到10的数值, "reason": "缺失要点说明"}}"""
        return [{"role": "user", "content": prompt}]

    @classmethod
    def process_response(cls, response: str) -> EvalDetail:
        # 生产实现建议参考 LLMRAGFaithfulness 做更健壮的 markdown/JSON 清理
        data = json.loads(response.strip().lstrip("`").removeprefix("json").strip())
        res = EvalDetail(metric=cls.__name__)
        res.score = data["score"]
        threshold = 7
        res.status = res.score < threshold  # 低于阈值判为未通过
        res.label = (
            ["QUALITY_GOOD"]
            if not res.status
            else ["QUALITY_BAD.COMPLETENESS_FAIL"]
        )
        res.reason = [data["reason"]]
        return res

第三步：注册与使用

Dingo 在启动时通过 Model.load_model() 递归扫描 dingo/model/rule/ 和 dingo/model/llm/ 目录并自动 import，装饰器执行时即完成注册。因此新增指标无需改动任何注册表——把文件放进对应目录即可，随后就能在 SDK、CLI、配置和 SaaS 平台里用类名直接引用：

"evaluator": [
    {
        "evals": [
            {"name": "RuleContentTooShort"},
            {"name": "LLMAnswerCompleteness", "config": {"threshold": 7}}
        ]
    }
]

零代码路径：通过配置定义自定义 LLM 指标

如果暂时不想写代码贡献到 SDK，可以直接复用内置的 LLMCustomMetric，用配置声明一个新指标——指定指标名、需要的输入字段和判定标准即可，适合快速验证一个评测想法或做业务专属规则。SaaS 平台的“指标配置”界面也基于同一能力，让非工程角色也能定义指标。

"evals": [
    {
        "name": "LLMCustomMetric",
        "config": {
            "model": "gpt-4o",
            "key": "YOUR_API_KEY",
            "api_url": "https://api.openai.com/v1",
            "custom_metric": {
                "metric": "ToneProfessional",           # 指标名
                "input_fields": ["content"],             # 依赖的输入字段
                "criteria": [                            # 判定标准，{{field}} 会被替换为字段值
                    "判断以下客服回复是否语气专业、礼貌：",
                    "{{content}}",
                    "若不专业，请将 status 置为 true 并说明原因。"
                ]
            }
        }
    }
]

从设计到上线的检查清单： ① 明确评估目标与所需字段；② 定义计算公式和 0–10 分的评分标准；③ 选择规则或 LLM 实现（或零代码配置）；④ 用少量典型样本验证分数是否符合预期；⑤ 校准阈值；⑥ 沉淀为指标组，供批量实验和在线监控复用。

场景演示

场景一：MinerU 解析数据质量评测

场景问题

MinerU 等文档解析工具可以将 PDF 转换为 Markdown 或 JSON，但“成功解析”不等于“解析结果可直接使用”。乱码、段落顺序错乱、标题层级异常、表格和公式丢失等问题会继续传递到知识库、RAG 或训练数据中。

评测思路

• 将原始文档信息、解析文本和结构化结果组织为评测数据集
• 使用规则指标检查乱码、异常字符、空内容、长度突变和 Markdown 结构
• 使用 LLM 指标判断语义完整性、段落连贯性、标题层级和表格/公式保真度
• 按文档、页码或内容块定位问题，并输出失败原因和问题样本

演示流程

1. 上传一批 MinerU 解析后的 Markdown/JSON 数据
2. 选择文档解析质量指标组并创建实验
3. 查看整体通过率和各指标的问题分布
4. 打开问题样本，对照原文定位解析缺陷

业务价值： 在文档进入知识库或训练流程前建立质量门槛，避免解析错误被下游系统放大。

单条数据评测示例：

The objective is to learn a mapping function $f_{\theta}$ (parameterized by
Dripper-0.6B) that predicts the label sequence
$\hat{Y} = [\hat{y}_1, \hat{y}_2, \dots, \hat{y}_n]$ conditioned on the input X:

原始公式的评测结果正确。

公式被故意修改后，评测结果正确识别出错误。

数据集评测结果报告示例： 查看公开报告

场景二：Agent 轨迹数据质量评测

场景问题

Agent 即使给出了最终答案，执行过程也可能存在工具选择错误、参数不正确、重复调用、计划偏离或异常后无法恢复等问题。仅评估最终输出无法揭示这些过程风险。

评测思路

• 将 Agent Trace 拆分为任务、计划、工具调用、工具返回、重试和最终答案等步骤
• 使用 LLM 指标评估任务完成度、步骤效率、计划质量、计划遵循和错误恢复能力
• 使用规则指标检查循环调用、Token 消耗、执行时延和异常状态
• 支持通过 API/SDK 持续提交线上 Trace，也可导入 Claude Code、Codex、Intern Agent、Langfuse 等格式进行离线分析

演示流程

1. 创建 Monitor 并配置 Agent 指标
2. 提交一条包含多次工具调用的 Trace
3. 查看 Trace 的异步评测状态、各指标得分和原因
4. 在监控面板查看一段时间内的指标趋势与异常记录

业务价值： 从“结果是否正确”深入到“过程为什么失败”，加快 Agent 调试，并持续发现生产环境中的质量退化。

评测结果报告示例： 查看 Agent 公开报告

场景三：AI4S 科研智能体与科学发现工作流评测

场景问题

AI4S 平台的质量不只取决于最终报告是否“看起来合理”。科研智能体通常需要检索论文、数据集和代码仓库，调用搜索、解析或计算工具，再把多来源证据整理成可复核的研究结论。任何一个环节出现遗漏、误用或不可追溯，都会降低结果的可信度和复现能力。

对于端砚（Intern AI Discovery）等科研发现平台，可以把 Dingo 作为独立的质量评测层：平台负责科研任务执行，Dingo 消费导出的 Trace、检索记录、工具调用日志和最终报告，对整个工作流进行离线评测或线上监控。这里的“端砚”是应用场景参考，并不代表 Dingo 已与其建立官方集成。

评测思路

• 科学数据质量： 检查字段完整性、Schema 一致性、单位和维度、缺失值、重复记录以及数据来源和版本信息
• 文献与资料检索： 评估检索相关性、关键资料召回、结果去重、引用元数据准确性和证据覆盖度
• 科研智能体轨迹： 检查任务完成度、计划遵循、工具选择与参数、重复搜索、无效循环、错误恢复和过程效率
• 研究报告质量： 评估事实忠实度、引用与结论的一致性、证据支撑、不确定性表达、边界条件和报告完整性
• 蛋白与分子等专业应用： 评测输入输出格式、数据来源、工具链执行和报告完整性；具体科学结论仍由领域模型、计算引擎或专家规则验证

一个典型工作流

提出科研问题
    ↓
科研 Agent 检索论文、数据集和代码仓库
    ↓
调用搜索、解析、计算等工具并收集证据
    ↓
生成结构化研究报告
    ↓
Dingo 评测检索、证据、轨迹和报告质量
    ↓
结果反哺离线基准集与线上质量监控

业务价值： 将“答案是否合理”的单点检查扩展为对科研数据、证据链和 Agent 执行过程的系统评测，帮助团队发现无依据结论、错误引用、工具误用和不可复现步骤。

能力边界： Dingo 负责评测数据和智能体工作流的质量，不替代蛋白结构、分子模拟或实验结论等领域验证，也不直接给出科研结论的权威性认证。

场景四：TC609 国家标准对齐与合规评测

场景问题

标准符合性评测通常涉及多个质量维度、指标口径和证据要求。如果依赖人工抽查，容易出现执行口径不一致、过程不可复现、结果难追溯等问题。Dingo 依据《全国数据标准技术委员会技术文件 TC609-5-2025-04 高质量数据集 质量评测规范》，支持自动化、智能化的高质量数据集评测。

评测思路

• 将具体标准条款拆解为可执行的规则指标、LLM 指标和指标组
• 固化数据范围、指标配置、模型参数和执行版本，保证评测可复现
• 在报告中保留指标结果、问题样本、判定原因和执行日志，形成完整证据链
• 通过公开报告链接支持评审、验收或第三方测评材料共享

演示流程

1. 选定本次评测所依据的具体标准和条款
2. 展示条款到 Dingo 指标组的映射关系
3. 对目标数据集执行评测并查看分维度结果
4. 抽查问题样本与判定原因，生成并分享评测报告

业务价值： 将标准要求转化为可执行、可追溯、可复用的评测流程。Dingo 提供评测工具与证据，不替代认证机构的最终合规结论。

创建说明文档指标评测。

创建数据质量指标评测。

说明文档评测报告示例： 查看公开报告

数据质量评测报告示例： 查看公开报告

展望

Dingo 的愿景是成为 AI 数据质量评测的基础设施：在开发阶段帮助团队快速发现问题，在交付阶段提供可复现的评测证据，在生产阶段持续监控质量风险，最终让 AI 系统的质量变得可衡量、可解释、可改进。

产品力：从“工具”到“体系”的护城河

单个规则或单条 LLM 指标很容易被复制，真正越用越厚、越厚越难替代的资产在于：

1. 评测对象更完整： 从文本和数据集扩展到图片、文档、音视频、RAG 上下文、Agent Trace，以及端到端 AI 应用链路。
2. 评测过程更持续： 把一次性的离线验收扩展为开发阶段快速验证、交付阶段可复现报告和生产阶段在线监控。
3. 指标资产不断沉淀： 持续建设规则与 LLM 指标库、行业指标模板、自定义指标能力和标准条款映射——这是随使用规模累积的资产，也是最难被抄走的部分。
4. 离线 + 在线的数据飞轮： 线上监控发现的质量退化 → 反哺离线评测指标 → 沉淀为可复用模板 → 再用于新项目的快速验证。评测用得越多，指标库越准，护城河越深。