archDentureBranch 在展开 exam_findings 的 JSON 数组之前没有任何文本级过滤, 而兄弟分支 RESTORATION_IN_PLACE 那条本来就先在整段文本上过滤了(rsrc 子查询)。 这是漏了,不是有意为之。 ARCH_DENTURE_UPPER_RE / LOWER_RE 两条都要求句中出现「义齿|假牙」,所以整段 exam_findings 里一个都没有时,任何条目都不可能命中 —— 预过滤逻辑上恒等,只剪枝。 2026-08-29 测试库实测: exam_findings 是数组的 emr 事实 1,519,829 份,含「义齿|假牙」的仅 7,396(0.49%) 按患者相关子查询(实际形态,300 患者样本):832.7ms → 49.7ms,快 16.7 倍,结果一致⛔ 注释里写死了一条反向提醒:别用「全表扫」形态验证本优化 —— 那个形态两边都是 81 秒(顺序扫描 + detoast 压倒一切),看不出差别,照着那个数会误以为没用而删掉。 我自己 2026-08-29 就先测错了这一次。批量路径接近全表扫形态,收益不明显; 吃到 16.7 倍的是单患者路径(详情页刷新 / recomputeForPatient / reparse 后定向重算)。 tests/arch-denture-false-missing.spec.ts 新增一组用例锁「预过滤词必须始终是 两条 RE 的必要条件」的蕴含关系 —— 一旦不成立,预过滤会静默丢真命中(少召不报错)。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| enums | Loading commit data... | |
| schemas | Loading commit data... | |
| utils | Loading commit data... | |
| canonical-codes.ts | Loading commit data... | |
| clinical-signals.ts | Loading commit data... | |
| host-action-message.ts | Loading commit data... | |
| index.ts | Loading commit data... | |
| kin-relationship.ts | Loading commit data... | |
| labels.ts | Loading commit data... | |
| persona-feature-specs.ts | Loading commit data... | |
| persona-tag-filters.ts | Loading commit data... | |
| plan-reason-focus.ts | Loading commit data... | |
| potential-label-rules.ts | Loading commit data... | |
| temperature.ts | Loading commit data... | |
| visit-recency.ts | Loading commit data... |