AskaEth/Cyrene_v2
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
742 Commits 7 Branches 0 Tags
91101dedfbdce97dddb10f485d60224e4b8af2e7
Commit Graph
8 Commits
Author SHA1 Message Date
AskaEth 66dda084cd fix(runtime): 上游错误体统一走 trace.UpstreamError，正文不进 error 
M41 的「LLM / embedding / 视觉 上游错误体」一族（M38 #5 #6 #7 #8 #9 #14）：
非 2xx 时把响应体截断后拼进 error，而 error 会被 chat run / loop step /
retrieve_fallback 打日志，等于把她的提问、记忆正文、要念的台词写进日志。

- model：openai/anthropic 两处 upstreamError 收口到 upstream.go 的
  providerUpstreamError；anthropic 流内 error 事件的 evt.Error.Message
  （原本无上限）整段丢弃，只保留令牌形状的 type
- embedding：readErrorBody 删除，改走 helper（input 就是她的记忆正文）
- vision：错误路径不再沿用取图的 50 MiB 上限，改为 4 KiB 有界读且不拼原文
- voice：classifyDashscopeStatus 只解 code/request_id，正文只留在内存里做
  分类判据；错误体读取同样改为 4 KiB 有界
- 测试：五个上游各一条「日志/error 里搜不到哨兵正文」用例，且能变异打红
 2026-10-26 13:44:32 +08:00
AskaEth bdf3f3edaf docs(embedding,memory): 复核 p2 的三处措辞改正（纯注释，零行为改动） 
review-m15 round1 判 p2-1items（fix-then-merge），三条都属「把证据能支撑什么写准」：

1. api.go 原写「最坏也只是这一片失败」与实现语义**相反** —— Embed 的实际语义是
   「任一片失败 ⇒ 整条调用失败、其余分片已算完的工作量一并丢弃」。改为与该包
   budget.go 里已经写对的那一句对齐，并点明调用方据此降级（记忆一条不丢、判定规则
   一字不改，变的是这一条审查的召回质量）。
2. 「尖峰与批次无关」是**过度断言**：原证据只支持「至少存在一个与批次无关的外部/
   争用分量」（4 条/片也实测到 7.139s）；越界的**频率**是否随批次上升，1/40 vs 2/40
   的样本不足以判定 ⇒ 改标为「归因未定」，并明说批上限取 8 的依据始终是硬证据
   （16 条/片实测越界 + 真实代码路径 3 次里 2 次越界），**不依赖**任何成因推断
   （原文与同文件「16 条越界故不取更大」的理由自相矛盾）。同时补上独立复核窗口的
   对照（review-m15：24 次单请求 0 尖峰）说明尖峰强依赖窗口负载。
3. budget.go 的不变式不再被读成延迟保证：明确定性为「**稳态、空闲机器的建模拟合**，
   用途是构造批形状」，并点名真正的兜底（90s 审查预算按整条链算 + 任一片失败即降级
   的路径 + 已登记的链路韧性遗留）；结论句由「8 条/片不越界」改为「**空闲实测下**不
   越界、负载下仍偶发越界」；perItemBudget 与 callBudgetShare 注释里「另一半／余量」
   的同口径措辞一并改正（加一句：这是建模余量，不是单请求一定不越界的保证）。

另：preinsert_config.go 里「设计稿那一行待同步」已过期 —— 塔同日已把 design/23 §15
同步为 Timeout=90s，改为「已按实测同步」。

验证：go build ./... / go vet ./... 干净；go test -count=1 ./... 全绿；
go test -race -count=1 ./internal/runtime/embedding/... ./internal/runtime/memory/...
全绿；diff 中无非注释行（纯文档改动）。
 2026-10-13 22:12:11 +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 95f517d61d refactor(embedding): 删掉生产不可达的冷启动 WARN 及其 logger 缝 
review round2 的 p2：`api.go` 那句「一次性冷启动放宽被花掉」的 WARN 在生产里
**不可能被人看见** —— 本包默认丢弃日志器，`WithLogger` 全树零调用者，生产走
`embedding.New(cfg)` 不带任何选项。而它的注释写着「这是唯一能审计一次性放宽的
地方」，与实际不符（本项目规则：注释不得说与实现不符的话）。

- 删该 WARN（失败并非静默：四个调用方本来就把错误原文写进各自的 WARN，
  路径见 review 召回 / 整理召回 / 向量索引写入 / 检索）。
- 连带删掉 `WithLogger` 与 `log` 字段：WARN 是 `e.log` 的唯一使用者，留着它会
  变成一个**空转的公开选项 + 又一次与实现不符的注释**（与上一轮删
  `WithRequestTimeout` 同一条理由：不留没人用且未测的缝）。
- `callTimeout` 不再返回 `relaxed`（它只为那条 WARN 存在）。
- `NewAPI` 的注释改为把「本包不记日志、失败沿错误返回」写成**实话**。

行为零变化（生产本就是丢弃日志器），只删死代码与不实注释。
 2026-10-13 21:01:54 +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): 端点地址规范化 + 独立短超时（治入库审查整条超时）
CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled
Details
CI / Frontend (tsc + vite build) (push) Has been cancelled
Details 
背景：入库前审查链路一直整条超时（日志每 ~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
Aska 51b2bdfba2 feat(embedding): 嵌入（n-gram 哈希向量 + 关键词 FTS + OpenAI 兼容 API 钩子 + Manager 选择） 2026-09-06 04:37:10 +08:00