3.17 搜索与信息检索

概述与动机

早晚会有人在搜索框中输入几个词，并期望你的系统能找到正确的结果。这个搜索框看似简单，背后却是计算机科学中最古老、最丰富的学科之一：信息检索，即从大型集合中依据不精确的请求找到相关项目的科学。搜索不是产品后期才附加的功能；它是一个拥有自身数据模型、自身失败模式、自身扩展方式、自身出错方式的系统性问题。当搜索做得好时，人们几乎不会注意到它，只会找到所需内容。当搜索做得差时，用户会离开，或者更糟，会认定他们想要的东西根本不存在。

本章将搜索视为一等架构议题。它与第 3.4 章的数据与存储决策紧密相关，因为搜索索引是一种为查询而优化的专用存储，不同于持有真相的系统记录（system of record）。它也依赖第 3.15 章的缓存与交付思想，因为搜索结果和建议对延迟敏感且可缓存。它现在还与第 6.3 章的生成式人工智能工作高度重叠，因为现代检索为大语言模型提供了其回答所需的上下文。

对大型团队而言，搜索是相关性、新鲜度与规模交汇的地方。一个拥有数千万条目的企业目录、一个需要向公众负责的政府记录门户、一个必须找出能解决工单的那一篇文章的支持知识库：每一种场景都要求搜索被度量、被调优、被以对待任何其他生产系统同等的严谨态度来运维。风险是实实在在的。一个税务机构在申报截止日期无法找到正确表单，或一个健康门户把相关指引淹没在噪声之中，都会以侵蚀公众对背后机构信任的方式辜负用户。

关键原则

将搜索索引视为一种衍生存储，与你的系统记录相分离。
相关性是可度量的质量，不是品味问题；用数据来判断它。
匹配人们实际输入的方式：拼写错误、简略、含糊不清。
结合词法检索与语义检索；单靠其中一种都无法覆盖所有查询。
为新鲜度而设计索引流水线，而不仅仅是为初始加载而设计。
用评判数据做离线评估，用真实行为做在线评估，两者都要用。
有意识地用分片和副本来扩展搜索，并像对待任何服务一样对其进行可观测性监控。

建议

从倒排索引与分析流水线入手

经典搜索的核心引擎是倒排索引：一个从每个词项映射到包含该词项的文档列表的映射，与列出文档所含词项的正排结构正好相反。搜索”invoice refund（发票退款）“时，引擎会在毫秒级别求出”invoice”的倒排列表与”refund”的倒排列表的交集，无论你持有多少百万份文档。正是这一数据结构让搜索显得瞬时响应，理解它也解释了搜索能做好和做不好的大部分事情。

索引的好坏取决于你喂给它的文本，而这正是分析器（analyzer）的职责。分析分阶段进行。首先，分词（tokenization）将文本流拆分为词项，一旦遇到标点、连字符，以及像中文这样不用空格分隔词语的语言，这项工作就比按空格切分难得多。接着，归一化会把字母转为小写、去除重音符号、合并变体形式。然后，词干提取（stemming）或其更精确的近亲词形还原（lemmatization）会把”running”、“ran”、“runs”归约到一个共同词根，这样查询其中一个就能匹配到其他形式。停用词处理、同义词扩展和语言检测完善了这条流水线。一条能省去许多麻烦的规则是：索引时分析与查询时分析必须一致，因为只有当两端以相同方式归一化某个词项时，该词项才能被找到。

在调优相关性之前先理解相关性排序

找到匹配文档只是简单的一半。把最好的结果排在最前面才是难的一半，这被称为排序（ranking）。传统的主力算法是 TF-IDF，即词频乘以逆文档频率：一个词项在文档中出现得越频繁（词频）、在整个集合中越罕见（逆文档频率），它的权重就越高，因此”photosynthesis（光合作用）“的权重会超过”the”。大多数现代引擎默认使用 Okapi BM25，这是对词频饱和处理（第十次出现相比第九次带来的增益很小）并对文档长度做归一化（长文档不会仅凭篇幅取胜）的改良算法。你不必推导这个公式，但应该知道存在这样一个可调参数，它有经过验证的默认值，改变它会改变哪些结果排在最前面。

