把注入前的两跳合成一次 recall - #26
Merged
Merged
Conversation
evolver 2.0.39 起,/asset/fetch 不带 ids 时按 text 直接召回,选候选和 取实体成了同一次往返。原来的两跳要从等待预算里买第二跳,那点预算只够 两个候选;召回直接返回整份资产,于是 limit 变成"让 Hub 排多少条", 不再是"这一步等得起几条"。 has_strategy 这个搜索标记也不必再信——资产本身就在手里,直接读 strategy。 顺带删掉 undeliverable:它存在的唯一理由是按 id fetch 会返回 missing, 而召回分支的 missing 恒为空数组,onMissing 永远不会触发。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Hub 的 thinGeneClause(≤3 步的基因不返回)只被 assetSearchService 引用, 按 text 召回的那条路完全绕过它。实测确认:五个查询的 25 条召回里有三条 3 步基因,benchmark 里还出现过一条 2 步的。 上界是同一个判断的另一半。同一批样本里有一条 21 步的流水线胶囊,注入 5047 字符,而中位数是 605——它是生成的执行记录,不是可复用的方法。 12 条 prompt 的 benchmark,加界前后:命中仍是 12/12,注入字符最大值 5047 → 1844,总量 12231 → 9264,最慢一次 5599ms → 3351ms。覆盖没掉, 代价全砍在长尾上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
Hub 的 reuseResultRequestSchema 把 task_id 列为必填,插件从来不发, 于是每一次上报都被 400 挡在门外——本地账本一直有记录,Hub 侧一条没有。 活体验证:不带 400,带上 recorded:true,同 id 重发 duplicate_report。 task_id 不是聚合键,asset_id 才是;它是 Hub 用来和 asset、上报节点一起 哈希成事件 id 的幂等键。所以取「每会话每轮一个」,重发同一判决会被认出, 而 T1 纠正带自己的后缀,不会被当成那次重发而吞掉。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"They may be unpublished or not visible to this node" 是这一行自己猜的。 实测那条取不到的资产 status=promoted、节点完全可见、Hub 也确实交付了, 真正的原因是内容哈希与 id 不符被适配器拒收。这句猜测把排查方向引向了 权限和发布状态。 原因到不了这一层:适配器分得清 absent / identity_mismatch / revoked / unverified_not_allowed,但 fetchAssetById 把它们统统折叠成 null,proxy 只剩一个 id。所以如实说不知道,而不是换一个猜测。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
untilCount/untilRequest/untilInjected 是防死循环的看门狗,不是断言—— 条件一满足立刻返回,所以预算只需要熬过最慢的 runner。2 秒熬不过:纠正 那条用例在空载笔记本上就要 2.0 秒,dsh 0.1.5-rc.3 那格因此变红,而其他 矩阵格全绿。 断言一条没动,"第二次抱怨不再发第二条否定" 仍然靠固定 300ms 等待。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
prime原来是/asset/search选 id、再/asset/fetch把 id 换成实体。evolver-v2-private-dev#1239 合入并随 2.0.39 发布之后,/asset/fetch不带asset_ids就能按text直接召回,两跳合成一跳。行为变化
POST /asset/fetch { text, limit: 5 },拿回整份资产,注入其中分数最高且真的带 strategy 的那一条。has_strategy这个搜索标记不再使用——资产在手,直接读strategy。原来"没 strategy 的命中在花掉一次 fetch 之前就被筛掉"的逻辑,现在退化成在同一份响应里往下顺延,不产生额外往返。FETCH_LIMIT = 2去掉了。那个 2 是等待预算的产物(两个 id 1629ms、三个 5011ms),召回只有一次往返,limit 的含义变成"让 Hub 排多少条",取 5(与原SEARCH_LIMIT一致)。src/undeliverable.js及其测试。它存在的唯一理由是按 id fetch 会返回missing;召回分支里qualifyFetch([], recalled, [])的missing由空 ids 数组算出,恒为[],onMissing永远不会触发。留着就是死代码。(local cache, the Hub was unavailable)这个来源标记去掉了。召回分支带degraded: true时assets必为空,那条分支拿不到可注入的资产,标记不可达。已知取舍
召回直接打
hub.fetch(query),没有本地资产库兜底。Hub 不可达时原来还可能从本地缓存拿到一条降级结果,现在是注入不到东西。这是 proxy 侧召回实现的性质,插件侧改不了;如果要兜底,得在 proxy 的 recall 分支上加。assetPrimeWaitMs的默认值6000没动。它是按两跳(实测 4.8s–9.4s,中位 5.1s)定的,一跳应该远在预算内,但本机 Proxy 当前起不来(节点密钥丢失),没法用同样方法实测单跳成本,所以不凭猜调默认值,README 里写明了这一点。Validation
npm test:88 passed / 0 failed(改动前 89/2 failed 是因为两个用例仍按两跳打桩)。套件耗时从 14.1s 降到 3.2s。npm pack --dry-run确认undeliverable.js已不在包内。test/prime.test.js按单跳重写,保留了全部有意义的用例(排序、相似度闸门、无分数不过滤、已注入跳过、标题回退的四个中英文分支),新增"没 strategy 的资产在同一份响应里顺延"和"三种信封形状都能读"。🤖 Generated with Claude Code