1. 企业搜索平台需求分析与目标定义
企业搜索平台建设最容易失败的地方，不是技术选型，而是需求没有收敛。很多团队一上来就讨论 Elasticsearch 集群规模、分片数量、向量检索插件，结果上线后发现：业务方真正要的是"能按合同编号精确找到扫描件"，而平台却把精力花在了模糊语义排序上。因此，本章的核心任务是把模糊的业务诉求，转化为可度量、可验收、可演进的平台目标。
一、业务场景调研：从"谁在搜"到"搜什么、怎么用"
调研的第一步不是问"你们想要什么功能"，而是还原真实的搜索行为。建议按"角色—场景—查询—结果消费"四层展开。以一家制造企业为例，典型角色包括：研发工程师查历史设计文档、售后工程师查故障处理记录、采购人员查供应商资质、法务查合同条款。每个角色的查询特征差异极大：研发常用型号、图号等强标识符；售后常用故障现象等自然语言描述；采购关注供应商名称与资质有效期；法务则需要按条款内容做全文检索。
调研时应记录每类场景的查询样本，而不是只记录功能名称。例如售后场景的真实查询可能是"X200 设备 开机 无显示 报警 E03"，其中包含型号、现象、错误码三类信息。这些样本将直接决定后续的分词策略、字段权重和过滤条件设计。建议每类角色收集 30～50 条真实查询，形成查询样本集，作为后续相关性评测的基线数据。
二、搜索质量指标：把"搜得准"变成可验收的数字
搜索质量不能停留在"感觉还行"。业界常用的一组指标包括：
- 召回率（Recall@K）：前 K 条结果中包含相关文档的比例，反映"该找到的有没有找到"。
- 准确率（Precision@K）：前 K 条结果中相关文档的占比，反映"找到的是不是都相关"。
- MRR（平均倒数排名）：第一条相关结果排名的倒数的均值，反映"相关结果排得够不够靠前"。
- NDCG@K：考虑分级相关性的排序质量指标，适合有"高度相关/部分相关"区分的场景。
- 零结果率：返回空结果的查询占比，是体验最直接的负向指标。
- 首条点击率与无点击率：来自真实用户行为，反映结果是否被认可。
指标选择要与场景匹配。精确查找类场景（如按合同编号）应重点看 Top-1 准确率和零结果率；探索类场景（如技术调研）则更关注 Recall@20 和 NDCG@10。建议为平台设定分层目标，例如：精确查找 Top-1 准确率 ≥ 95%，自然语言查询 NDCG@10 ≥ 0.75，整体零结果率 ≤ 5%。这些数字是示例性目标，实际取值需结合业务容忍度和历史基线确定。
三、非功能需求：决定平台能否长期稳定运行
非功能需求往往比功能需求更能决定架构走向。需要明确的关键项包括：
| 维度 | 典型要求（示例） | 对架构的影响 |
|---|---|---|
| 查询延迟 | P95 < 300ms，P99 < 800ms | 决定分片数、副本数、缓存策略 |
| 数据规模 | 文档 2 亿，日增 200 万，索引 1.5TB | 决定集群节点数与存储选型 |
| 写入时效 | 业务数据 5 分钟内可搜 | 决定同步方式（CDC/批量） |
| 可用性 | 99.9%，单节点故障不中断 | 决定副本与跨可用区部署 |
| 权限 | 按部门/项目隔离，字段级脱敏 | 决定文档级安全与查询过滤 |
| 可观测 | 慢查询、零结果、集群健康可追踪 | 决定监控与日志体系 |
其中权限与数据隔离最容易被低估。企业搜索往往涉及合同、人事、财务等敏感数据，必须在查询阶段就完成过滤，而不是靠前端隐藏。这要求文档在入库时携带权限标签，查询时由平台统一注入过滤条件。
四、平台边界与演进路线
平台边界要回答三个问题：谁负责数据接入、谁负责搜索体验、谁负责业务语义。建议平台负责统一的索引管理、查询解析、权限过滤、监控告警；业务方负责定义字段含义、提供查询样本、参与相关性评测。边界不清会导致平台变成"什么都做但什么都做不好"的泥潭。
演进路线建议分三阶段：第一阶段聚焦"能搜到"，打通核心数据源，建立基础检索与权限；第二阶段聚焦"搜得准"，引入字段权重、同义词、排序调优与评测闭环；第三阶段聚焦"搜得智能"，在评测体系稳定后，再引入向量检索、语义召回与个性化排序。切忌在第一阶段就堆叠高级能力，否则缺乏评测基线，无法判断效果是否真的提升。
五、可直接使用的需求调研清单
为便于落地，下面给出一份需求调研与目标定义清单，可直接用于访谈记录和评审。字段可根据企业实际情况增删。
【场景调研记录表】
场景名称：售后故障查询
使用角色：售后工程师
典型查询：X200 开机无显示 报警E03
查询类型：混合（型号精确 + 现象自然语言）
期望结果：故障处理手册、历史工单、备件清单
结果消费：阅读后按步骤操作
优先级：P0
【质量目标表】
精确查找 Top-1 准确率：≥ 95%
自然语言查询 NDCG@10：≥ 0.75
整体零结果率：≤ 5%
P95 查询延迟：≤ 300ms
【非功能约束表】
文档规模：2 亿条
日增文档：200 万条
写入时效：≤ 5 分钟
可用性：99.9%
权限：部门级隔离 + 合同金额字段脱敏
【边界与演进】
平台负责：索引、查询解析、权限、监控
业务负责：字段语义、查询样本、评测
阶段一目标：核心数据源可搜、权限生效
阶段二目标：评测基线建立、排序调优
阶段三目标：语义召回、个性化排序总结来说，本章的目标定义工作可以概括为：用真实查询样本锚定业务场景，用分层指标把"搜得准"变成可验收的数字，用非功能需求约束架构选型，用清晰的边界划分避免平台与业务互相推诿，最后用三阶段演进路线保证平台在可控节奏下持续提升。这五项工作完成后，后续的索引设计、查询实现和评测体系才有稳定的依据。