用该领域的两个词来判断质量。准确率（precision）是返回结果中相关结果所占的比例；召回率是所有相关结果中被返回的比例。二者此消彼长。放宽查询以捕获每一个可能的匹配，准确率就会因噪声混入而下降；收紧查询以得到干净的结果集，召回率就会因遗漏好的匹配而下降。从拼写容错到同义词扩展，每一个相关性决策都是在这条曲线上押注你的用户希望落在哪个位置，而答案对法律档案（偏向召回率，不遗漏任何内容）和对购物网站（偏向准确率，展示优胜结果）是不同的。

投入查询理解

用户输入的方式与你文档的书写方式并不相同。他们会拼错、会缩写、会搜索你从未索引过的同义词，还会把三个意图塞进四个词里。查询理解就是弥合这一差距的层次，投入在这里的回报几乎超过其他任何地方。添加人工整理和挖掘得到的同义词，使”laptop（笔记本电脑）“能找到”notebook”，“heart attack（心脏病发作）“能找到”myocardial infarction（心肌梗死）“。通过编辑距离（edit distance）（两个字符串之间单字符改动的次数）添加拼写容错，使”reciept”仍能找到”receipt（收据）“。检测实体和意图，使”flights to Paris under \$500（500 美元以内飞往巴黎的航班）“能路由到正确的过滤条件，而不是被当作一堆词处理。

对最棘手的查询要有意识地区别处理。搜索一个稀有的精确字符串，比如订单号或法条引用，需要精确匹配而不需要任何巧妙的扩展。一个含糊的自然语言问题则需要相反的处理方式。将这两类查询分别路由，而不是对两者强加同一种行为。并且务必设计好零结果情形：当查询返回空结果时，放宽条件、提出替代建议，或回退到更宽泛的匹配，因为一个空白页面是失去用户最快的方式。

添加分面、自动完成和结构化筛选

搜索不只是一份排好序的列表。分面搜索（faceted search）让用户能按结构化属性缩小结果范围：品牌、价格区间、部门、日期、文档类型。分面把一个令人不知所措的结果集变成一场有引导的对话，同时也充当导航。它们依赖于数据的干净归类，这是搜索上游的数据质量投入，并且它们会与排序产生交互，因为过滤条件会改变排序器所看到的候选集。

自动完成和建议在查询提交之前就已经在塑造它。一个好的建议器会在用户输入时提出真实、高价值的查询，及早纠正拼写，并展现出热门或趋势中的意图。它对延迟极其敏感（每一次按键都是一次请求），并直接受益于第 3.15 章的缓存模式。建议还能把人们引导向你处理得好的查询，从而悄悄提升整体相关性。把建议器当作它自己的一个小索引，拥有自己的排序逻辑，依据查询日志而非文档内容来调优。

结合词法搜索与向量搜索

经典搜索匹配的是词。除非你事先告诉它，否则它无法识别”car”和”automobile”是同一个意思，遇到与你文档用词方式不同的问题表述时它也会碰壁。向量搜索通过将文本表示为嵌入（embedding）来解决这个问题（）嵌入是由机器学习模型生成的稠密数值向量，使得含义相近的内容在向量空间中彼此靠近。检索由此变成在该空间中的最近邻搜索，而由于精确最近邻在大规模场景下太慢，引擎会使用近似最近邻（ANN）算法，以牺牲一点准确性换取巨大的速度提升。这种语义搜索即使在查询与文档不共享任何词语的情况下，也能找到正确的文档。

没有哪种方法在所有场景下都占优。词法搜索擅长精确词项、名称、代码和稀有关键词；它透明且解释成本低。向量搜索擅长把握含义、转述和自然语言问题，但可能漏掉精确标识符，且更难调试。对正式系统而言，稳妥的默认选择是混合搜索（hybrid search）：同时运行两者并融合结果，常用的技术如倒数排序融合（reciprocal rank fusion），它能融合两个排好序的列表，而无需两者的分数具有可比性。混合搜索兼具关键词的准确率和语义的召回率，并且在任一方失效时也能优雅降级。

