Commit Graph

10 Commits

Author SHA1 Message Date
ThearchyHelios 975dde1146 起草引擎按验收修正:列分段均分、超时拆小、段大小随模型减半、每段 8 次封顶、提醒、超时与没写出来的计数、模型留空的列、不插队、原因写清哪几段哪几列
- 均分:超过 40 列的表,列分段数是列数除以 40 向上取整,各段列数平均(相差不超过 1),不再留下 2 到 8 列的尾段(实测
  会思考的模型常对这种小段只给空壳);表级那段、窄表拼段、parts_total 不变。
- 拆不开的段(不到 10 列)只给空壳:再问一次,结构化输出换纯文本,已经走纯文本的原样再问,仍是空壳才记没写出来。
- 超时当作这一段太大:不再原样重试同样大小的段,按额度用完的办法拆小再问;网络错误、429、5xx 仍原样退避重试。
- 段大小随模型调整:一次起草里额度用完或超时累计 2 次,之后新开始的段列数上限减半(40 → 20 → 10,最低 10),新开始
  的段超过上限就先按上限均分开(多表的段按表重新拼);任务记当前的上限 part_columns。
- 封顶:一段(连同它拆出来的、补问的、重试的)最多调用 8 次,到了次数还没写完的记没写出来、原因写清。止损照旧。
- 提醒:最近 6 次调用有 4 次以上没写出来(额度用完、超时、空壳、出错),任务的 notice 写一句提醒(次数、原因,建议在
  「设置 → 偏好设置」的「起草模型」换一个模型、减少表或停止);之后最近 6 次里少于 2 次就清掉。
- 用量:进度回调 usage 换成 call_done(CallReport:用量、没写出来的原因种类、当前的提醒和列数上限),任务的用量加
  timeouts、failed_calls;超时的调用 token 照实记 0。
- 留空的列:请模型写了、模型也列出了,中文名和含义却都没给(或者给的都没通过校验)的列记在 ModelOutcome.blank,逐表
  记 blank_columns 和最多 5 个列名 blank_sample,任务上是合计,目录清单的 last_draft 也带列数;表的状态不因此变。已确认
  的、库注释已经说清的列不算。补问时把漏的列列出来、字段却留空的,算留空,不再记成「漏了这些列」。
- 公平排队:宽表的表级那段写完,它的列分段排到已经排着的段后面(先来先服务),不再插到队首让窄表一直等。
- 原因:几段因为同一个原因没写出来时说「这几段」,同一段拆出来的几块仍是「这一段」;只有真拆小过才补「已拆小重试仍
  没写出」(截断后只补剩下的不算);每段写上列的范围,例如「第 5 段(列名 到 列名,共 33 列)」,窄表写出是哪几列。
- 库:catalog_draft_jobs 加 timeouts、failed_calls、part_columns、notice,catalog_draft_tasks 加 blank_columns、
  blank_sample,旧库启动时补列(存量回填 0 和空)。假模型加 hang(头几次调用一直不回,用来模拟超时)。
2026-10-13 20:30:02 +08:00
ThearchyHelios 645064fe47 数据目录重新起草不丢内容;库注释就是名字本身或标识符写法的不当中文名
- 合并(merge_notes)只改模型起草这一个来源的「覆盖即删」:模型这次对某一项没给值(留空,或者给的值没通过校验、在
  _from_model 里就丢掉了),以前模型起草的项留着,只有给了合格的新值才替换。只有这一轮完整起草过(covered 含 llm)、
  而这一项说的列已经不在表结构里(列级的项看列名,业务主键、业务日期看它们指着的列)才删;write_draft 把表结构里的
  列名交给合并。注释、外键、命名推断、剖析各自的规矩不变,人工确认、驳回的不动。删除数因此只在真删时才有。
  以前整库重跑一次,模型这次没给的几百项全被删掉,有的表覆盖率从八成多掉到五成,表仍记「已完成」。
- 库注释(comment_role):和表名(列注释和列名)相同(忽略大小写、下划线、连字符、空白,表名带 schema 前缀的也比
  不带前缀的),或者是标识符写法(只有字母、数字、下划线、点,不带空格),不当中文名、也不当说明,不记进目录;交给
  模型的表结构里照旧有这条注释。以前这种注释短、不带句读就当中文名,库注释的级别又高于模型起草,模型起草的中文名
  永远进不了目录。已有目录不另做迁移:起草到那张表时,旧的那条随这一轮的注释删掉,模型起草的中文名就能进来。
