 ThearchyHelios
|
7e95703a94
|
结论句裁判与口径账本认分析结论：引用了分析结论的句子，裁判摘录里给方法与版本、判定语、判定标准、关键数、附带说明、结果表（被引用的行先给）、输入取自哪几个 Q 用了哪几列和它们的 SQL、下钻自哪个 A（核查 agent 的摘录照旧分段遮）；摘录里有分析结论时裁判规则另加一条（判定是系统算的，只判句子说法和判定是否一致，分析说明不了原因），没有分析结论的报告规则一字不差。口径账本不给分析结论里的数（判定语、具名标量、结果表的格）标口径、不按它们投影比对、不进整题判断的计数，也不算成没比对
|
2026-10-21 13:07:36 +08:00 |
|
|
ThearchyHelios
|
aee237f457
|
按行号取多行查询里的一格，重跑、核对时行序不定的照实标出来：sql_semantics.ordered / row_stable 认这一行重跑时还是不是同一行（最外层带 ORDER BY 的按位置认，一定只出一行的第 0 行认得住，别的行序不定）。口径账本的比对记下 ordered、one_row，指标标签按「同一行」认来自口径只在行认得住时成立，行序不定的标相关、写明原因；口径召回里两版都按行号取一格、查询又没有 ORDER BY 的指标记行序不定（changed 为空），召回待办上写「行序不定」，不按位置硬比；对账的多行对齐每一组先核对那一行的维度就是它，重跑时缺了一行、多出一行错位的记空值，不拿别的维度的数冒充
|
2026-10-19 10:01:05 +08:00 |
|
|
ThearchyHelios
|
271bc6e782
|
口径标签逐格判：引用了好几列的查询，每个数按它自己那一格标
真实模型下问「上周的销售额是多少」，助手写 SUM(amount) AS 销售额, COUNT(*) AS 订单数, MIN / MAX(paid_date) AS 区间首日 /
末日，报告四列都引用了，口径「周销售」只取 SUM(amount)。按「全部引用列」投影后还是 4 列，对不上口径的 1 列，整条比、
四个数都标相关口径，说明整段兜底。
- ledger/match._cells / _cell（algo 4）：整条（含按全部引用列投影）没证明、又引用了这条查询两列以上的，被引用的每一列单独
投影到那一列，和每份口径的每个指标读的那一列（card_reads；口径版本没有口径卡的按取数的每一列）逐个比，仍只走
match_template / explain_sql_diff，上次的投影规则照用：投影不了（分组列、DISTINCT……）、过了时限、不可比的格照用整条
查询的那一个候选。结果记在 queries[].cells {列名: {status, candidates}}，另记 one_row（sql_semantics.one_row：不分组的
聚合，一定只出一行）。整条这一层的结论、候选一字不改；老工件没有 cells，照旧按整条读。
- ledger/labels：单元格按它那一格的结论标（_view）；指标用了同一条查询的好几格时，只有那条查询一定只出一行才把逐格的
结论合起来用（多行的结果里每一列各自对得上，不等于每一行的几列一起对得上）。整题照拍板 L1 不变：每个数都证明来自
同一份口径才等价；一格证明了、别的格只是相关的整题不等价，原因写「有的数和相关口径不一致，不来自口径」（以前一律说
「这次的推理」）。出具入口照 ledger/issue 现有判法只在整题等价时给，没有放宽。
- 逐格证明了的口径各处都算上（labels.candidates_of）：工件 meta 的 calibers（召回按旧版本反查）、ledger/uses 的使用记录、
召回时找原答案对应的那一格、E4；E1 另数各种结论各几格（cells），E2 的兜底比例按标签上给人看的那一份说明数。
- GET /runs/{id}/ledger 的 queries 带上逐格的 cells（遮罩同候选）；证据片段的 ledger 键、轮次摘要的计数本来就按每个数的
标签，数据变了、形状不变。前端只补类型；check-ledger 加一段：同一条查询一格来自口径（正文挂小标记）、一格相关（差在哪
先说多查了几列），整题不等价不给出具。
- 评测逐题比 SQL（eval/score.sql_match）取和期望配上的那一格（score.matched_cells：评分时配上的格），没给时取逐格证明了
的那一格；结果带 column。runner、rescore 传它。
测试：tests/test_ledger_cells.py（同一条查询一列等价、一列不等价各自标对；两份口径只证明了一份标那一份；口径多个指标按列
配对；指标跨两格只在一行的查询上用逐格结论；分组列、DISTINCT 逐格也不投影；照真实例子造的虚构库真跑一遍：销售额标等价
已证明，订单数、首末日标相关，整题不等价、不给出具、不自动出具，证据片段的 ledger 键一致；评测取配上的那一格）。去掉逐格
再跑，10 条失败；去掉「一行才合起来用」、去掉评测取格，各 1 条失败。
|
2026-10-17 13:07:19 +08:00 |
|
|
ThearchyHelios
|
d4f1ba8dd4
|
给评测留一个按引用的列投影的入口（referenced_of），顺手折行、补模块说明
- ledger/match.referenced_of(sealed)：这次运行封存的报告引用了哪条查询的哪几列，正好是 compare_queries 的 referenced。
评测逐题比 SQL（eval/score.sql_match，另一组在改）传它，就和账本一样按引用的列投影，不必自己再拼一遍。compute 和它
共用读指标集的那一段（_card_loader）。
- data/sql_semantics 模块说明的「几处共用这里」补上模板绑定、按引用的列投影、同一个形状三处。
- 本轮几处新代码折到 120 列以内（只换行，不改逻辑）。
测试：tests/test_ledger_projection.py 的整题等价那条另核 referenced_of 交回的就是被引用的那一列。
|
2026-10-17 12:22:48 +08:00 |
|
|
ThearchyHelios
|
2a4086ab73
|
认口径按答案引用的那几列比：整条比不等价时先投影再交现有的绑定和判等价
真实助手的 SQL 总会多选几列（订单数、日期常量、MIN / MAX、COALESCE），报告只引用其中一列，口径的取数也只选它的指标要的
那几列。以前整条比，「上周的销售额是多少」3/3 只标相关口径、从不自动出具。
做法：sql_semantics 新增 project_select / project_template / output_names。按方言切词、按括号深度认出最外层 SELECT
列表每一项在原文里的起止，只把留下的几项原样拼回去（选择列表前后一字不动，保真守卫照样看得到原文），拼完重新解析、
语法树要和「原树换成留下的几项」一模一样。只在确定去掉不影响时投影，否则照实给原因、照旧整条比：DISTINCT / DISTINCT ON、
出现在 GROUP BY 里、被 ORDER BY / HAVING / QUALIFY / 窗口用到（按别名、同样的写法、按位置）、有 LIMIT / OFFSET 又不是
只出一行的聚合、集合运算、*、可能改变行数或不认识的函数、去掉仅有的聚合、留下按任意一行取值的列、调换先后时引用别的
选择项的名字，一律不去。
ledger/match：整条比不等价时，答案一侧按报告引用了这条查询的哪几列（labels.referenced_columns）投影，口径一侧按口径卡
上每个指标读了这个取数节点的哪几列（labels.card_reads）投影，投影后照样交 match_template（不另开给信任的路）。被引用的
列两边怎么对上写进模块说明：答案按列名在快照结果列里找位置、口径按 cell() 里的列名在输出名里找位置，投影后按位置配对，
答案留下两三列时另试调换先后，每份口径取数最多试 12 种。证明了的候选记 projection；没投影可试的逐对和以前一字不差。
算法版本升到 3；E1 另数 proven_projected；对账按投影后留下的列配对（不用人选）。
测试：tests/test_sql_projection.py（该去的、不该去的各一组，语料里 305 种投影在虚构库上执行守门）、
tests/test_ledger_projection.py（多选一列 / 多几个聚合 / 日期常量列能证明；多一个分组列、DISTINCT、按别的列排序加
LIMIT、HAVING 用到多出来的聚合仍然证明不了且和不投影时一字不差；口径一侧投影、调换先后；真跑一次整题等价；对账配对）。
去掉投影再跑，7 条失败。
|
2026-10-17 11:47:26 +08:00 |
|
|
ThearchyHelios
|
538799e70d
|
沉淀：认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证队列的转化（口径账本做法 8、10，拍板 L9）
为什么：同一类问题被反复问、Agent 反复写出同一个形状的 SQL，就该沉淀成一份口径；以前 from-run 保留 Agent，沉淀出的模板没有固定 SQL，以后永远比对不上。第 2 波的统计在 E2 反馈、E3 认证队列上照实写了「目前没有数据」，这一波补上能补的。
做了什么（新增 ledger/certify.py）：
- GET /api/ledger/certify-queue（搭建者）：确定性重复（问数据运行里被报告引用、没对上口径的查询，按数据源 + normalize_sql 文本分组，≥3 次运行且来自 ≥2 段对话；跨运行变化的字面量是参数候选，展示的形状不带取值）、问题聚类（app/chat/questions 全站唯一的那份）、被反复用的答案（导出 ≥2 次用第 2 波的 report.exported 审计、做成过应用看蓝图来源、在画布里打开或提取过看工作流 origin）。每项给代表问题、轮次、相关口径、是否已固化。
- POST /api/ledger/certify-queue/dismiss：「不是口径」写审计 ledger.certify.dismiss，之后不再进队。
- 固化成口径草稿（from-run 加 freeze、peers 后转调 certify.freeze）：报告引用的查询变成固定 SQL 的取数节点，跨轮变化的字面量换成 '{{ input.pN }}'（缺省值取代表运行的），单行结果的数值列成口径卡指标，报告核对规则按受管要求写、契约 report_from + metrics_from + required（多行加 cells）；过 validate_graph 和受管门禁。新工作流 origin.sources 记来源问题。
- 发布之后补比：api/workflows.commit_publish 提交后调 certify.after_publish，来源运行按新口径补比一次（新的 trigger=certified，界面写「按之后发布的口径回看」，时间线和账本接口同一句）。
- 统计：E2 加对过账的答案数、参数经人核对的、指标由人选的次数（反馈照实写第 4 波）；E3 认证队列的转化（固化、发布、不是口径）。
测试：tests/test_ledger_certify.py（参数推断与模板、三种信号进队、门槛、不是口径、固化草稿过受管门禁、发布后来源运行补比成等价已证明并出队、再问标等价已证明、统计）。
|
2026-10-16 17:06:41 +08:00 |
|
|
ThearchyHelios
|
4f4ad48ad7
|
组合式问数：问数据的助手可以 use_caliber 选用已发布口径，服务端确定性内联实例化（口径账本做法 4，拍板 L3）
为什么：问数据以前看不到口径，也没有组合机制；子图做骨架的路走不通（子图证据不交回父图、使用者用不了子工作流）。改成助手只选口径、填参数，取数节点由服务端按固定版本照抄，证据照常封存、比对照常复证。
做了什么：
- 问数据的查看对象加 caliber（look/calibers 的 compose 模式）：另给每张卡的入口字段（类型、必填、可选值、格式、缺省值）和「能不能组合」（ledger/derive.load_pinned 同一个认法），能组合的写出 use_caliber 的写法；仍不给 SQL。只给搭建者及以上：使用者的图里看得到拷进来的取数 SQL。
- 新增 ledger/compose.py：use_caliber {id, workflow_id, version, card, metrics, inputs} 经 derive.caliber_block（扩了 card_id、inputs 两项）实例化——取数节点照抄、id 加前缀、模板按参数渲染成字面 SQL，口径卡 id 就是操作 id、caliber_from 带改名映射。参数按入口字段过 apps/forms 校验，写进 SQL 引号里的不能带引号、裸写的只能是数；只能选这一轮看到的那一版、能组合的卡、卡上的指标；不合规拒收。
- GraphApplier 落地 use_caliber：节点、连线记进 seen（兜底重放照样在），入口连到第一个取数节点；转给界面的只有那一条操作带 result；拒收的原因经自查交回模型（GraphChecker.issues）。
- 提示：协议多一段 USE_CALIBER_PROMPT；LOOK_WHEN 里问数据那一条按细案改写（只在能选用口径时换）。运行时写 SQL 的 Agent 不看口径（L2）。
- 比对器认出助手选用的查询（从封存的图里读 caliber_from.nodes）：证明了的标 composed「助手选用」，没能证明的照常是相关口径并说明；标签 how=composed，指标标签记取自哪几条查询；比对算法版本升到 2。
- 前端：问数据过程里 use_caliber 照实显示一行（选用了哪一版、生成几个节点；拒收写原因），节点数算进「新增几个步骤」；文案进 LEDGER_TEXT.use；check-decode 加一节。
测试：tests/test_ledger_compose.py（实例化确定性、各种拒收、查看文字不带 SQL、提示切换、落地与接线、拒收交回模型、剧本模型走一遍生成再真跑出 composed 标签、使用者不给口径）。
|
2026-10-16 16:35:28 +08:00 |
|
|
ThearchyHelios
|
5b4bd91476
|
口径账本内核：运行封存后在后台比对已发布口径、逐个数标口径、按运行读的账本接口、来源链和导出留痕、统计 E1–E4
为什么：问数据的答案要和已治理口径接起来（next-round 02 做法 2、3、9、10；总方案 X1、X2、X3、X12，拍板 L2、L4、L8）。
- 比对（ledger/match.py）：探索运行（chat、canvas、trial、personal_app）成功结束、封存完、有查询快照时，在 runner 封存之后和
notify_run 同一个位置放到后台；候选口径是每个工作流最新的已发布未退役版本里查库的调用工具节点（受管、已发布都算），按数据源
和表预筛；逐个用 match_template 比，schema 用查询当时冻结的表结构、列名取同一份快照里冻结的数据目录。每次运行限时 8 秒、在
线程里、同时最多 2 个；超时、快照被改过或读不出、SQL 解析不了照实记 skipped。启动时（run_manager.setup，和调度循环同一个开关）
补比最近 7 天封存了却没比过的运行，只读工件和版本表。
- 记法（ledger/store.py，拍板 L8）：内容寻址工件 kind=caliber_match（agentlab.caliber_match/1）+ run_append 的 sealed 方式追加
ledger.matched（core/events.py 登记）；工件里不放时间和工作流名，同一份封存再比一次哈希一样；meta 记 calibers / related / counts。
- 标签（ledger/labels.py）：单元格按查询的比对状态；指标要每个输入都等价于同一份口径同一版、绑定一致，式子按「哪个取数节点、
第几行、哪一列」换完和口径卡上的一字不差。caliber（how：independent 等价已证明；composed 助手选用留给第 3 波）/ related /
reasoning / unknown；整题判断附还缺的入口字段。
- 读（ledger/view.py）：GET /api/runs/{id}/ledger（ledger_api.runs_router，和证据同一道门），没比对过、能比的按需排上；证据
片段接口加 ledger 键（没比对过的运行没有这个键，返回一字不差）；报告导出的面板最上面多「口径」一步并写明「封存后比对，不在
封存范围内」。遮罩按读的那一刻重滤：绑定的值是这次运行查到过的遮罩值时不给值，差异条目和逐行对照走 _Shown。
- 来源链：POST /api/runs 加 origin_ref（只在 origin=chat 时收，服务端核对对话访问权和轮次归属，写进 Run.origin 和封存的
run.origin）；WorkflowIn 加 origin（run_id、conversation_id、turn_id，核对规则同 from-run）；报告导出和可验证报告下载各记一条
审计 report.exported。可验证报告列封存后追加的事件时给 ledger.matched 一句只有条数的说明。
- 统计（ledger/stats.py）：E1–E4 从工件、运行、查询快照、审计现算，GET /api/ledger/stats（搭建者）；E3 用 app/chat/questions
的聚类加按（数据源、normalize_sql 文本）的确定性重复；评测直接调 compute_stats（可点名 run_ids）。对账反馈、认证转化、按发布
的召回在后面几波，照实写没有数据。
测试：test_ledger_match.py（真跑探索运行：等价、相关、没有相关口径、写死的码值、非探索运行、超时、快照被改、解析失败、预筛、
指标两种、级别、只认最新版、补比）、test_ledger_api.py（账本接口、按需比、遮罩、证据片段、导出、审计、统计）、
test_run_origin_ref.py（origin_ref 与画布来源的核对）。
|
2026-10-16 14:02:55 +08:00 |
|