 ThearchyHelios
|
03c18c4d78
|
界面文案整改：口语改书面、术语统一、不再露出实现细节；修掉几处说错的提示；新增文案检查防回潮
一、文案（前端约 1600 处，后端传到界面的约 880 处）
- 术语统一：工作流层面用「运行」（继续运行、重新运行、试运行），节点和工具层面用「执行」，不再用「跑」；
总时长 / 执行时长 / 等待审批；服务端；助手；Agent；token；工作流；固定版本；模型接入；系统提示；批准 / 驳回；受管级别
- 口语改书面：取不到、没取回来、读不懂、连不上、多半、照样、兜底、揉成这类说法改成「无法 / 未能 / 失败 / 请」；去掉拟人写法
- 不再露出实现细节：界面上不写 checkpoint、同一拍、哈希（凭证处除外），不写改版历史（「以前…」「老数据」）；
报错、校验、门禁、自动修复里裸写的配置键名和枚举值换成界面上的中文标签，由新的 backend/app/engine/labels.py 统一提供；
发布弹窗里结论句的选项不再是 off / require_citation
- 同一件事只留一种说法：生成阶段文案、出具档位说明、画布锁定提示各合成一份
- 去掉界面上的工业场景示例（MES、ERP、「张工」「王工」）和真实产品名，换成通用示例
二、说错的提示（都有测试证明）
- 数据库测连接失败时的专用提示以前从不出现（按报错文字全等比较，永远比不上）：改为按错误类型判断，不再拼出重复的前缀
- 「设置 → 供应商」改指「设置 → 模型接入」；「在设置里建数据源」改指「数据」页
- 缺少 API Key、模型接入已停用的报错不再夹英文，写明去哪里填
- 两处原因说错（「这种引用在后续版本支持」「这一版还不支持」）改成真实原因
- 节点说明里不准确的说法改正：代码节点在 microVM 或系统沙箱中执行；报告撰写、口径卡的说明不再说过头
- 导出的证据 CSV 里两列同名，第三列改为「片段编号」
三、前后端对齐
- 前端按后端原文识别日志、报错的地方，新旧两种写法都认得（历史运行里存的是旧文字），逐条补了新旧原文的核对
- 后端交回模型的原指令放进单独的 for_model 字段，前端在解析响应时去掉，不会显示到界面上
四、检查
- 检查脚本里按原文匹配的断言改成新文案；改完会变成永远成立的反向断言逐条修正，并做了变异验证
- 新增 check-copy（静态扫描前端界面字符串和后端上界面的文案）：再出现「跑」「后端」「多半」「令牌」、
界面上的 Copilot、裸写的配置键名、半角标点等就报错；确需保留的写进 scripts/copy-allow.json 并注明理由
|
2026-09-30 08:05:15 +08:00 |
|
|
ThearchyHelios
|
2a1040bbfc
|
重排给足输出预算；失败提示分清是哪种失败
拿真 provider（deepseek-v4-pro，千帆网关）跑了一遍评测集，重排确实有用：
hit@1 hit@5
初筛 88% 100%
重排后 100% 100%
变动的两题都是语义类的，正好是本地哈希向量的短板——BM25 把「权限」的字面
命中排给了「数据导出」（那篇里有「export 权限」），模型读懂了问的是「谁有权
改」。字面类原本就 100%，没有被重排搞坏。
但 16 次里有 2 次退回了初筛顺序。查下来模型回的是**空字符串**，而失败那次的
out_tokens 正好等于 max_tokens——重排的输出只有一行几十字的 JSON，但模型为了
读完 20 条候选要花 800~1600 个输出 token，顶到上限后正文什么都不剩。llm.py
里对同一个现象早有记录：「思考型模型把额度全花在推理上了，正文是空的」。
所以重排改成有自己的预算（至少 4096），不跟节点上那个走。补跑 16/16 全部成功。
顺带纠正一处判断：thinking=off 救不了这个 provider。实测关思考那组照样在
out_tokens=2048 时空手——factory.py 只在 anthropic 分支里读 thinking 字段，
openai_compatible 整条路径不碰它。仍然传 off，因为对 Anthropic 有效、而且打分
任务本来不需要思考模式，但它不是这次的解药，注释里写明了。
失败提示原来四种坏法统一报「解析不出来」，会把人引去查 JSON 格式，而该调的是
token。现在分开说：空回复 → 「把最大输出 token 调大」；找不到 scores → 带上
原文前 80 字；个数不符 → 说明给了几个、候选几个；混了非数字 → 指出是哪个值。
测试里有一条专门断言空回复的提示中不出现「解析」二字。
|
2026-09-19 11:09:04 +08:00 |
|
|
ThearchyHelios
|
913380f738
|
倒排索引取代全表重算；PDF/Word 终于传得进来
**倒排**：以前每次检索都 select(Chunk) 全量载入，再在 Python 里重建一遍 BM25
——不只是扫表，是对每一段重新分词、重新统计词频，每次查询都来一遍。几百段
无感，上万段就是秒级，而那正是知识库开始有用的规模。
没用 SQLite 的 FTS5。方案里写了实施前先验证，验了：trigram 分词器要求查询
至少三个字符，中文的「商家」「订单」「权限」这些两字词一个都召不回。照搬会
让召回大幅倒退。现有分词器本来就做中文单字 + 二元组，自己存一张 chunk_terms
既保住召回，也不把知识库锁死在 SQLite 上。
快是次要的，一致才是前提——所以先写了"倒排必须和全表扫给出同一个名次"的
测试。它当场抓到两个真问题：
1. BM25 被算了两次：倒排按全集统计（N、avg_len、df）算一次，hybrid_rank
又在候选子集上重建一次，而子集的 df 和平均长度是另一套数。改成把倒排
算好的分传下去，不再重算。
2. 原来的 BM25.score 遍历的是**带重复**的查询词表：「导出订单最多多少行」
里「多」出现两次，贡献就加两次。倒排用 set() 去重，顶部那条差了 2.32。
改成按查询词频加权。
还有一处是排序确定性：分数并列时稳定排序保留输入顺序，而两条路径喂进去的
顺序天生不同——同一个查询会因为走了哪条路给出不同名次。两边都按 id 定序。
倒排跟着 ingest 建、跟着删文档清、跟着 reindex 重建；没建倒排的片段（存量
数据升级上来就是这样）退回全表扫——宁可慢，也不要因为索引没建好就说"没搜到"。
**解析**：upload 以前只收 UTF-8，PDF 传上去直接 415，而 mime 字段记了却从不
参与判断。现在认 PDF / DOCX / HTML。解析库走可选依赖 [docs]（几十兆，只用
纯文本的人不该为此付出安装时间），HTML 用已在依赖里的 bs4。
几处是实际验出来的，不是想出来的：DOCX 要连表格一起取（合同和口径说明的关键
信息常常整个在表里）；PDF 每行拖着排版填充空格，不清掉会混进切块和词频统计
（实测 416 字里只有 68 字是正文）；扫描件提不出文字要明说，否则悄悄存一份
空文档，用户以为传成功了却永远搜不到。
PDF/DOCX 两条路径在临时 venv 里用真文件验过（含中文、表格、扫描件、坏文件），
没有动开发环境。
|
2026-09-19 09:44:09 +08:00 |
|
|
ThearchyHelios
|
e8ef6ff9a8
|
检索质量有数了：评测集 + 重排，alpha 不再写死
先做评测再做重排——否则重排的收益只能靠"搜两下感觉准了"。
**评测集**（test_retrieval_quality.py）：24 篇语料 + 16 个问题，问题分成字面
重叠和纯语义两类。第一版是 8 篇、主指标 hit@3，结果各档 alpha 全是 100%，
等于什么都没量——8 选 3 瞎猜都有 37%。扩语料、加干扰、主指标换成 hit@1
之后才开始能分辨。
量出来的第一个结论就推翻了我原来的猜测：
alpha hit@1 hit@5 MRR 字面 语义
0.0 88% 100% 0.911 100% 75%
0.2 81% 100% 0.880 88% 75%
0.5 81% 100% 0.880 88% 75%
1.0 81% 100% 0.880 88% 75%
本地哈希向量那一路不是"弱一点"，是**纯噪音**：给它任何权重，hit@1 都从 88%
掉到 81%。而 alpha 的默认值一直写死 0.5，等于主动把检索做差。改成跟着
embedder 能力走（default_alpha：有语义泛化才给 0.5，否则 0），节点上的
alpha 也不再写死默认值。
**重排**（memory/rerank.py）：初筛多捞一些（20 条），让模型按"对回答这个问题
有多大帮助"重排，再取 top_n。只捞 5 条的话重排最多把这 5 条换个顺序，第 6
条是对的也救不回来。
用已配置的对话模型做，不引入本地 cross-encoder——后者要下模型权重，和"零配置
能跑起来"的基线冲突。代价是每次检索多一次调用，所以默认关闭。
失败一律退回初筛顺序并说一声：解析不出分数、个数对不上、模型抛异常、没配
provider，四条路径都有测试。重排是增强，不该因为模型抽风就让整个检索挂掉。
|
2026-09-19 09:33:09 +08:00 |
|