Commit Graph

10 Commits

Author SHA1 Message Date
ThearchyHelios 1a6082f033 大库的对象索引、探查范围和后台探查(next-round 03 A1),schema_view 预筛与按需加入、剖析事实的后端(A2、遗留 e 的底座)
为什么:几千张表的库以前用不了——探查每个源最多取 200 个对象、按数据库列出的顺序截断,同步请求、整份替换、不排队;
落在窗口外的表在目录、look、剖析里被说成「表已不在」。

做了什么:
- db/models_sources.py:source_objects(对象索引一行一个对象:范围、原因、结构指纹与 struct_version、first_seen / last_seen /
  removed_at、reflected_at、按需加入的留痕)、introspect_jobs / introspect_tasks(后台探查任务与逐表状态)。
- data/source_objects.py:每种方言一条字典查询建对象索引(失败退回 Inspector,上限 5 万,截断时不判删除);探查范围规则
  (options.introspect_scope:通配、按 name_key、排除优先、显式列出 / 移出;有目录的表、已发布模板写死 SQL 用到的表 pinned;
  命中超上限拒绝并说出命中数);唯一的 rebuild_schema_cache 从范围内已反射的行物化 schema_cache(形状不变,另加 scope 摘要);
  三种「不在」分开说(removed / missing / out_of_scope / reflect_failed);按需加入(当场只读反射、落盘、留痕、进程内按源加锁)。
- data/introspect_jobs.py:探查改成后台任务(core/job_runtime,lane kind introspect,和同源起草、剖析串行;按批反射、逐表记状态、
  可停止、读完的照样物化;重启标中断不续跑)。
- api/datasources.py:POST /introspect 返回 202 和任务,dry_run 同步只刷新索引、返回命中数;/introspect-jobs 读任务、停止;
  /introspect-scope 读、预览、保存规则;/schema?table= 带剖析事实、说清三种「不在」;DataSourceOut 加 schema_scope、introspect_job。
- schema_view:search_tables(BM25 倒排,遮罩列只用列名,范围外只按名字和注释、权重低一档)、profile_lines(剖析事实一节,
  附「只供写查询参考」,遮罩按渲染那一刻重滤,上传表格快照不一致时不给)、absent_detail。
- look:候选超过 PREFILTER_LIMIT 时只给预筛结果 + 已用到的表 + 一跳关联;点名或挑中范围外的表按需加入(每次查看最多 4 张),
  look 记录加 added_to_scope、prefiltered;表详情带剖析事实。
- tools/datasource:db_schema__ 加 keyword、不传 table 时只列前 50 张;点名范围外的表按需加入(每次运行最多 8 张);查询结果
  照实列「未按目录检查的表」(unchecked_tables,不新增检查规则);建工具时读剖析事实。
- 剖析:_relation_ends 分清「范围外,可以加入」和「表结构里没有」;任务记上传表格的 snapshot_id;last_facts。表助手、/schema
  用同一段剖析事实。
- 目录接口:清单只列范围内,absent_reason 分开说;GET /catalog/search 查对象索引,POST /catalog/scope/add 加入范围。
- 第 1 波留下的一处:check_valid_filter 和 stored_valid_filter 拼有效记录条件时按 quote_name 强制加引号。
- 工具参数纠错:空着的可选参数不止一个时,只认拼写明显接近的那一个(db_schema 多了 keyword 以后 tabel 仍能纠成 table)。
- 测试:3,000 张表的合成库(对象索引、缺省范围超上限拒绝、规则圈 400 张后台读完、停止、重启标中断、和剖析排队、同步起草
  409)、删除与结构版本、Inspector 回退、截断不判删除、范围规则、pinned、方言金样;改了同步探查的老测试改为等任务做完。
2026-10-16 14:17:06 +08:00
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 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 b078d08ffe 数据目录 F1-A4:码值项加「已列全」标记(complete: true),只有人工明确勾选、或剖析整表统计(没有只看前若干行)得到的码值才有;码值不在码值表中的检查只认标了它的码值表,给模型的话改为提示核对取值,不再叫它照目录里的码值改。以前经对话只补了 status=9 表示作废,之后 status = 1 就被报提醒,模型还可能把对的 SQL 改错。提案补充码值时沿用原有的标记、自己不能标;目录页的码值编辑和填写含义弹窗加「已列出全部取值」勾选,表格里标「已列全」,检查脚本跟上 2026-10-04 01:13:13 +08:00
ThearchyHelios 913ed9d2c4 命名推断认业务前缀、SQL 检查认兄弟关联:表名带业务前缀、列名只写词根时推不出关系,两张表各自指向同一张父表、彼此相连也被当成连错了列——改为直接对不上时按引用表共用的前缀找唯一一张,兄弟关联只提示行数可能成倍 2026-10-03 11:21:03 +08:00
ThearchyHelios 8ed0bc23f7 数据目录阶段 2B:引入 sqlglot,SQL 检查的解析层——按数据源方言解析、认表和别名、解析不了一律跳过 2026-10-03 10:15:52 +08:00
ThearchyHelios 44b63f78fc 数据目录阶段 1A:新增 /api/datasources/{id}/catalog 接口——表清单、单表、整份提交与单项审阅(乐观锁 409)、同步起草 2026-10-03 09:34:25 +08:00
ThearchyHelios e7646532c1 数据目录阶段 1A:探查补读外键和唯一约束(读不到就跳过、不写键),新增 50 张表的合成景区库夹具 2026-10-03 09:30:50 +08:00