database · E1 预消化简报(2026-10-27)

作者：Jay · 轮次：E1 日间预消化(database) · 模式：宿主机增量清单(manifest d71a4202-68b2-455a-bff8-f7f12a8714b4,created_at 1793103601 / expires_at 1793107201,读取时未过期;items 共 8 件,score 8)

本轮只处理清单 8 件 material,不做全库扫描、不联网补料、不为凑字数多轮重写。凡结论均给出处;凡出处未覆盖的内容一律留空为"待核查",不补写推断数字。 活文档参照:organized/knowledge/database.md(当前正文版本 R-110,更新 2026-10-25 20:40)+ organized/knowledge/.database-candidate.md(已含 R-111 候选稿,尚未晋级正文)。

0. 一句话结论

本批 8 件 material 中,对 database 主题构成实质新增量的只有 3 件:colinhacks/reylo(repo_card,工程主轴级)、arXiv:2610.32616(LLM 批量抽取 legacy 报告)、arXiv:2610.32943(item/code 空间蒸馏,弱邻接)。另 4 件(people-context、openidea、SwAV 1911.05371、flyp 反方审稿、relocateme Substack)已在 R-110 入库,1 件(1409.0575)已在 R-111 候选稿中登记,均不构成新观点,不得重复计入;1 件(Import AI 478)属 reproduction 主题,不入 database 主轴。不升 §2.12 层数、不升 §2.15 轴、不改 §3 共识与争议、不改 §6 arXiv 锚定计数之外的新增(仅建议 §6 新增 2610.32943 / 2610.32616 两个 ID)。

1. 增量 1(工程主轴级)· colinhacks/reylo:把「活库 catalog」变成编译期护栏

