离线评估使用真实数据集,在受控条件下提供关于算法性能的有价值的认识。然而,这些离线指标,例如召回率和精确率,并不总是能完全预测搜索系统在真实用户及其多样化、通常不可预测的查询下的表现。用户交互模式、对相关性的主观判断以及系统延迟对用户体验的影响,都难以在线下获取。正因如此,A/B 测试成为了在实时生产环境中验证和对比搜索算法及配置的不可或缺的手段。A/B 测试,也称为分流测试或在线实验,它允许您通过将用户或查询随机分配到不同组并测量他们的交互,来对比搜索系统的两个或多个版本(变体)。通常,您会将提议的变更(变体 B)与当前的生产系统(对照组 A)进行对比。搜索 A/B 实验设计进行有效的搜索 A/B 测试需要周密的设计:定义假设和目标: 从一个明确的假设开始。例如:“对混合搜索实施倒数排序融合(RRF)(变体 B)将提高前 3 个搜索结果的点击率(CTR),与当前仅使用 HNSW 的搜索(对照组 A)相比,且不会大幅增加平均查询延迟。”目标通常与提高用户活跃度、相关性或业务成果相关联。选择指标: 选择直接反映您目标和假设的指标。常用指标包括:相关性/活跃度指标: 点击率 (CTR),特别是位置加权点击率,转化率(如适用),零结果率,查询重构率,会话成功率。性能指标: 平均查询延迟,95/99 百分位延迟,索引吞吐量(如果测试索引变更),CPU/内存利用率。防护性指标: 即使不是主要目标,您也希望确保不会明显下降的指标(例如,在优化 CTR 的同时,确保延迟不超过某个阈值)。确定分流单位: 决定如何分流。常用方法包括:基于用户: 在实验期间将用户(基于用户 ID 或 cookie)持续分配给对照组或变体组。这提供了一致的体验,但可能受用户群组影响。基于请求: 随机分配每个传入的搜索查询给一个组。这平滑了用户差异,但如果用户在会话中发出多个查询,可能导致不一致的用户体验。基于会话: 将用户的整个会话分配给一个组。这是基于用户和基于请求分流之间的一种折中方案。 选择取决于所测试变更的性质以及用户会话内的潜在交互。对分流单位进行哈希处理(例如,用户 ID + 实验 ID)是确保随机分配的标准方法。分配流量: 决定暴露给实验的流量百分比(例如,90% 对照组,10% 变体组,或 50%/50%)。对于风险较高的变更,可从较小的分配开始,如果初步结果有希望,再逐步增加。确保分配提供了足够的统计效力,以便在合理的时间范围内检测到有意义的差异。实施框架为搜索设置 A/B 测试框架通常包括:实验平台/基础设施: 这可以是一个专用的第三方 A/B 测试平台,也可以是内部系统。它需要处理流量分流、分配、配置管理(例如,告知搜索服务使用哪些索引参数或融合策略)和结果追踪。服务修改: 您的搜索服务需要能够根据分配的实验组以不同模式运行。这通常涉及功能标志或动态配置加载。例如,服务可能会收到一个标志,指示是仅使用向量搜索还是混合方法。日志记录和监控: 日志记录非常重要。对于每个查询,您必须记录它属于哪个实验组(对照组或变体组)、显示的结果、用户交互(点击、加入购物车等)以及性能指标(延迟)。这些数据是进行分析的根本。digraph G { rankdir=LR; node [shape=box, style=rounded, fontname="Arial", fontsize=10, margin=0.2]; edge [fontname="Arial", fontsize=9]; UserQuery [label="用户查询"]; Router [label="A/B 测试路由器\n(分流)"]; ControlService [label="搜索服务\n(对照配置)", style="filled", fillcolor="#a5d8ff"]; VariantService [label="搜索服务\n(变体配置)", style="filled", fillcolor="#b2f2bb"]; ResultsA [label="结果 A"]; ResultsB [label="结果 B"]; Logging [label="指标记录"]; UserQuery -> Router; Router -> ControlService [label="A 组 (例如,90%)"]; Router -> VariantService [label="B 组 (例如,10%)"]; ControlService -> ResultsA; VariantService -> ResultsB; ResultsA -> Logging; ResultsB -> Logging; ControlService -> Logging [style=dashed]; VariantService -> Logging [style=dashed]; }搜索 A/B 测试中流量分流的简化视图。路由器将查询分配给对照或变体配置,并且交互和性能被记录下来以供分析。分析 A/B 测试结果一旦实验运行足够长时间以收集到足够数据(由功效分析决定),您需要对结果进行统计分析:计算指标: 汇总记录的数据以计算对照组和变体组所选的指标。统计显著性检验: 使用适当的统计检验来判断观察到的组间差异是否具有统计显著性,或者是否可能是随机机会造成的。对于比例(CTR,转化率):卡方检验或比例 Z 检验。对于均值(延迟,会话时长):T 检验(检查正态性和方差齐性等假设)。如果假设不成立,可能需要使用非参数检验,如 Mann-Whitney U 检验。置信区间: 计算组间差异的置信区间。95% 置信区间告诉您真实差异可能所在的范围。如果该区间不包含零,则结果通常在 p < 0.05 水平上被认为是统计显著的。分群分析: 分析不同用户分群(例如,新用户与回访用户,移动端与桌面端,不同地区)的结果,因为变更的影响可能因分群而异。决策: 根据统计显著性、置信区间和实践意义(变更是否足够重要?),决定是将变体发布给 100% 的流量、弃用它,还是进一步迭代。{"layout": {"title": {"text": "A/B 测试:CTR 随时间的变化对比"}, "xaxis": {"title": {"text": "天"}}, "yaxis": {"title": {"text": "点击率 (CTR)"}}, "legend": {"title": {"text": "组"}}, "font": {"family": "Arial", "size": 12}, "margin": {"l": 50, "r": 20, "t": 40, "b": 40}}, "data": [{"type": "scatter", "mode": "lines+markers", "name": "对照组 (HNSW)", "x": [1, 2, 3, 4, 5, 6, 7], "y": [0.15, 0.155, 0.148, 0.152, 0.153, 0.149, 0.151], "line": {"color": "#339af0"}}, {"type": "scatter", "mode": "lines+markers", "name": "变体组 (混合+RRF)", "x": [1, 2, 3, 4, 5, 6, 7], "y": [0.16, 0.168, 0.165, 0.17, 0.172, 0.169, 0.171], "line": {"color": "#51cf66"}}]}A/B 测试期间对照组和变体组的每日 CTR。统计分析将判断变体组中观察到的提升是否显著。搜索 A/B 测试中的挑战位置偏见: 用户本身更常点击位置靠前的结果。如果您的变体提高了相关性并在较低位置显示更好的文档,即使用户满意度提高,简单的 CTR 也可能下降。请考虑位置感知指标或分析特定排名的点击量。多重变更: 同时测试索引参数(如 HNSW 的 efConstruction 或 efSearch)、量化方法或融合算法的变更,会使影响归因变得困难。在可能的情况下,一次测试一个重要的变更。长尾查询: 由于量少,对稀有查询实现统计显著性很困难。您可能需要更长的运行时间,或将评估侧重于汇总指标或更频繁的查询类型。延迟与相关性权衡: 通常,提高相关性(例如,使用更复杂的模型或更大的 efSearch 值)会增加延迟。请定义可接受的延迟阈值,并在必要时使用多目标优化框架。新奇效应: 用户最初的交互可能与新系统有所不同,仅仅因为它不同。请长期监控指标,查看效果在初始阶段后是否持续。A/B 测试提供关于变更如何影响真实用户的真实情况。虽然离线评估有助于筛选出有潜力的候选并有效调整参数,但在线实验是在将重大变更部署到向量搜索或混合搜索系统之前的决定性步骤,它确保了离线测量的改进能转化为生产环境中的实际收益。