自演进编目闭环Self-Evolving Cataloging 首页 架构 使用方法 方法论 建设现状 开发日志

六个功能件 · 三层结构

架构

闭环由六个功能件组成，数据层是纯文件（JSONL/JSON），Web 层是薄壳。 除规则提取外全链路无模型依赖 —— 埋点和分析在任何环境都能跑。

8个命令行命令CLI Commands
12条 HTTP 路由HTTP Routes
2条埋点事件Ingest Events
5种修正原因Reason Labels
6个规则状态Rule States
76个测试Tests Passing
1处用到大模型Single LLM Call

SYSTEM MAP

一图看全：从一次人工修正，到一条能回流的规则。

左边是现网跑着的编目链路，右边是可被审核、可灰度、可回滚的规则。 中间四段流水线，每一段都产出可直接阅读的文件，而不是只留在模型里的印象。 顶上那条线是全系统的硬约束：AI 可以自由归纳，但让规则生效必须有人签字。

总体架构图（窄屏可横向滚动）

自演进编目闭环总体架构图 四段流水线：上游编目链路的人工修正与处理完成事件经埋点接收落盘， 进入差异分析（高频错误字段、错误模式、置信度分箱、率口径）， 再由规则提取用大模型归纳出带样本证据的规则草案， 最后经人工审核、灰度生效与效果验证。顶部一条人工审核边界带说明规则生效必须有人署名且可一键回滚； 底部一条产物带标注每一段落盘的文件；一条虚线表示生效规则按模块层回流到上游链路，该段仍在路线图上。 HUMAN GATE · 人工审核边界 AI 可以自由归纳规则草案 —— 但草案跨过这条线才叫生效，跨线必须人工署名； 任何已生效规则都可一键回滚，状态机跳步直接抛异常。 上游编目链路 现网 · 独立系统 54 个业务字段 人机协同工作台 每次人工修字段 → 每条内容处理完 → 准确率约 90%–95%， 最后一段靠人工校订 STAGE 1 埋点接收 corrections 字段级修正事件 · reason 必填 completions 处理完成事件 —— 率的分母 deadletter 校验失败不丢弃，可重放 token 未配置鉴权则拒绝启动 HTTP 与进程内双通道 STAGE 2 差异分析 top_fields 高频错误字段 Top-10 by_reason / by_source 错误模式与来源质量分布 confidence 分箱检验：置信度可不可信 field_rates 按率口径算填充率与修正率 全段无模型依赖 STAGE 3 规则提取 extract 归纳「条件 + 动作 + 理由」 evidence 强制附样本证据，否则不入库 min_samples 样本不足的字段不提规则 conflicts 同字段同条件冲突告警 全链路唯一用模型的一环 · 可 dry-run STAGE 4 审核与验证 review 草案 → 待审 → 灰度 → 全量 canary 先放 10% 流量，再谈全量 rollback 任意状态一键回滚归档 verify 修正率下降 ≥20% 才算达标 跳步流转直接抛异常 ARTIFACTS · 每一段的落盘产物 corrections.jsonl completions.jsonl 追加式，可 grep 差异分析报告 终端表格 / 网页看板 rules.json · 草案 含条件、动作、理由与样本证据 rules.json · 生效 附审核人、灰度比例与验收判定 ROADMAP 生效规则按 field_layer 回流到采集 / 解析 / 生成 / 补全各层 —— 这一段尚未自动化 目前规则的条件与动作是自然语言，仍需人工翻译成采集策略或 prompt 约束

实线是已实现且有测试覆盖的环节；虚线是仍在路线图上的回流段。

功能件与数据流

件职责输入 → 输出依赖模型
F1 修正埋点工作台每保存一次字段修改落一条记录；HTTP webhook 与进程内函数双通道修正事件 → corrections.jsonl否
F2 差异分析高频错误字段排行、错误模式分布、来源分布、置信度分箱检验修正日志 → 分析报告否
F3 规则提取对样本充足的字段，用 LLM 归纳「条件 + 动作 + 理由」草案，强制附样本证据分析结果 → 规则草案是（支持 dry-run）
F4 审核与灰度状态机流转 + 一键回滚，审核必须署名草案 → 生效规则否
F6 效果看板规则生效日前后对比：修正率是否下降 ≥20%日志 + 生效日 → 验收判定否
F9 冲突检测新规则与已生效规则同字段同条件时告警（不阻断）规则库 → 冲突徽标否

规则状态机

草案 待审 灰度 10% 全量生效 已归档 已驳回 任一生效状态可一键回滚归档 跳步流转（如 草案→全量生效）直接抛异常，测试覆盖

规则回流到哪一层

上游编目链路按职责分层（配置 / 采集 / 解析 / 字段生成 / 联网补全 / 输出写入）。 每条修正记录都带 field_layer 标注，规则据此精确回流到对应模块 —— 改一层，不动全链路。这是「白盒可局部优化」原则在架构上的直接体现。

层职责典型规则回流形态
L1 数据采集多源拉取原始数据调整数据源优先级、补采集路径
L2 数据解析快照 → 结构化字典修解析定位、加清洗规则
L3 字段生成映射生成业务字段加归一化规则、调 prompt 约束
L4 联网补全跨源交叉验证补跨语种检索、实体消歧策略

四条不可绕过的红线

1 · reason 非空

修正原因是唯一的训练标签，空值直接抛异常，前端下拉框不可选空。

2 · evidence 非空

规则入库必须附原始修正记录摘要，否则审核人无从判断。

3 · 审核不可自动化

状态机跳步抛异常；错误规则批量放大的风险远大于审核成本。

4 · 坏数据不丢

webhook 校验失败的 payload 进 deadletter 队列，修好 schema 可重放 —— 100% 落盘包括错误数据。

存储与部署形态

数据层刻意选了纯文件：修正日志是可 grep 的 JSONL，规则库是可直接人工审阅的 JSON。 原子写（临时文件 + rename）+ 进程内锁保证单进程一致性；部署约束为单进程， 规模上限明确（数十人工作台足够），复杂度换来的是全链路可解释、可审计、可手工修复。

使用方法 →