知识问答效果不好时，团队第一反应通常是换 embedding、调 top-k 或升级模型。我在数据平台场景里遇到的更多情况是：被索引的元数据本身不完整、没有版本，甚至彼此冲突。检索与生成只能重新排列现有信息，不能凭空修复事实链。

RAG 的上限取决于它能拿到什么证据。表名和描述只是最薄的一层；对象身份、来源、有效时间、负责人、血缘、权限和采集状态，决定答案能否从“听起来合理”走到“可以复核”。

数据 Catalog 常见的问题不是没有资产，而是用户不知道该怎么找。平台要求先选实体类型，再填库、表、标签、负责人，只有熟悉元数据模型的人才能用好。自然语言适合作为入口，但它不该绕开 Catalog，直接让模型根据一堆描述猜表。

我的设计是两段式：模型把问题解析成结构化检索意图，Catalog 用确定性查询返回实体；模型再基于实体和关系组织答案。对象身份、权限和血缘事实仍由 Catalog 决定。

做统一 Catalog 时，团队通常先讨论要接哪些数据源、搜索框怎么做、血缘图画到字段还是表。我更愿意先追问一个看起来很基础的问题：prod 和 test 里都叫 sales.orders 的两张表，到底是不是同一个对象？

这个问题没答清楚，后面所有治理功能都会漂。采集任务重复跑一次可能多出一张表；集群迁移后，原来的标签和负责人找不到了；表重命名既可能把历史血缘切断，也可能错误地把两个对象合并。Catalog 不是把各种名称塞进一个搜索索引，它首先是一套对象身份系统。

血缘项目最容易交付的是一张很大的图：点开一张表，左边几十张上游表，右边几十张下游表，连线铺满屏幕。演示时很直观，真正遇到问题却常常答不出来。

“改这个字段会影响谁”需要字段与表达式；“昨晚这批数据为什么错”需要运行实例、代码版本和输入输出水位；“这张表有哪些上游”用表级关系就够。把三种问题都塞进同一张表级拓扑，图再完整也只能回答资产发现。

Apache Atlas 2.1 的模型本身已经给出几种层次：基础 Process 通过 inputs/outputs 连接 DataSet；Hive 还有 hive_column_lineage，保存字段依赖和 expression；模型里也有 ProcessExecution 与 hive_process_execution 表达具体执行。关键不在于有没有这些类型，而是采集和查询时是否保留了问题需要的证据。

做元数据平台时，很容易先把精力花在资产目录、业务术语和页面分类上。界面做得很完整，任务失败时却还是有人在群里问：这张表谁负责，今天是哪段代码写的，改字段会影响哪些任务？

我更愿意从这些运维问题反推元数据模型。它们有明确答案，也能用一次真实故障检验。平台先把表、任务、实例和运行证据串起来，资产目录才不会只剩一棵需要人工维护的树。

下面用 Apache Atlas 2.1.0 的源码模型做参照。对应提交是 da35519，打包时间在 2020 年 7 月。Atlas 已经提供了实体唯一标识、Process 输入输出、实体变更审计和血缘查询；运行实例仍需要平台自己建模。