将搜索与检索增强生成相连接

搜索最快增长的消费者已不再是阅读结果列表的人，而是语言模型。检索增强生成（RAG）通过检索相关段落并将其放入模型上下文中，使生成式模型立足于你的数据，从而让它依据你的事实而非其训练记忆来作答。第 6.3 章所讨论的生成质量直接取决于检索质量：喂给模型错误的段落，它就会自信地合成出错误的答案。本章中的一切（将文本切分为段落、把它们排好序、融合词法与向量信号、保持索引新鲜）恰恰就是 RAG 的检索那一半。如果你的组织正在基于大语言模型构建产品，你的搜索系统就是其基础，而提升正确段落的召回率往往比更换模型更能帮助助手。

构建面向新鲜度的索引流水线

索引是一份副本，而副本会漂移。索引流水线是让搜索索引与系统记录保持同步的机制：读取源数据变化、运行分析与嵌入、写入索引，理想情况下是以流式方式而非夜间批处理完成。这是一个数据工程问题（第 7.2 章），第 3.3 章中关于顺序、重试和幂等性的那些考量同样适用，因为一次乱序更新可能会让一份已删除的文档”复活”。要明确设定你的新鲜度目标。价格或库存数量可能需要在几秒内可被搜索到；一份归档的政策文件可以滞后数小时。要支持为模式（schema）和分析器变更而进行的全量重新索引，并将其设计为可在不停机的情况下运行，通常做法是构建一个新索引，待其就绪后原子性地切换别名（alias）。

用评估而非意见来调优相关性

关于相关性的争论无法靠断言取胜，因此要用度量取代意见。离线阶段，构建一份评判列表：一组有代表性的查询，配以人工评定的结果相关性标注，并用诸如 NDCG（归一化折损累计增益）这样的指标为你的排序打分，该指标奖励把高相关性结果排在靠前位置，并对被埋没在靠后位置的结果打折扣。离线评估让你能在两种排序配置触达用户之前就进行比较。在线阶段，观察真实行为：点击率、被点击结果的位置、查询改写、零结果率和转化率。运行受控实验（第 7.4 章），使相关性变更被证明优于对照组，而不是凭直觉上线。两者都要用，因为离线指标快速但理想化，在线指标真实但缓慢且有噪声。成熟的闭环会从查询日志中挖掘数据来扩充评判列表，从而让评估随着学习不断改进。

用分片和副本扩展，并对一切进行可观测性监控

搜索沿两个维度扩展。分片（sharding）通过对文档分区，将一个索引拆分到多台机器上，因此一次查询会分发到每个分片，部分结果再合并；这使索引能增长到超过单台机器的容量，并分摊索引写入负载。副本会复制每个分片，使读取流量能分散到多个副本，且某个节点丢失也不会丢失数据；副本服务于查询吞吐量并提供韧性。分片越多，每次查询的分发成本就越高，因此应按你的数据规模来确定分片数，而不是套用一个整数。用第 9.2 章所述的可观测性来运维搜索：跟踪查询延迟的百分位数（长尾比平均值更重要）、索引延迟、缓存命中率、错误率，以及作为一等信号的相关性指标，如零结果率和点击位置。一个快但结果差的搜索系统是在悄无声息地失败，只有相关性遥测数据才能告诉你这一点。

权衡：优点与缺点

方式	优点	缺点
词法（BM25）搜索	精确词项、代码、名称；透明；成本低	若不调优则对同义词和转述视而不见
向量（语义）搜索	理解含义和问题；召回率强	漏掉精确 ID；计算成本高；更难调试
混合搜索	兼具关键词的准确率与语义的召回率	环节更多；融合需要调优和测试
激进的拼写和同义词扩展	召回率更高；对真实用户更宽容	准确率下降；若不加控制会产生噪声结果
实时索引	数秒内获得新鲜结果	比批处理成本和复杂度更高
更多分片	索引更大；可并行索引	每次查询的分发成本和协调成本更高
离线评估（评判列表）	快速、可重复、便于安全迭代	理想化；可能与真实用户行为不符
在线评估（点击指标、实验）	反映真实用户和意图	缓慢、有噪声，需要流量和实验纪律

