treg搜索实验search experiment揭秘相关性裁判如何改进目录搜索【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址: https://gitcode.com/GitHub_Trending/treg/tregtreg 是面向 Agent 工具的 OpenRouter它的核心资产是一个可被 AI 智能体直接调用的目录搜索catalog search当你用自然语言描述一个任务时目录会返回真正能完成这件事的 API 端点。但纯关键词匹配看不懂语义——于是 treg 上线了一个搜索实验search experiment在放大的召回结果背后放一位相关性裁判relevance judge用用户的真实下一步行为来衡量它是否让搜索结果变好了。本文将完整拆解这套机制的设计思路与实现细节。为什么关键词搜索不够两类典型失败treg 的catalog_search本质是token 匹配详见 docs/context/architecture/catalog.md 中的 Search scoring 一节大部分词要命中且由稀有的词决定得分。它可复现、可解释但对语义是盲的。SearchMiss 日志暴露了两类失败失败类型例子结果词都在但都是参数值apple stock closing prices for last year苹果去年股价收盘价6 个稀有词里有 3 个是股票代码和日期区间目录里根本没有一无所获词撞上了但撞错行某些词恰好出现在不相关的端点上给出了错误的结果这两类都是语义问题靠调词表解决不了——所以才需要一位真正读得懂任务的裁判。三层架构宽召回、相关性裁判、实验编排搜索实验由三层组成依赖方向严格向内源码见 src/treg/application/search_experiment.py宽召回store.candidatessrc/treg/domain/catalog/store.py 只要命中至少一个必需词就召回候选最多取search_experiment_candidates默认 30条。之所以敢这么宽是因为没有裁判的答案任何一行都不会展示。相关性裁判infra/judge.pysrc/treg/infra/judge.py 底层是 TypeSafe 的 System One API代号 Jev。一次请求携带查询和全部候选作为state每个候选一个 Noul 问题返回每行的相关性概率。关键特性永不抛异常超时、非 200、格式错误都返回probsNone加原因调用方直接回退基线进程内缓存按模型, 查询, 候选 id缓存重复查询只付一次裁判成本并行打分30 个候选也是一次网络往返实测 1.2–1.5 秒。实验用例application/search_experiment.py给候选打裁判分、用与基线完全相同的收尾步骤证据重排、路由分组、截断到一页构建裁判页为调用方分配实验臂并向审计层递交一行SearchLog记录。不按概率排序而是分桶0.4 与 0.7 两条线一个反直觉的设计裁判页不是按概率从高到低排序而是分桶见 src/treg/domain/catalog/interleave.py 的bucketed函数概率search_judge_keep0.4的行直接丢弃概率≥search_judge_high0.7的行排在前一桶其余排后一桶桶内保持原有的词法顺序——词法上打平的行仍然精确打平证据重排的话语权不被裁判覆盖。也就是说裁判决定一行该不该上页、大致排哪而不推翻已有实测数据能决定的精细顺序。三种模式一个开关就是紧急制动整个实验由一个设置search_experiment控制它同时是紧急停止开关src/treg/config.py模式用户看到什么目的off默认原样上线的排序器什么都不跑shadow影子模式基线页两页都计算并记录测量页面差异率、裁判延迟与成本先让任何调用方都看不到变化interleave交错模式两页的合并版大部分调用方看合并页各留 10% 的 holdout 分别看纯基线页和纯裁判页读取绝对转化与延迟代价分臂按调用方bearer token 的加盐哈希分配保证同一个 Agent 的会话体验一致、重查可测量改search_experiment_salt即可重新分臂。若未配置裁判密钥任何模式都退化为off。抛硬币交错合并为什么更少的查询就能下结论把一半流量给 A、一半给 B 的传统 A/B 测试要跨过不同调用方之间的噪音才能比较两个排序器而交错interleaving把两个页面合并成同一页每一行都记得是谁放进去的——当调用方真的去call了某行就是谁得一分。每个查询都成了配对比较因此交错需要的查询量比 A/B 低一个数量级src/treg/domain/catalog/interleave.py 的team_draft。得分只发生在两页不一致处只有一页包含该行 → 该页得分两页都有但排名不同 → 排名更高的一页得分两页同排名都包含 → 平局谁也不得分。两页完全一样的查询贡献为零——这正是正确的裁判在那里什么都没改变。记录什么SearchLog 与只读报表 SQL每次 MCP 搜索模式非off时写入一行SearchLog数据库迁移 0041src/treg/alembic/versions/0041_searchlog.py查询、模式与臂、基线页、裁判页及概率、最终展示页、baseline_total0 表示词法召回一无所获即召回层样本、页面是否不同、裁判延迟/token/错误。写入走 fire-and-forget丢一行只损失一个样本。分析靠 scripts/search_experiment_report.sql只读 Postgres 脚本把searchlog按团队 邮箱、10 分钟内关联到后续callrecord读取四组数字每臂的量与健康度差异率、错误率、p50/p95 延迟每臂的转化率按基线为空/非空分层召回增益和排序增益是两个不同的主张交错得分与二项 z 检验重查率——2 分钟内二次搜索且中间没有调用说明这一页没干成它该干的事。同一位裁判也服务给人/catalog/find同一套机制还做成了面向人的按任务找工具GET /catalog/find?qsrc/treg/application/catalog_find.py支撑仪表盘的 Catalog 搜索框和公开/search页面。面向人时它做了几处差异化更宽召回 更松超时find_candidates取 60、find_timeout_s为 6 秒。裁判并行打分60 条与 30 条墙钟时间一样但能让词法排名靠后的行也见到裁判例如why is my blog losing google traffic 只有在 60 条时才找到 Search Console 表现报告流式响应两个 NDJSON 事件先出candidates再出judged页面即刻动起来动画掉等待感更严格的问题每个候选问题附带FIT_CRITERIA其false一侧包含任务只是提了一个产品/公司/平台名——否则裸搜 google 会给所有 Google 端点打出 0.6 的弱答案同一请求还追问一个问题task 是不是只是一个名字 裸名字概率 ≥find_name_min0.8直接返回该平台的端点货架给结论而非一页结果strong有强匹配/closest最接近不是答案/none一无所留/keyword裁判弃权展示未评判的关键词页/name纯名字限流匿名可用按 IP 和全站双窗口限流且限流会话在调用裁判之前就已提交关闭不占数据库连接。安全护栏裁判永远不能做什么延迟上限裁判最多给搜索增加typesafe_timeout_s2.5 秒且永远不能让搜索失败——裁判弃权即回退基线Agent 看不见概率面向 Agent 的响应不携带裁判概率暴露它会改变 Agent 的选择方式把实验变成另一个实验页面长度一致所有臂返回同样长的页面更多选项不能伪装成更好的选项不碰钱不触碰/call/、计费和 HTTP 搜索路由。小结用行为做标签的搜索实验treg 搜索实验最值得借鉴的是它的评估哲学没有人工标注数据时就用调用方的下一步行为当标签——展示页面上这个端点被 call 了没有比任何主观相关性打分都硬。宽召回 裁判分桶 交错配对比较 影子模式先行构成了一套既严谨又能随时紧急制动、且绝不伤害现有搜索可用性的渐进式改进流程。测试见 tests/test_search_experiment.py完整设计文档见 docs/context/architecture/search-experiment.md。【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址: https://gitcode.com/GitHub_Trending/treg/treg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 treg搜索实验（search experiment）揭秘：相关性裁判如何改进目录搜索
treg搜索实验search experiment揭秘相关性裁判如何改进目录搜索【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址: https://gitcode.com/GitHub_Trending/treg/tregtreg 是面向 Agent 工具的 OpenRouter它的核心资产是一个可被 AI 智能体直接调用的目录搜索catalog search当你用自然语言描述一个任务时目录会返回真正能完成这件事的 API 端点。但纯关键词匹配看不懂语义——于是 treg 上线了一个搜索实验search experiment在放大的召回结果背后放一位相关性裁判relevance judge用用户的真实下一步行为来衡量它是否让搜索结果变好了。本文将完整拆解这套机制的设计思路与实现细节。为什么关键词搜索不够两类典型失败treg 的catalog_search本质是token 匹配详见 docs/context/architecture/catalog.md 中的 Search scoring 一节大部分词要命中且由稀有的词决定得分。它可复现、可解释但对语义是盲的。SearchMiss 日志暴露了两类失败失败类型例子结果词都在但都是参数值apple stock closing prices for last year苹果去年股价收盘价6 个稀有词里有 3 个是股票代码和日期区间目录里根本没有一无所获词撞上了但撞错行某些词恰好出现在不相关的端点上给出了错误的结果这两类都是语义问题靠调词表解决不了——所以才需要一位真正读得懂任务的裁判。三层架构宽召回、相关性裁判、实验编排搜索实验由三层组成依赖方向严格向内源码见 src/treg/application/search_experiment.py宽召回store.candidatessrc/treg/domain/catalog/store.py 只要命中至少一个必需词就召回候选最多取search_experiment_candidates默认 30条。之所以敢这么宽是因为没有裁判的答案任何一行都不会展示。相关性裁判infra/judge.pysrc/treg/infra/judge.py 底层是 TypeSafe 的 System One API代号 Jev。一次请求携带查询和全部候选作为state每个候选一个 Noul 问题返回每行的相关性概率。关键特性永不抛异常超时、非 200、格式错误都返回probsNone加原因调用方直接回退基线进程内缓存按模型, 查询, 候选 id缓存重复查询只付一次裁判成本并行打分30 个候选也是一次网络往返实测 1.2–1.5 秒。实验用例application/search_experiment.py给候选打裁判分、用与基线完全相同的收尾步骤证据重排、路由分组、截断到一页构建裁判页为调用方分配实验臂并向审计层递交一行SearchLog记录。不按概率排序而是分桶0.4 与 0.7 两条线一个反直觉的设计裁判页不是按概率从高到低排序而是分桶见 src/treg/domain/catalog/interleave.py 的bucketed函数概率search_judge_keep0.4的行直接丢弃概率≥search_judge_high0.7的行排在前一桶其余排后一桶桶内保持原有的词法顺序——词法上打平的行仍然精确打平证据重排的话语权不被裁判覆盖。也就是说裁判决定一行该不该上页、大致排哪而不推翻已有实测数据能决定的精细顺序。三种模式一个开关就是紧急制动整个实验由一个设置search_experiment控制它同时是紧急停止开关src/treg/config.py模式用户看到什么目的off默认原样上线的排序器什么都不跑shadow影子模式基线页两页都计算并记录测量页面差异率、裁判延迟与成本先让任何调用方都看不到变化interleave交错模式两页的合并版大部分调用方看合并页各留 10% 的 holdout 分别看纯基线页和纯裁判页读取绝对转化与延迟代价分臂按调用方bearer token 的加盐哈希分配保证同一个 Agent 的会话体验一致、重查可测量改search_experiment_salt即可重新分臂。若未配置裁判密钥任何模式都退化为off。抛硬币交错合并为什么更少的查询就能下结论把一半流量给 A、一半给 B 的传统 A/B 测试要跨过不同调用方之间的噪音才能比较两个排序器而交错interleaving把两个页面合并成同一页每一行都记得是谁放进去的——当调用方真的去call了某行就是谁得一分。每个查询都成了配对比较因此交错需要的查询量比 A/B 低一个数量级src/treg/domain/catalog/interleave.py 的team_draft。得分只发生在两页不一致处只有一页包含该行 → 该页得分两页都有但排名不同 → 排名更高的一页得分两页同排名都包含 → 平局谁也不得分。两页完全一样的查询贡献为零——这正是正确的裁判在那里什么都没改变。记录什么SearchLog 与只读报表 SQL每次 MCP 搜索模式非off时写入一行SearchLog数据库迁移 0041src/treg/alembic/versions/0041_searchlog.py查询、模式与臂、基线页、裁判页及概率、最终展示页、baseline_total0 表示词法召回一无所获即召回层样本、页面是否不同、裁判延迟/token/错误。写入走 fire-and-forget丢一行只损失一个样本。分析靠 scripts/search_experiment_report.sql只读 Postgres 脚本把searchlog按团队 邮箱、10 分钟内关联到后续callrecord读取四组数字每臂的量与健康度差异率、错误率、p50/p95 延迟每臂的转化率按基线为空/非空分层召回增益和排序增益是两个不同的主张交错得分与二项 z 检验重查率——2 分钟内二次搜索且中间没有调用说明这一页没干成它该干的事。同一位裁判也服务给人/catalog/find同一套机制还做成了面向人的按任务找工具GET /catalog/find?qsrc/treg/application/catalog_find.py支撑仪表盘的 Catalog 搜索框和公开/search页面。面向人时它做了几处差异化更宽召回 更松超时find_candidates取 60、find_timeout_s为 6 秒。裁判并行打分60 条与 30 条墙钟时间一样但能让词法排名靠后的行也见到裁判例如why is my blog losing google traffic 只有在 60 条时才找到 Search Console 表现报告流式响应两个 NDJSON 事件先出candidates再出judged页面即刻动起来动画掉等待感更严格的问题每个候选问题附带FIT_CRITERIA其false一侧包含任务只是提了一个产品/公司/平台名——否则裸搜 google 会给所有 Google 端点打出 0.6 的弱答案同一请求还追问一个问题task 是不是只是一个名字 裸名字概率 ≥find_name_min0.8直接返回该平台的端点货架给结论而非一页结果strong有强匹配/closest最接近不是答案/none一无所留/keyword裁判弃权展示未评判的关键词页/name纯名字限流匿名可用按 IP 和全站双窗口限流且限流会话在调用裁判之前就已提交关闭不占数据库连接。安全护栏裁判永远不能做什么延迟上限裁判最多给搜索增加typesafe_timeout_s2.5 秒且永远不能让搜索失败——裁判弃权即回退基线Agent 看不见概率面向 Agent 的响应不携带裁判概率暴露它会改变 Agent 的选择方式把实验变成另一个实验页面长度一致所有臂返回同样长的页面更多选项不能伪装成更好的选项不碰钱不触碰/call/、计费和 HTTP 搜索路由。小结用行为做标签的搜索实验treg 搜索实验最值得借鉴的是它的评估哲学没有人工标注数据时就用调用方的下一步行为当标签——展示页面上这个端点被 call 了没有比任何主观相关性打分都硬。宽召回 裁判分桶 交错配对比较 影子模式先行构成了一套既严谨又能随时紧急制动、且绝不伤害现有搜索可用性的渐进式改进流程。测试见 tests/test_search_experiment.py完整设计文档见 docs/context/architecture/search-experiment.md。【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址: https://gitcode.com/GitHub_Trending/treg/treg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考