• 来源:organized/repo_cards/4563-colinhacks-reylo.md(主题标签 llm-infra, database · 主分类 llm-infra · 形态 app · Rust · MIT · 1297★ · 周增 +737 · 最近提交 2026-10-26 · 首次采集 2026-10-23 · 采集态 2026-10-27);补充可核查细节取自本库既有 organized/guides/colinhacks-reylo.md(作者 Tom,更新 2026-10-23,README/package.json/官网 reylo.dev/llms.txt 实际抓取)。
• 要点(全部有出处,未补写):
• 机制:把 .sql 文件作为 TypeScript content mapper 直接 import,行类型/参数类型/可空性/返回行数从真实开发库的 catalog 推出;不做 codegen、无生成文件、无 watcher;类型检查时 tsc 调 Reylo 向数据库 prepare(不执行) 查询,由数据库自己报错(例:Postgres: get_user.sql:1:12 - error reylo6: column "nmae" does not exist (42703)),错误定位到行列。
• 载体:Rust 引擎产出 engine.wasm,随 @reylosql/postgres / mysql / sqlite 分发;TS 侧 src/mapper.ts + src/register.ts + src/cli.ts;示例工程 11 个。
• 前置条件三项(均为硬约束):TypeScript 7.1(当时处于 beta)、Node ≥24、一个跑着的开发数据库(PG / MySQL 8.0.22+ / SQLite 文件)。
• 版本口径:npm reylo 与三个 @reylosql/* 均为 0.3.0(发布于 2026-10-22T22:42:37Z),peerDependencies 写死同版本,三包版本必须严格一致。
• 缓存:类型结果缓存在 .reylo/,键为 schema 指纹 → 迁移后下一次类型检查即看到新 schema。
• 与活文档 database.md 现有脉络的关系: 1. §2.9(ML4DB / Schema 演化与自治调优)——本页此前记录 schema 演化时,落点是引擎侧自治调优(R-50 vec2vec/LA2M、R-51 Agentic-SQL、R-54/R-55 pgvector 量化、R-81 openGauss DTCC、R-98 QueryOptimization 三件)。reylo 补的是另一侧:应用/编译期侧对 schema 漂移的即时反映——"手写行类型必然腐烂"这一老问题,被"类型直接从 SQL + 活库长出来"替代。这与 §2.9 现有条目不重合,是同一问题的下游解法。 2. §2.2(SQLMorph + HarnessSQL + ARCS 三角)——SQLMorph 治的是查询变异/变异引擎,HarnessSQL 治的是harness-native 训练,ARCS 治的是提问歧义;reylo 治的是查询写错时的发现时机(把运行时事故提前到编译期)。三者合起来可勾出"DB Agent 可靠性"的一条完整轴:歧义 → 生成 → 校验,reylo 是"校验"这一端目前缺失的一环。 3. §2.15(LLM × DB 融合十八轴 → 第三十四轴)——reylo 把 DB catalog 变成 LLM/agent 消费的强类型接口,与"数据库 Agent 成为 first-class 实体"(trend 110)同向;其"事实单一存放 + 编译期拒绝漏改调用方"与本库 llm-infra 侧 v3.68 已登记的 C379「断言的放置位置是工程自由度」/ C380「护栏从运行期下沉到构建期」 完全同构(该结论登记在 organized/knowledge/llm-infra.md,非本页,此处只作跨文档互证,不作为本页新证据)。 4. §2.1(向量库选型)——无关联,不要硬拉:reylo 不涉及 ANN/IVF/向量索引。
• 建议归入哪一节:§2.9 邻接 1 件(主,schema 漂移的编译期护栏)+ §2.15 邻接 1 件(候选轴「DB catalog 作为 agent 可消费的类型接口」,不升第三十五轴正式版)+ §2.2 交叉参考一句(补"校验"端)。不进 §2.12(形态 app/工具,非数据层承载端),不进 §3 共识(单样本),不进 §5 趋势(仅 1 件)。
• 证据边界 / 警示(不得省略):
• ⚠️ star 读数冲突:同一仓库同周出现 516★ 与 1,297★ 两个读数(1297★ 为本 repo_card 采集值),llm-infra.md 已就此立 D285,增长真实性本轮不判定。
• ⚠️ "活库 prepare 读 catalog"要求开发期可达数据库:在 CI 隔离 / 预发无库 / 生产禁连的场景下,是否存在离线快照或 mock 路径未说明——若无,"agent 友好"在企业 CI 中不成立。此为最硬的落地约束,必须原样带入正文。
• ⚠️ 类型检查耗时未披露(每次 query prepare + catalog 读取的延迟量级缺失),属"待补硬字段",故不得给出任何性能结论。
• ⚠️ 依赖 TypeScript 7.1 beta,属预览期依赖,版本漂移风险未评估。

2. 增量 2(学术邻接 · 仅方法描述)· arXiv:2610.32616:LLM 把 legacy 大批量档案重抽成结构化字段

• 来源:inbox/jay/2026-10-27-1105-engineering-brief.md(Jay · 工程实践简报 2026-10-27 11:05 · "database / backend" 节)· 论文链接 https://papers.cool/arxiv/2610.32616(标题:From archive to resource: bringing legacy data back to life at scale with large language models)。
• 要点:
• 方法轮廓:用 LLM 把 fasting、anesthesia、laboratory instrumentation 等 study-context 细节,从大批 legacy 预临床报告中批量重抽为结构化字段。
• 证据等级:仅方法描述——无量化结果、无源码、无抽取准确率。
• 与活文档 database.md 现有脉络的关系: 1. §2.9 是最贴近的落点:本页 §2.9 的既有条目多为"让数据库自己改 schema / 自己调优",2610.32616 是反方向的路径——存量异构档案 → 结构化字段,即把"非结构化历史数据"变成可查询、可索引的数据层资产。这与 §2.9 "Schema 演化"互补(前者造新 schema,后者把旧数据补齐进 schema),但不是同一件事。 2. 与 §2.12 三十九层矩阵(检索/承载端形态)不构成新层:2610.32616 是一篇方法论文,不是可并列的数据层形态。 3. 与本页"LLM 抽取"类工作(如 §2.2 提到的 structured disambiguation、§2.10 RAG 评估)只有方法论邻接:它关心的是字段抽取的准确性与幻觉/漏抽处理,不是检索质量。
• 建议归入哪一节:§2.9 邻接 1 件(弱证据条目),正文必须带"仅方法描述"标注;或作为 §2.9 的一条 ⚠️ 待核查线索记录。不进 §5 趋势、不进 §3 共识、不进 §6 性能型锚定(只有 arXiv ID 进锚定清单)。
• 证据边界 / 待核查:抽取准确率、字段 schema 设计、幻觉与漏抽的处理方式三项全缺;原文未读(excerpt 之外未核实)。引用时必须注明"仅方法描述",不得表述为"大规模抽取已验证有效"。

3. 增量 3(学术弱邻接)· arXiv:2610.32943:item 空间与 code 空间之间的分布对齐蒸馏

• 来源:同 inbox/jay/2026-10-27-1105-engineering-brief.md · https://papers.cool/arxiv/2610.32943(标题:Knowledge Distillation across Item and Code Spaces for Parallel Generative Recommendation)。同材料在 inbox/spark/2026-10-27-agent-e1prep.md 已有 agent 主题的独立判读(stephen 协调检查 2026-10-27T1245 亦记录该对论文被 Jay 多份草稿共享,需一次性去重归档——该去重属他人实例动作,本轮不代劳)。
• 要点:
• 两个可复现的蒸馏目标:① IDM——从学生的并行 code 预测重建目录级 item 分布,并与教师分布对齐;② CMM——把教师的 item 概率按固定 item→code 映射投影到各 code 位置,再匹配 code 边缘分布。
• 量化结果(仅 excerpt 内给出的原值):Recall@10 平均 +15.39%、NDCG@10 +8.28%。
• 证据边界:excerpt 未交代数据集规模、基线模型、训练成本;excerpt 亦未说明两项指标是否来自同一实验配置。
• 与活文档 database.md 现有脉络的关系: 1. 方法论邻接于 §2.1 的"原型/分布"线:§2.1 因 SwAV(arXiv:1911.05371,ICLR 2020)新立"向量索引的算法血统"子节,主张向量库倒排分桶与自监督原型分配共享同一"原型分配"原语(功能类比,非历史断言,见 O184)。2610.32943 恰好提供"两个 code 空间 ↔ item 空间的分布对齐目标",在形式上比 SwAV 更接近"可写下来的损失函数"——但它服务的对象是并行生成式推荐的 item 目录,不是向量索引。 2. 与 §2.2/§2.9 的关系为零:它不涉及 SQL、Text-to-SQL、schema、向量索引或存储引擎。 3. 因此在 database 页上,它最多是一条"分布对齐方法论"邻接观察,不构成任何 database 技术主张。
• 建议归入哪一节:§2.1 邻接 1 行(与 SwAV 谱系段相邻,定位为"分布对齐的另一种可形式化写法",明确标注为推荐系统域)或直接不入正文、只在候选稿留一条 ⚠️。建议归入 §5 趋势?否——单域结果 + 数字未核实,不可升格。
• 证据边界 / 警示:
• ⚠️ +15.39% / +8.28% 不得作为性能结论引用:缺数据集规模、基线、训练成本,且未确认两项指标同配置;固定 item→code 映射在目录结构变化时如何维护未交代(这一点恰好是 database 侧读者会问的:映射是硬编码还是可重训)。
• ⚠️ 领域错位:推荐系统 ≠ 数据层,不可借"检索/蒸馏对照基线"之名把它写成 database 页的方法论支撑。

4. 不构成新增量的 material(已入库 / 主题不符),逐件列明以免重复计数

5. 值得警惕的矛盾 / 待核实说法(今晚接力时优先处理)

1. reylo 的 star 读数冲突(516★ vs 1,297★)与"活库可达"硬约束(本轮最需要落笔的警示)。前者是同周双读数,后者决定它在企业 CI 里能不能用。两项都已由 llm-infra.md 的 D285 记录在案,database 侧引用时须原样带上,不得只抄"+737 周增"这个漂亮数字。
2. 跨实例重复稿:2610.32943 / 2610.32616 同时出现在 Jay 的多份草稿、spark 的 agent e1prep、stephen 的协调检查中。stephen 已提出"以 Jay 的 engineering-screen(量化最完整)与 engineering-e1prep(入库判定最明确)为主稿、其余标已覆盖"的去重方案,但归档判定涉及各实例自留档策略,需人工确认。本轮不代为归档、不改他人文件,只在此登记冲突面。
3. 2610.32943 的两项指标是否同配置未知;+15.39% / +8.28% 与 §3 争议 3 关心的"同层基线对照"是同一类问题——本库本页多轮记的评测数字本就存在粒度/配置混淆风险,该件不应成为反例。
4. 2610.32616 与"被引变化/采集时间不是新观点"的界线:该件本轮只提供方法轮廓,不得因"新出现"而当成 database 页的结构化抽取能力证据。
5. 本轮 8 件中,已入库 5 件 + 待晋级 1 件 + 主题不符 1 件 = 7 件零新增,命中率低是清单的正常现象(宿主机增量清单按"未处理"派发,历史材料会重复出现),不应因此加读材料或凑篇幅。

6. 可引用的 arXiv 号列表

本轮新增可入 §6 锚定清单(2 个) - arXiv:2610.32943 — Knowledge Distillation across Item and Code Spaces for Parallel Generative Recommendation · https://papers.cool/arxiv/2610.32943(经 Jay 2026-10-27 11:05 工程实践简报引入;弱邻接,仅方法+excerpt 数值) - arXiv:2610.32616 — From archive to resource: bringing legacy data back to life at scale with large language models · https://papers.cool/arxiv/2610.32616(同上;仅方法描述)

本轮 material 中出现、但已在本页锚定(不重复计数,供今晚核对引用) - arXiv:1911.05371(SwAV · R-110 §2.1 谱系锚点) - arXiv:1409.0575(ILSVRC · R-111 候选稿 §2.1 制度性溯源锚 + O191) - arXiv:2610.13695(legal-KG · R-110 §2.12/§2.13 + §3 争议 3 + O186) - arXiv:2610.13735(Orthros · R-110 §2.14 降级为弱邻接) - arXiv:2610.13361(AgentSWE · R-110 §2.14 降级为弱邻接)

7. 今晚接力的建议动作(不含执行)

• §2.9 补 reylo 一条(主)+ 2610.32616 一条(弱,标"仅方法描述");§2.15 只作候选观察(不升第三十五轴正式版);§2.2 补一句"校验端"交叉引用。
• §4 开题 可新立 1 条 O(reylo 在 CI 隔离下是否存在离线路径 + 类型检查开销量级),与 llm-infra.md 的 D285 保持同口径、避免两页各写一份数值冲突。
• §3 / §5 不动:本轮无新争议、无新趋势证据(单一工程样本 + 未核实数字,不满足升格条件)。
• §6 锚定:arXiv ID 320 → 322(按 R-111 候选稿口径再加 2610.32943 / 2610.32616);DOI 本轮0 新增(两件 excerpt 未给 DOI);URL 按实际新增计入;CVE 0 新增;GitHub repo 按候选稿口径 +1(reylo)。
• R-111 → R-112 的边界:若今晚做 R-112,须先确认 .database-candidate.md(R-111)已晋级为正文,否则 1409.0575、2004.11362、GreptimeDB RCA 等会被重复计入。

边界声明:本轮只写本文件 1 个(inbox/jay/2026-10-27-database-e1prep.md,整篇 write,未使用 edit);未写他人目录、未写 knowledge/、未写 review/、未 git、未输出任何密钥/Token;未修改 manifest / 基线 / 认领记录 / 定时配置;未联网检索、未做全库扫描、未为凑字数多轮重写;所有条目均保留可核查出处,采集时间与被引变化不作为新观点计入。