反复出现的张力是准确率与召回率，它隐藏在每一个可调参数背后。放宽匹配、扩展同义词、倚重语义，你就能捕获更多内容，代价是噪声增加；收紧一切，你会更干净，但会遗漏内容。不存在普适的设定，只有针对特定集合和受众、经由度量发现的正确设定。第二重张力是新鲜度与成本：实时索引和混合检索都是用计算量和复杂度换取质量。解决这两重张力的方式相同：把每个决策与一个评估指标和一个用户结果挂钩，而不是凭直觉，这样你才能看清一次变更究竟带来了什么。

与团队讨论的问题

我们今天如何度量搜索相关性，如果它变差了我们会注意到吗？ 许多团队无法回答这个问题，这意味着他们的相关性就是默认设置产出的结果，对退化毫无察觉。带上你目前的信号：你有评判列表吗？你跟踪零结果率和点击位置吗？你能客观比较两种排序配置吗？“感觉搜索还不错”与”这是我们在一百条评分查询上的 NDCG，这是上月的趋势”之间的差距，就是猜测与工程之间的差距。接下来的行动是建立哪怕一份小型评判列表并对点击行为进行埋点，因为你无法调优你无法度量的东西，每一次盲目上线的相关性变更都是你无法辩护的变更。
词法检索和语义检索各自在哪些地方让我们失望，我们应该转向混合搜索吗？ 纯关键词搜索在被转述的问题和同义词上悄悄失效，而纯向量搜索在精确标识符和稀有词项上悄悄失效，而大多数团队只运行过其中一种。带上一批返回结果不佳的真实查询，并逐一分类失败原因：是缺少同义词、拼写错误、语义不匹配，还是缺少精确匹配？这些失败中的模式会告诉你混合搜索是否有帮助，以及应优先在哪里投入精力。如果你正在为语言模型提供数据，这一点就更加重要，因为检索失败会变成自信满满的错误答案，一旦上层有生成式模型，坏结果的代价就会急剧上升。
我们的新鲜度要求是什么，我们的索引流水线真的能满足它吗？ 新鲜度通常是被假定的而非被明确规定的，因此团队往往是在事故中才发现两者不匹配：一个已删除的条目反复出现，或价格更新滞后数小时。带上真实数字：从系统记录中的一次变更，到该变更可被搜索到，需要多长时间，这与你目录中不同部分实际需要的时间相比又如何？答案很可能因数据类型而异，把它明确说出来，就会倒逼出关于流式处理与批处理、顺序性、重新索引的流水线决策。一个用户能看出过时的索引会侵蚀对整个产品的信任，而一个你从未度量过的新鲜度目标，很可能就是一个你正在错过的目标。
我们是自建搜索引擎，还是购买托管的搜索或向量服务，日后改变主意的代价会是什么？ 自建还是购买的决定会在多年内决定你的成本结构和控制力的上限，而大型团队往往是因惯性而漂向某一个答案，而不是经过深思熟虑地做出决定。带上双方的真实数字：运行和扩展自有集群及嵌入流水线的运维成本，对比托管服务的按查询计费或订阅成本，以及每种方案所占用的、本可部署到别处的工程时间。隐藏变量是锁定：你的排序逻辑、分析逻辑和向量模式有多大的可移植性，如果定价或能力在你脚下发生变化，一次迁移实际需要多长时间？在企业和政府场景中，还要加上采购提前期和退出义务，因为一个无法开放其排序行为或无法导出你索引的服务，是你或许不被允许承担的一种依赖。
我们愿意在查询理解上投入多少，谁来评审失败的查询？ 用户会拼错、会缩写、会用你文档中从未出现过的措辞来提问，因此原始查询与好结果之间的差距，正是大部分用户感知到的搜索质量所在，然而这却很少是任何人明确的职责。带上你的零结果率、排名靠前的失败查询和改写查询，以及对你目前的同义词、拼写容错和意图处理能力的诚实评估。这里相互竞争的因素是准确率与召回率：你允许的每一个同义词和每一单位编辑距离，都会多捕获一些真实用户，也会多引入一些噪声，因此正确的投入水平是你能度量的那个水平，而不是听起来最慷慨的那个。对大型或公共组织而言，失败查询的长尾同时也是一张未被满足需求的地图，按固定节奏评审它，能把一项支持成本转变为一份路线图，尤其是在漏掉一份表格或福利会给公民带来实际后果的场景中。
谁作为一项有经费、持续性的职责来拥有相关性，评估闭环在上线后将如何存续？ 搜索永无完工之日：目录在变化，语言在漂移，上个季度的调优正在悄悄失效，因此一个没有明确负责人的系统会退化回默认设置所产出的结果。带上组织架构的真实情况：相关性是一个拥有时间和指标的指定团队来负责，还是落到最后接触索引的人头上？是否存在一份评判列表和一个新人也能接手的实验平台？这里的张力在于，相关性工作并不光鲜，且在搜索看起来运转良好的那一刻最容易被取消经费，而衰退恰恰正是从那一刻开始的。在企业和政府场景中，要把责任与具体义务挂钩：各市场的准确度、无障碍性、多语言覆盖，以及对零结果查询的评审，从而使责任可审计，不会在上线团队解散后随之蒸发。

