灯推的恬静小屋

data-platform-investigator Skill 讲解1. 这个 Skill 是什么data-platform-investigator 是一个专门用于调查数据中台资源的 Codex Skill。 简单说，它的作用是： 当用户用自然语言问“某个业务数据在哪里”“应该用哪些表”“字段是什么意思”“这张表是不是物理表/逻辑表/血缘过程”时，指导 Codex 按固定流程去查业务目录、标准字典、Hive 元数据和 DataRiver 血缘，并给出有证据的答案。 它不是一个普通脚本，也不是一个单独服务。它更像是一份“调查手册 + 工具清单 + 安全边界”。 Codex 看到类似问题时，会先读这个 Skill，然后按里面的流程做事。 例如用户问： 1帮我查一下学生期末评价完成状态应该用哪些表，字段大概是什么含义 这个 Skill 会指导 Codex： 先从业务目录和标准字典里找候选资源。 再确认这些候选资源是不是真实 Hive 表。 再查字段、字段注释、存储位置。 再看 DataRiver 里有没有血缘或加工过程。 最后把“应该用哪张表、字段是什么意思、 ...

头条文章《企业数据资产管理核心框架：L1-L5分层架构解析》阅读汇报来源：今日头条文章标题：企业数据资产管理核心框架：L1-L5分层架构解析发布时间：2026-05-27 11:02作者：星语拾闻整理时间：2026-05-28 一、文章核心内容这篇文章讲的是企业如何用 L1-L5 五层结构管理数据资产。它的核心思想不是“多建几层目录”，而是把一个模糊的业务问题，逐步翻译成技术系统里可以查到的表和字段。 最简单的理解方式是：L1-L5 是一个从业务到数据的放大镜。 12345L1 业务域：公司在做哪一大块事L2 主题域：这块业务里有哪些主题L3 业务对象：这个主题里管理的核心东西是什么L4 逻辑实体：这个东西在数据模型里拆成哪些表/实体L5 属性：每张表/实体里有哪些字段 文章认为，这套分层结构来自数据仓库和企业架构实践，主要受维度建模、范式建模和企业架构框架影响。它要解决的是企业数据管理中常见的几个问题：数据孤岛、口径不一、业务人员看不懂、技术人员难复用、同名不同义、同义不同名。 二、L1-L5 到底是什么关系L1-L5 不是五个并列分类，而是一条逐层变具体的链路： 1大业务 -&g ...

EDBT 2026 · Experiments & Analyses · Schema Linking 让 LLM 先找对表和字段 这篇论文回答的是一个很工程的问题：用户问完一句话后，LLM 到底能不能先判断需要哪些表、哪些字段，再交给 Text-to-SQL 写 SQL？作者没有发明一个花哨大模型，而是把 few-shot、问题拆解、微调、规则修正、schema enrichment 逐项实验，告诉我们哪些做法真的有用。 论文：In-depth Analysis of LLM-based Schema Linking 出处：EDBT 2026 数据集：Spider + BIRD 代码：IBM/few-shot-schema-linking 做了什么 怎么做 规则修正 实验结果 创新点 项目落地 ...

AAAI 2026 · Text-to-SQL · Schema Linking AutoLink：让智能问询自己找字段 这篇论文把 schema linking 从“一次性把全库 schema 塞给 LLM”改造成“agent 逐步探索、检索、验证、扩展字段”的过程。对 skill + MCP 连接数据库的智能问询系统，参考价值非常直接。 论文：AutoLink 场景：大规模数据库 Text-to-SQL 核心：schema exploration + vector search + verification 代码：github.com/wzy416/AutoLink 核心想法 解决什么 方法拆解 Action Space 实验结果 对 MCP 项目的启发 审稿式评价 ...

前一轮实验把 DeepSeek 放在“查询时过滤候选概念和关系”的位置，结果说明它很适合做噪声过滤器。这一轮继续往前推一步：如果不只在查询时调用模型，而是让 DeepSeek 直接参与“全量标准字典生成”，字典本身会不会变得更干净？如果再叠加查询时过滤，能不能得到更稳定的检索排序？ 本文保留实验方法、核心指标和结论，但不公开本地路径、运行日志路径和内部产物路径。 一、实验目标本轮实验分两步。 第一步让 DeepSeek 直接参与“全量标准字典生成”： 基于 595 条资源目录生成新的全量字典。 保留原有概念 ID 和表覆盖范围，保证可以和前面实验直接对比。 让 DeepSeek 重写概念名、描述、别名、字段关键词和关系。 使用同一套 100 条评测问题重新评估。 第二步验证混合方案： 123DeepSeek 离线生成全量字典+ 查询时 DeepSeek 过滤候选概念和关系= 混合方案 也就是说，既让字典本身更干净，又让模型在具体问题上继续做一次“是否真相关”的判断。 二、实验产物本轮实验涉及三类产物： 产物 说明 DeepSeek 生成全量字典 由 DeepSee ...

