4 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	18ad2b89ab	test(memory): 两条审查超时用例搬到正确位置（复审 p2-1，纯搬运） ... 复审指出 TestEmbeddingTimeoutFitsReviewBudget 的整段文档被夹在「它描述的 函数」与「两条新用例」之间成了孤儿文档，而该函数自己的文档只剩一句、且在 文件里出现两次（一次属于那段孤儿注释，一次紧贴真正的函数）。 只搬不改语义：把 TestReviewTimeoutExplicitEnvValueWins 与 TestReviewTimeoutEffectiveValueIsTheOnlyDefault 整体挪到 TestEmbeddingTimeoutFitsReviewBudget 之后，删掉重复的那句文案与多余的空行， 让那 21 行文档重新紧贴它描述的函数（与 dev 版的相对位置逐字相同）。 纯搬运的证据：拿「排序后的行集合」比对搬运前后（前者取自 HEAD）—— `diff <(git show HEAD:internal/runtime/memory/preinsert_recall_test.go | sort) <(sort internal/runtime/memory/preinsert_recall_test.go)` 只差两行：一句重复文案 + 一个空行，其余逐行一致。 顺带按「主张与落点」把本文件自查了一遍：每段注释都紧贴它描述的符号 （实测文档与函数之间没有空行：`awk '/^\/\// {doc=NR} /^func / {if (NR-doc!=1) print NR}'`）， 且文中的位置指代（「那条防线在下面的 …」「下方 cfg.TimeoutSec != 0 那条」） 在搬运后依然成立。	2026-10-13 23:21:25 +08:00
AskaEth	42a07cb454	fix(config): 单条入库审查的墙钟上限收敛到唯一真源（M16） ... 生产启动行仍是 timeout=20s —— M15 把 memory 包的 defaultReviewTimeout 抬到 90s 的修复**从未生效**：config 层的 env tag 自己带着 default:"20"， env 层永远产出非零值，于是 memory 侧「≤0 才回落默认」的归一化成了死代码。 修法（二选一中的「① 让 memory 侧成为唯一真源」）：去掉 config 侧 MEMORY_REVIEW_TIMEOUT_SEC 的字面默认值，未配置时读出 0 = 「没配」， 由 normalizeReviewConfig 单点落地 90s。 生效值： .env / env 没写这个键 ⇒ 90s（唯一真源） 写了正数 ⇒ 原样生效（不做任何「保底抬到 90」的加码） 写了 0 / 负数 ⇒ 90s（与项目其它旋钮同一口径：≤0 = 用默认） 新增测试（走真实组装路径，不绕过任何一层）： config.LoadMemoryReviewConfig → ReviewConfig.Timeout → NewPreInsertReviewer → normalizeReviewConfig → 生效值（= 启动行打印的 timeout=） 断言生效值严格大于「实测最坏召回链 57s + T1 子超时 8s」，并断言启动行打印它。 变异自证（修前红）：把 tag 的 default:"20" 加回去 ⇒ 报出 「组装后 timeout = 20s」+「生效值 20s != 唯一真源 1m30s」 原有 TestEmbeddingTimeoutFitsReviewBudget 拦不住这条，因为它比的是**本包常量**， 看不见 env 层；注释里已写明「比常量」与「比组装后生效值」的区别（防后人重蹈）。	2026-10-13 23:09:19 +08:00
AskaEth	f3fb097630	perf(embedding,memory): 批上限 4→8 削掉请求放大，审查预算 20s→90s 覆盖实测链长 ... 实测（2026-10-13，本机空闲，活库 cyrene/user 分区 201 条、均长 34.7 汉字）： - 一条入库审查召回链 = 51 个「4 条」请求 = 23.070 / 21.860 s；旧审查预算 20s 比链长还短 ⇒ 每一条候选满额的审查都超时，且超时后 **一行留痕都不写** （7 天里 92.1% 的审查 recall_mode 为空、2274 条超时降级的根因） - 同一条链改成「8 条」= 26 个请求 = 21.435 / 21.597 s：请求数减半，墙钟几乎不变 —— 链路耗时由「条数 × 每条成本」主导，批次只改请求数 - 「16 条」在**真实代码路径**上 3 次里 2 次让单请求越过 5s 单次超时（1.818 / 5.016 超时 / 5.001 超时）⇒ 批上限不越过 8；隔离测量里 12 条 0.996~1.017 s 仍在界内 改动： - embedding: perItemBudget 500ms→300ms（实测摊销 70~107ms/条的约 3 倍） ⇒ DefaultBatchLimit 由 (5s/2−100ms)/300ms = **8**，同一套推演、两维都成立 （条数 100ms+8×300ms=2.5s；字符 100ms+480×5ms=2.5s，均在超时的一半内） - embedding: 新增 maxSafeBatchLimit=12（实测外沿）+ 编译期断言（越界即 uint 溢出、 编译失败），与 tidy_config.go 那条同手法 - memory: defaultReviewTimeout 20s→**90s**（> 实测最坏链：空闲 21.6s⇒4.2 倍余量、 与整理链并发 56.7s + T1 8s ⇒ 1.4 倍；不再大的理由=单 worker 有界队列 256 的 最坏积压 256×90s≈6.4h、服务真挂死时第一片 5s 就降级用不到这条预算） 测试（不留过时断言）：budget_test.go 加「钉值 8/480 + 两维不等式 + ≤12 外沿 + 16 条必须仍判越界」四层；api_url_test.go 的 reviewBudgetRef 20s→90s； preinsert_recall_test.go 新增跨包断言「预算 > 实测最坏链 + defaultT1Timeout」。 变异自证：perItemBudget 回 500ms ⇒ 钉值断言红；reviewTimeout 回 20s ⇒ 跨包断言红； perItemBudget 150ms（⇒16）⇒ 编译失败（constant -4 overflows uint）。三者均已逐字还原。 遗留（如实登记，未修）：① 整理轮每轮重嵌整个分区（user 一轮仍 250 个请求）， 解法方向是复用已入库的 vec_items 或给整理轮一个 embedding 请求预算；② 链路对单点 慢分片没有韧性 —— 一个分片失败即整条 Embed 失败、丢掉其余分片的工作量，且实测 任何批次形状都会偶发 >5s 尖峰（4 条 7.139s / 8 条 9.711s，与批次无关），方向是 重试/分片级容错，调常量解决不了。	2026-10-13 21:59:31 +08:00
AskaEth	987cefdf28	fix(embedding): 端点地址规范化 + 独立短超时（治入库审查整条超时） ... 背景：入库前审查链路一直整条超时（日志每 ~20s 一条 WARN），异步那层 （含刚装好的 T1）从未成功跑过。 - 新增 endpoint.go：把「连接语义上不可靠」的回环别名规范化成 127.0.0.1 （localhost 大小写不敏感 / 0.0.0.0 / 空主机），只替换 Host，不碰 path / query / fragment / userinfo；显式 [::1] 与真实主机名逐字不动 - Embed 加独立短超时 DefaultRequestTimeout = 5s（远小于审查 20s 预算）： 卡住的调用快速失败并走既有「降级到词项余弦」的路径，把预算留给 T1 - .env.example 示例地址 localhost -> 127.0.0.1（未注释行键数 69 -> 69，无增删） - 跨包测试钉住 5s 严格小于审查总预算 诚实边界（子代理实测，推翻了主代理原先的 IPv6 根因推断）： - Go 客户端走 localhost 实测约 57ms、curl 约 0.2s ⇒「localhost -> ::1 等满 20s 预算」这条链不成立；更可能是单槽 llama.cpp 的吞吐/争用 （一批 64 条约 2.1~2.9s，审查 201 条约 8~10s，再叠 T1 8s 顶满预算） - 规范化在任何环境下都无害，5s 快速失败对这个真因对症；但真因 （容量/争用）需要另排切片，已记入工作小结	2026-10-07 16:22:28 +08:00