行业视角

创业公司。 直接采用托管的搜索或向量服务，第一天就上线 BM25 默认设置；在有查询可供调优之前，不要自建集群。选定一个与营收或留存相关的搜索场景，从第一个版本起就对点击位置和零结果率进行埋点，让真实的查询日志而非路线图来告诉你何时该加入同义词或语义层。你为搜索构建的这套检索层，日后会成为你的检索增强生成后端，因此要把它置于一个精简的接口之后。

小型企业。 你几乎肯定没有相关性工程师，所以购买已嵌入在你现有平台中的搜索功能，比如你的电商主机、帮助台或内容管理系统，并把调优当作一项轻量的日常事务，而不是一个项目。把你有限的精力花在搜索所依赖的数据质量基础工作上：干净的产品属性用于分面、合理的标题，以及一份贴合客户实际用词的简短同义词表。每月查看零结果查询，因为它们是最廉价的信号，能让你无需工程师就能弥补差距。

企业。 问题在于跨众多团队、目录和语言的规模化相关性：需要一套共享的评判列表方法、按市场进行的评估，以及一个有经费支持的相关性职能，使每个团队不必各自从零调优 BM25。将索引流水线、新鲜度目标和门控排序变更的实验纪律标准化，并有意识地而非凭习惯地确定分片和副本的规模。在自建与购买之间做明确权衡，因为托管的向量服务能以牺牲一定控制力和潜在锁定为代价降低运维成本。

政府。 可发现性往往是一项法律义务，也是一个公平性问题：一个找不到正确表单的公民就无法行使其权利。偏向召回率和可解释的排序，使机构能够解释某个结果为何出现，添加能将大白话与官方名称桥接起来的同义词，并把无障碍性和多语言支持当作要求而非附加项。采购应权衡锁定风险，并要求任何托管服务开放其排序行为并支持数据可携带，零结果查询应作为未被满足需求的公开记录加以评审。

示例

创业公司。 一家十人的软件公司在其支持知识库中加入搜索功能，以便客户自助服务。他们从 BM25 默认设置起步，很快就遇到了天花板：用户用大白话提问，与文章不共享任何关键词。他们加入了向量嵌入，并用倒数排序融合将两者结合，转化分流效果立竿见影地提升。为了调优，他们挖掘自己的查询日志，为数百个”查询-文章”配对打标签，并每周跟踪点击位置。当他们后来加入产品内助手时，同一个检索层就成了 RAG 后端，使得搜索方面的投入获得了双重回报。

