4 Commits

Include renames

Author	SHA1	Message	Date
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	6c30ca540a	fix(memory): 冷启动放宽改为一次性 + 试算轮区分「没候选」与「向量不可用」 ... review round1 的 p1/p2 收口（commit 5967272 之后）。 p1：旧实现 `warmed` 只在 2xx 之后才翻 ⇒ 注释里写的「只在第一次成功响应之前」 实际是「服务坏着的全部时间」。reviewer 实测「接受连接但永不回包」时**每次**调用 都等满 30s（fail-fast 变 fail-slow）：审查 20s 预算被一次吃光、索引写入拖成 8×30s、开机探针阻塞 30s。 - `warmupLeft` 改为**一次性许可**（CompareAndSwap 取走即失效，成败都算花掉） ⇒ 挂死时只有第一个请求慢一次，此后一律 DefaultRequestTimeout。 - `warmupTimeout` 30s → 8s：与常态 5s 同一量级（≤2×），且严格小于审查总预算 20s（一次冷启动不许吃光整轮）；两条界都由 TestDefaultRequestTimeout 守住。 - 放宽被花掉且没成功时留一条 WARN（事后可复核「第一个请求」这个判据）。 - 更正两处自述：api.go 的「不会被 30s 拖住」与 budget.go 的不变式说明（批次形状 永远按稳态超时推导；冷启动只放宽第一个请求的截止时刻）。 - p2：删掉零调用者的 `WithRequestTimeout` —— 单次超时只允许改常量，批次上限与它 同源并由编译期/常量断言复核。 p2：试算轮在向量源不可用时 `RecallMode` 与「没有候选可比」同为空串。 - `recallLedger` 增 `unavailable` 计数 + `noteUnavailable()`（strictRecall 失败 那一笔记一笔）；试算汇总行新增 `recall_unavailable_partitions`，**成败都记**。 - 不扩 `recallMode` 取值集合：失败那一路不序列化 result（响应是 500 tidy_recall_unavailable），新取值只会出现在日志里却要动一次契约，不划算。 测试：三种失败形态 × 两次调用的耗时断言（连接被拒 / 500 / 永不回包）， 试算轮的「不可用」与「没候选」两态日志断言；两处变异自证（warmupTimeout 调回 30s ⇒ TestDefaultRequestTimeout 红；去掉 noteUnavailable ⇒ 试算汇总行退化成 recall_mode="" + recall_unavailable_partitions=0）。	2026-10-13 20:51:10 +08:00
AskaEth	59672720bd	fix(memory): embedding 批上限与超时同源 —— 不再「客户端先放弃、服务端继续算」 ... M9（EMBRECALL）。故障机制（M6 + 本次复测）：客户端 5s 单次超时先放弃，服务端仍在 算那一批 ⇒ 本机 llama.cpp 被自己顶住 ⇒ 后续每个请求（含写向量索引的单条请求） 排队到自己的超时 ⇒ 召回全线降级。 - embedding/budget.go（新）：把「一次请求的耗时上界 ≤ 单次超时的一半」写成不变式， 批上限（条数 4 / 字符 480）与 5s 超时由**同一个不等式**解出；实测依据与复跑命令 写进注释（空闲态摊销曲线 1→0.19s / 8→1.1s / 12→1.3s / 64→8.5s，约 50ms 固定 + 2.7~3.9ms/字符，n≥32 起有数倍放大 ⇒ 余量取一半）。 - embedding/api.go：Embed 按同一对上限**自己切片**（不变式与调用方无关）；冷启动 首次调用单独给 warmupTimeout，拿到第一个成功响应后立刻回常态超时。 - memory/tidy_config.go：tidyEmbedBatch = embedding.DefaultBatchLimit（同源）， 并加编译期断言 —— 调回 64 会直接编译失败（constant -60 overflows uint）。 - memory/tidy.go | tidy_recall.go | tidy_dryrun.go：recall_mode 改报**实际发生** 的来源（""=本轮没候选可比 / embedding / lexical / mixed），新增 recall_degraded_partitions；试算轮 RecallMode 同口径（M6 medium finding）。 - 测试：embedding 侧用「实测曲线 + 会睡够时间的假客户端」钉住两态 （批内 < 超时 ⇒ 不降级；旧配对 64 条 ⇒ 必然超时），并断言 abandoned == 0； memory 侧钉住降级/健康/没候选三态与试算轮的如实上报。 不改 preinsert*、不改 .env、不动判定规则与任何阈值。	2026-10-13 20:33:26 +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