2026-10-13 20:30:02 +08:00
ThearchyHelios c3105bba4f 起草引擎按失败原因处理的三处修正:结构化输出回了一段说明文字(不是 JSON、也没停在额度上,例如网关接受了 response_format 却没照做)不再因为带着思考就当成额度用完去拆,也不直接判失败,这次起草后面改走纯文本、这一段换纯文本问一次(纯文本另带格式说明);只有停在额度上、或者正文为空而有思考才算额度用完。补问之后整列没列出来的列记没写出来(「模型的回复里漏了这些列,补问一次仍没有给出」),表是 partial、covered 不含 llm,以前起草过的待确认模型项不再被删(以前补问只给空壳也记 ok,还把这一轮没给的旧项删掉);列出了、字段留空的照旧算拿不准;补问时整张表还一项都没有的,照只给空壳的规矩拆小、换纯文本,不直接记失败。几处没写出来的原因按基础原因去重,拆小重试过的在最后补一句,不再出现同一句说两遍。假模型照提示词把请写的列都列出来(字段留空是拿不准),要模拟漏列的传 list_all=False 2026-10-13 16:42:45 +08:00
ThearchyHelios 6b1f63a9dc 数据目录模型起草换成分段、按失败原因处理的引擎(data/catalog_draft.py):每次最多 4 张表、40 列,窄表按顺序拼段,宽表拆成「表级一段 + 每 40 列一段」,列分段带着表注释和表级起草结果做背景,最后合并照旧逐项校验;思考和输出用完额度、只给空壳时拆成两半再问(最少 5 列、最多 3 层),拆不开的空壳换纯文本问一次,写出来了后面都走纯文本;被截断的 JSON 先捡回已完整的表和列、只补剩下的;缺了的表和列只补缺的、补一次;服务方嫌额度大时退回 8192、结构化输出不支持时改走纯文本,都管到这次起草结束;网络错误、429、5xx、超时退避重试最多 2 次;单次调用 420 秒;全进程最多 3 个调用同时进行;报错写原因和办法(第几段、共几列没写出来、可以只重试这张表);提示词加上起草要求一段(数据源说明、起草要求、本次说明,规矩在前、冲突以规矩为准)和「思考时不必逐列草拟」;同步起草改用新引擎,写入抽成每张表一结束就能调的 write_draft 2026-10-13 15:19:06 +08:00
ThearchyHelios 0df5e7d4af A2 模型起草一项都没写进去时不再算成功:认出没有 tables 外壳的单个表对象;结构化输出是空壳(只有表名、没有可用字段)时改走纯文本再问一次;某张表最终没有可用内容记 model_error「模型没有给出这张表的可用内容」;起草结果每张表多一个 model_items(模型给了几项可用内容),界面据此区分「和现有目录一致」与「模型没给内容」;「没有变化」改为只说起草出的内容与现有目录一致,另加「目录没有更新」一句;假模型能模拟空壳、单个对象、某条路不可用三种实测回复 2026-10-04 02:19:26 +08:00
ThearchyHelios 913ed9d2c4 命名推断认业务前缀、SQL 检查认兄弟关联:表名带业务前缀、列名只写词根时推不出关系,两张表各自指向同一张父表、彼此相连也被当成连错了列——改为直接对不上时按引用表共用的前缀找唯一一张,兄弟关联只提示行数可能成倍 2026-10-03 11:21:03 +08:00
ThearchyHelios e7b1510894 测试里建的数据源用完就删:留在共用测试库里的源会混进助手的数据源清单、触发挑表,别的用例的结果随执行顺序变 2026-10-03 11:09:09 +08:00
ThearchyHelios a340d968fa 数据目录阶段 1A:结构化输出报错时退回纯文本起草,关联关系的校验说明补上空格和修改时间的检查 2026-10-03 09:42:48 +08:00
ThearchyHelios 44b63f78fc 数据目录阶段 1A:新增 /api/datasources/{id}/catalog 接口——表清单、单表、整份提交与单项审阅(乐观锁 409)、同步起草 2026-10-03 09:34:25 +08:00
ThearchyHelios 6f6798153e 数据目录阶段 1A:catalog.py 补齐合并与审阅、注释 / 外键 / 命名推断 / 模型起草、渲染、关系图、使用次数和冻结内容 2026-10-03 09:27:25 +08:00