企业。 一家全球零售商在跨数十个市场和语言、数千万条商品上运行产品搜索。索引因体量而分片，并因吞吐量而设有副本，各语言专属的分析器为每个市场正确处理分词和词干提取。按品牌、价格和库存状态划分的分面导航，把庞大的结果集变成了有引导的浏览体验，自动完成则把购物者引导向转化率高的查询。相关性由一个有经费支持的团队负责，各市场都有评判列表，并持续进行在线实验；一项排序变更只有在转化率上超过对照组之后才会上线。一条实时索引流水线让价格和库存能在数秒内被搜索到，因为一个排在第一位却已售罄的商品，意味着一次流失的销售和一张支持工单。

政府。 一个国家级机构发布法规、表格和指引，公众必须能够找到这些内容，且往往存在法律义务，并在截止日期临近时面临高峰负载。团队偏向召回率和透明度：搜索福利的公民不能漏掉相关表格，机构必须能够解释某个结果为何出现，这促使他们采用可解释的词法排序，并谨慎地辅以能将人们所用的大白话与官方名称对应起来的同义词。无障碍性和多语言支持是要求，而非附加项。当政策文件变更时，索引会在别名之后不停机地重新构建，零结果查询会被记录并作为未被满足的公共需求信号加以评审。

商业论证：动机、投资回报率与总拥有成本

搜索直接位于价值路径之上。在电商领域，可观的营收份额流经搜索框，进行搜索的用户转化率高于仅浏览的用户，因此哪怕几个百分点的相关性提升也能转化为实实在在的收益。在支持和内部工具领域，更好的搜索能分流工单、缩短处理时长，并挽回知识工作者在寻找文档上损失的时间。在公共部门，有效的搜索是一个服务质量和公平性问题：找不到正确表格或指引的人，就无法行使权利或履行义务。这些结果都是可量化的，这正是为什么搜索理应获得有经费支持的评估，而非只求过得去的默认设置。

总拥有成本远超许可证或集群本身的费用。你要为索引及其副本的计算和存储付费，若采用语义方案还要为嵌入生成付费，为保持新鲜的索引流水线付费，而最重要的是，要为持续进行相关性调优和评估的人力工作付费。最后这项成本正是团队最容易低估、却最决定成败的成本，因为搜索永无完工之日：目录在变化，语言在漂移，昨天的调优正在失效。购买托管的搜索或向量服务能够降低运维成本、加快你的进度，代价是牺牲一定的控制力和潜在的锁定风险，这是一个需要根据你的规模和差异化程度权衡的经典自建与购买抉择。最有力的商业论证，会把一个具体的相关性指标与一个具体的业务结果绑定，为评估闭环提供经费，并把搜索当作一个被持续度量和改进的产品，而不是一个安装完就被遗忘的组件。

反模式与陷阱

分析不匹配： 索引时和查询时的分析器不一致，导致词项悄无声息地匹配失败，结果无声无息地消失。
凭意见判断相关性： 排序由声音最大的人说了算，没有评判列表，没有指标，也无法发现退化。
唯向量论： 完全用嵌入取代关键词搜索，随后在精确 ID、代码和稀有词项上失效。
忽视零结果： 任由空结果页面存在，而不是放宽条件、提出建议或回退，从而失去用户。
索引陈旧： 夜间批处理流水线所提供的价格、库存或删除状态，用户能看出是错误的。
重新索引停机： 原地重建而非在别名背后重建，每次模式变更都会导致搜索离线。
永远不调整的默认设置： 直接上线开箱即用的 BM25，且从不随集合和受众的演变而重新审视。
没有相关性遥测： 只监控延迟和错误，却不监控零结果率或点击位置，导致差结果悄无声息地失败。
过度扩展： 层层叠加同义词和拼写容错，直到准确率崩溃，每次查询都返回一堆噪声。

成熟度模型

