电商搜索评测如何避免标签与裁判偏差

电商里的 AI，难点往往在模型之外：搜索分数涨了，可能只是噪声；Agent 会调接口，也可能改错库存；代码看着合理，却漏掉支付回调的幂等处理。作者把为客户反复开发的能力整理成四个 MIT 开源项目，分别处理搜索评测、店铺操作、领域知识和波斯语检索。

它们共同强调一件事：先把评判标准、操作边界和输入处理做好，再谈模型能做多少事。对做前端、全栈和 AI 应用的程序员，这些设计取舍比工具清单更值得看。

搜索分数涨了，为什么还不能直接上线

从关键词搜索换成向量检索，加上重排、查询改写或同义词，通常要做离线评测。作者举出的常见流程是：跑 50 条查询，对比 nDCG，分数上涨就发布。

问题出在评测依据可能已经落后。旧系统的人工相关性标注没有覆盖新系统召回的商品，这些商品会被当成未命中，新方案反而吃亏。另外，50 条查询上 +2% 的变化可能来自偶然；让一个 LLM 补标，也只是增加了一位裁判。

llm-search-eval 的做法是每次运行构建一个共享标注池：优先采用人工金标，只让 LLM 填补空缺，所有系统都在同一个池子上评分。它还支持多个裁判，通过 Cohen's kappa、Fleiss' kappa 和 Krippendorff's alpha 查看一致性，并检查各裁判与人工标注的吻合程度。

比较结果同时提供配对随机化检验和 bootstrap 置信区间，用来判断差异是否可能只是波动。成对 A/B 判断则交换顺序各跑一次，减轻展示位置带来的偏差。

评测工具的价值，是让团队知道一个涨分结果有多可信。

安装命令是 pip install llm-search-eval。它没有运行时依赖，支持任何 OpenAI-compatible endpoint，包括本地模型。estimate 命令能预估裁判调用次数、token 和费用，预算限制会阻止超支；GitHub Action 则能把报告写进 PR 评论，并在排名退化时让检查失败。

Agent 能改店铺之后，确认环节怎么设计

woocommerce-mcp 把关注点放在 Agent 犯错之后的后果。MCP（Model Context Protocol）负责连接工具，但线上店铺还需要明确的写入规则。

它默认只读，允许写入后，每个写工具先返回准确的 REST 请求预览，再次调用并传入 confirm: true 才执行。所有写入尝试，包括被拒绝的操作，都会进入审计日志；客户数据可以脱敏，工具可以按名称模式放行或禁用，例如隐藏 delete_*。

下面的命令用于启动服务：

npx -y @sadrmanesh/woocommerce-mcp

要注意，启动命令本身没有表达写权限，实际修改还受前面的授权与确认流程约束。

项目覆盖 47 个工具，包括商品搜索、订单与物流追踪、退款、批量调价和库存变更、优惠券、定时促销、客户分群、运费税费、webhooks 和销售分析。它支持 stdio 或 streamable HTTP，通过 bearer tokens 或 OAuth 2.0 认证，并发布到 npm、GHCR、Docker Hub 和官方 MCP Registry。

作者说，预览和确认会多花一次调用，却是店主最先询问的功能。这里的启发是：在业务操作中，多一步交互可以是产品价值。但原文没有说清楚，谁负责检查预览，以及确认前后状态变化时如何处理。

让 Agent 懂电商，不能只教它接口怎么写

作者观察到，编码 Agent 容易写出看似可信、却漏掉业务约束的代码：webhook 没有幂等处理，退款金额的货币单位不对，多仓库存发生超卖，商品页不满足无障碍要求。

commerce-agent-skills 把这些知识整理成 29 个 Markdown skills。每份包含规则、参考说明、常见陷阱、验证清单和评测样例，覆盖 Stripe、伊朗支付网关、退货退款、多仓库存、B2B 定价、商品目录迁移、WCAG 2.2、Core Web Vitals、WooCommerce、Shopify 和 MCP 店铺工具。

初始化命令如下：

npx @sadrmanesh/commerce-agent-skills init

要注意生成位置 .agents/skills/：它们是普通文件，任何能读取文件的 Agent 都可以使用。项目还提供小型评分器，用固定样例检查回答，让 skill 修改有一个可比较的依据；这些内容也发布成了 Hugging Face dataset。

这种方式把经验变成了可维护的项目材料。不过，原文没有给出使用前后的缺陷率或完成率，不能据此认定装上 skills 就能减少多少错误。

波斯语检索的提升，为什么先从字符处理开始

persian-rag 处理的是容易被忽略的输入问题。波斯语和阿拉伯语的 Yeh、Kaf 看起来相同，码点却不同；半空格可能出现或消失，一份文档会混用三套数字，PDF 还可能倒序存储文字，同一个词也可能有多种合法拼写。

这些问题会让表面相似的文本无法匹配，不能指望换个模型自动解决。

项目先处理这些语言差异，再提供文档加载、切块、BM25 与稠密检索的排名融合、拼写变体查询改写、重排、聊天记忆和评测。回答引用能定位到原文片段，另外提供 FastAPI 服务和 Docker 镜像。核心安装是无依赖的纯 Python，命令为 pip install persian-rag。

在项目附带的小型基准里，改写器把拼写错误查询的 BM25 Hit@1 从 0.58 提高到 0.83，即正确结果排在第一位的比例提高了。作者明确说样本很小，只把它当回归测试，不当作普遍效果声明。

我的判断

四个项目最有参考价值的地方，是把容易含糊处理的环节做成显式机制：统一评测依据、写入前预览、领域规则落盘、语言差异预处理。相比单纯更换模型，它们更容易检查，也更容易持续维护。

但机制存在，不代表问题已经解决。多个 LLM 裁判仍可能共享偏差；第二次调用确认，也不能证明有人认真检查过请求；Markdown 规则是否有效，还取决于 Agent 是否读取并遵守。

目前原文唯一给出的效果对比，是 persian-rag 小基准上的 0.58 到 0.83。其他收益主要是作者的项目经验，没有对照数据。四个项目都有文档、逐次变更 CI、标签发布自动化、GitLab 镜像，并在 README 写明局限，这些值得借鉴，但不能替代业务验证。

能拿来做什么

• 修改电商搜索前，先检查人工标注是否覆盖新召回的商品，再结合置信区间判断涨分，避免只盯着单次 nDCG。
• 给店铺 Agent 开放退款、调价和库存能力时，把请求预览、显式确认、审计日志和工具禁用做成可检查的流程。
• 在 AI 编程项目中，把支付幂等、货币单位、多仓库存和无障碍要求写入 .agents/skills/，配上固定验证样例，再观察修改是否有效。
• 做多语言 RAG 时，先检查码点、数字、空格和 PDF 文本顺序；保留一套已知失败样本，作为每次修改后的回归测试。