这轮实验想回答一个很具体的问题：在数据中台资源检索场景里，标准字典和关系字典已经能扩大召回，但也会带来噪声；如果把 DeepSeek 放进流程，让它先判断候选概念和候选关系是否真的服务于当前问题，最终检索质量会不会更稳。 本文保留实验流程、指标和结论，但对本地路径、产物路径、样本 ID、真实业务系统名和真实表名做了脱敏处理。 一、实验目的实验目标是验证“标准字典 + 关系字典 + 大模型判断”是否能提升数据提取和数据处理时的资源命中质量。 前一轮实验发现：全量候选字典可以覆盖更多业务概念和表字段，但自动生成的字典会引入噪声，导致标准字典和关系增强字典在部分排序指标上反而低于无字典检索。因此本轮把 DeepSeek 加入流程，用大模型对候选概念和候选关系做过滤，再重新评估检索结果。 本轮实验暂不包含人工确认，人工复核只作为下一轮实验准备。 二、实验对象 项目 说明 实验环境 隔离副本，不直接修改原项目 候选字典 全量标准字典 评测问题 100 条 实验模型 deepseek-v4-flash 生成时间 2026-05-21 18:19:16 100 条评 ...

本文整理了两个部分： 数据中台当前的元数据架构与只读检索链路。 在隔离实验副本中进行的标准字典迁移实验与评测结果。 原始项目保持不动，所有实验都在复制出来的新目录里完成。 一、数据中台架构1.1 总体链路 flowchart LR Q[自然语言问题] --> S[Codex / Skill] S --> M[MCP 服务] M --> C[业务目录 catalog.json] M --> H[Hive Metastore] M --> D[DataRiver 元数据图谱] M --> R[别名归一 / 资源解析 / 血缘解释] R --> O[候选表 / 字段语义 / 关系说明] 这套架构的核心不是“直接写 SQL”，而是把问题拆成可解释的元数据检索步骤： 先把用户的自然语言问题转成业务概念。 再从业务目录、Hive Metastore 和 DataRiver 图谱里找证据。 最后输出候选表、字段语义、别名、血缘和解释。 1.2 关键组件 组件 ...

这篇论文想让机器真正读懂科学实验流程。论文里的实验步骤原本是一段段自然语言。SCHEMA-MINERpro 做的事，是把它们整理成标准化 schema，再把温度、压力、时间、能量这些字段连到 QUDT 本体，让它们可以被搜索、比较和复用。一句话它把“论文里写的实验描述”变成“机器能懂的实验卡片”。LLM 读论文专家纠错Agent 对齐本体QUDT 统一单位最核心的价值以后你可以问机器：“找出所有低于 (200^\circ C)、使用 TMA precursor 的 ALD 实验”，而不是人工一篇篇翻论文。 先看一个例子假设一篇 ALD 论文里有一句话：论文原文The Al₂O₃ film was deposited at 200 °C using trimethylaluminum and H₂O. The TMA pulse time was 0.1 s, followed by a 5 s N₂ purge. The growth per cycle was 1.1 Å/cycle.→机器真正需要的结构process: Atomic Layer Deposition materi ...

ICLR 2026 under review · Docs2Table / FGLM / DDST 把 10 篇长文档，压成一张可比较、可约束、可复现的结构化表 这篇论文真正要解决的，不是“让 LLM 再抽点信息”，而是把多文档比较分析这件事， 从单文生成升级成 schema-first 的结构化流程： 先决定表该长什么样，再决定每个格子该填什么。 先看结果与结论 直接看 DDST 流水线 任务：Docs2Table 数据：FGLM，1,802 条样本，每条 10 篇文档 领域：Finance / Government / Law / Medicine ...

论文精读 · arXiv:2603.18014v2 · 2026-03-31 实时判断结构化输出，哪里值得信。 这篇论文提出 CONSTRUCT：一个不训练 detector、不依赖 logprobs、可用于黑盒 LLM API 的实时 trustworthiness scoring 方法。核心目标不是让 LLM 少犯错，而是在企业文档处理里把错误输出和错误字段更早、更准地暴露出来。 看方法 看复现细节 5 次并行 verifier calls per-document + per-field 4 个高质量 benchmark GPT-5 / Gemini 3 Pro 等模型 prompt = ...