第 1 级，启动（Initiate）： 搜索只是一个默认的数据库查询，或者一个使用出厂设置、未经调优的引擎，是有人终于提出要求时才被动搭建起来的。没有相关性度量，没有查询理解层，新鲜度取决于批处理任务碰巧产出什么。只有当用户抱怨时，才会注意到糟糕的结果，每次修复都是一次性的。
第 2 级，发展（Develop）： 已部署真正的搜索引擎，具备合理的分析、BM25 排序以及基本的分面和自动完成功能。存在一些同义词和拼写容错，团队会关注延迟和错误，并已开始记录零结果查询。各团队和各产品之间的实践不尽相同，相关性仍靠意见而非证据来调优。
第 3 级，标准化（Standardize）： 相关性实践在整个组织内有文档记录并被一致地应用。各团队使用共享的评判列表方法和离线 NDCG、在线点击指标来度量，在有助益的地方运行词法加向量的混合检索，将索引流水线维持在明确规定的新鲜度目标之内，并在别名背后实现不停机的重新索引。分片和副本规模经过有意识的设定，相关性指标与运维指标一同被监控。
第 4 级，管理（Manage）： 搜索被度量并对照基线加以控制。每个搜索场景都会跟踪 NDCG 趋势、零结果率、点击位置和改写率并与约定的基线比较，查询延迟百分位数和索引延迟设有服务水平目标。排序和分析方面的变更只有在受控实验中超过对照组的既定结果后才会上线，一次相关性退化会自动触发告警，按市场或按细分的仪表盘能在用户感受到之前让悄然的衰退变得可见。调整参数的决定基于数据做出，并有明确的回滚标准。
第 5 级，编排（Orchestrate）： 搜索改进是一个持续的、由实验驱动、贯穿整个组织的闭环。评判列表从挖掘出的查询日志中持续增长，查询理解随真实语言而不断适应，检索被作为下游生成式应用的共享基础而持续调优。整个系统在速度和相关性两方面都被端到端地观测，搜索实践随着目录、语言和模型生态的变化而自我调整。

讨论思路

你的搜索中有多大比例返回零结果或导致改写，这些查询揭示了哪些未被满足的需求？
如果你明天就用纯向量搜索取代关键词搜索，哪些查询会失效，你又将如何在用户之前发现这一点？
谁在你的组织中拥有相关性这项职责，他们有评判列表和指标，还是只有意见和轶事？
从你系统记录中的一次变更，到该变更可被搜索到，延迟有多长，这对每一种数据类型都是可接受的吗？
如果一个语言模型正在消费你的搜索结果，你的检索质量能否满足生成式回答所要求的更高标准？
你会如何向一位持怀疑态度的利益相关者为一次排序变更辩护：用一个实验结果，还是用一个故事？

关键要点

把搜索当作一等系统对待：一个拥有自身数据模型、流水线、扩展方式和失败模式的衍生索引，与你的系统记录相分离。
在尝试任何更花哨的手段之前，先掌握基础（倒排索引、一致的分析、BM25 排序、准确率与召回率）。
投资于查询理解（同义词、拼写容错、意图识别，以及一个真正的零结果应对方案），因为用户从不会按你文档的写法来输入。
默认采用融合词法与向量搜索的混合检索，并记住这同一个检索层正是检索增强生成的基础。
用度量取代意见：离线用评判列表和 NDCG，在线用点击指标和受控实验，并像监控任何生产信号一样监控相关性遥测数据。

参考文献与延伸阅读

Christopher D. Manning, Prabhakar Raghavan, and Hinrich Schütze, Introduction to Information Retrieval
Stephen E. Robertson and Hugo Zaragoza, The Probabilistic Relevance Framework: BM25 and Beyond
Ricardo Baeza-Yates and Berthier Ribeiro-Neto, Modern Information Retrieval: The Concepts and Technology behind Search
Doug Turnbull and John Berryman, Relevant Search: With Applications for Solr and Elasticsearch
Trey Grainger, Doug Turnbull, and Max Irwin, AI-Powered Search
Patrick Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”
Jeff Johnson, Matthijs Douze, and Hervé Jégou, “Billion-Scale Similarity Search with GPUs”
Kalervo Järvelin and Jaana Kekäläinen, “Cumulated Gain-Based Evaluation of IR Techniques”