文 / 阿里云AI搜索产研团队
在做搜索技术架构咨询时，我们经常听到一句话："我也知道业务系统复杂，但不知道怎么简化架构部署?"
今天，我们想聊聊 "某知名互联网泛娱乐视觉平台 A"（以下简称 A 公司）的搜索架构演进故事。他们的云上迁移经历，是无数正在为"技术栈碎片化"与"AI搜索架构改造"头疼的企业的真实写照。
第一阶段：为了业务的"快"，他们建了三根烟囱
一年前，A 公司的技术架构负责人老李面临着极大的压力。随着原先的检索业务引入全量日志审计的运维管理，再到接入大模型 RAG（检索增强生成），他们的架构变成了典型的"拼凑型"：
通用搜索业务：素材中台、视频/表情包关键词检索，涉及大规模用户、话题及活动信息。跑在开源ES集群上。
日志检索业务：为了合规存储海量 Access Log，采购了独立的日志服务。App行为日志、服务端系统日志，用于性能监控与运营决策。为了省钱又把部分老日志导到了 对象存储里，查询极其不便。
向量检索业务：基于视觉特征的相似图片检索、基于用户画像的智能推荐（如相似滤镜、模板推荐）。为了做 RAG 和猜你喜欢，又不得不单独搭建了一套 开源Milvus。
老李的痛点非常具体：
"半夜烧钱"：A 公司的流量有明显的潮汐效应。每天晚上 8 点到 12 点是日志写入洪峰，但凌晨 2 点到早上 8 点流量极低。为了抗住那 4 小时的峰值，他们必须按最高水位购买日志资源。结果就是：每天有 16 个小时，昂贵的计算资源在空转。突发流量导致的扩容压力与存储成本不成正比。
"胶水代码"：在做 RAG 时，开发同学需要在代码里先查 Milvus 拿 ID，再回查 ES 拿文本。不仅代码难维护，一旦出现数据不一致（比如文章删了，向量还在），用户就会点进 404 页面，投诉率飙升。
"三根烟囱"，多种搜索能力隔离分开，开发与运维成本极高，难以支持复杂的跨模态检索。
"蜗行牛步"：全量同步耗时长，大数据量下的实时更新与索引重建效率低下。
第二阶段：做减法，拥抱 All in ES
在与阿里云AI搜索专家团队深聊后，A 公司决定进行一次彻底技术"断舍离"，将AI搜索所需的多种技术栈统一收敛到阿里云 Elasticsearch 上。
-
日志场景：把"固定资产"变成"电费单" A 公司首先改造的是最烧钱的日志系统。他们没有继续购买庞大的自建ES节点，而是接入了阿里云 ES 的 高性能写入托管服务Indexing Service 和 混合存储服务OpenStore。
变化前：为了抗峰值，常驻 20 台 8C32G 的机器。凌晨流量跌到谷底时，这 20 台机器依然在计费。
变化后：彻底 Serverless 化。晚高峰流量来了，云端自动扩容扛压；凌晨流量没了，计费几乎归零。存储方面，数据自动沉降到 OpenStore（对象存储介质），成本直接对其归档存储。
老李的反馈："以前是养车，不管开不开都得付折旧和保险；现在是打车，跑多少付多少。单这一项，日志账单降了 60%。"
-
向量场景：删掉胶水代码，回归原生 解决了日志，A 公司开始动刀向量搜索。他们利用阿里云 ES 内核级强化的混合向量引擎，替代了独立的向量库。
变化前：应用 -> 查向量库 -> 拿 ID -> 查 ES -> 应用层排序。延迟 200ms+。
变化后：应用 -> 阿里云 ES (混合检索 API) -> 返回结果。
由于阿里云 ES 全自研云原生引擎FalconSeek在内核层引入了 SIMD 指令集加速和 HNSW 算法优化，在千万级数据量下，性能完全满足 A 公司的需求。更重要的是，他们终于可以用一个 DSL 语句同时搞定"语义搜索 + 关键词匹配 + 边时间过滤边检索"。
老李的反馈："架构图上少了一个框，代码里少了几百行胶水逻辑，开发同学终于不用在两个库之间修数据一致性的 Bug 了。"
为什么选择 All in ES？因为"统一"本身就是生产力
A 公司的故事并非孤例。当他们将日志、搜索、向量收敛到阿里云 Elasticsearch 这一套技术栈上时，发生的不仅仅是成本的降低：
系统架构优化：
-
极致的计算资源弹性（Serverless）： 对于日志这种具有明显"峰谷效应"的数据，传统的预置机器模式注定是浪费。阿里云 ES 的 Indexing Service 让算力像水一样流动，"用时付费，不用免费"，这才是云原生该有的样子。
-
运维标准的统一： 现在，A 公司的运维团队只需要精通 ES 这一门手艺。无论是查业务慢查询，还是做日志分析，亦或是管理向量索引，都在同一个控制台，遵循同一套安全标准（RBAC/VPC），看同一套监控大盘。
-
数据价值的闭环： 日志数据进来，清洗后直接可以用于业务分析；业务数据进来，直接生成向量用于推荐。数据在同一个生态内流转，没有中间商赚差价。
日志检索增强：
在A公司中广泛使用的日志检索，采用阿里云Elasticsearch企业版以下方面进行全面优化。
极致写入优化 - Indexing service读写分离，综合写入成本降低60%
-
高性能：专业级写入优化，多自研特性加持(物理复制,定向路由等)
-
高稳定：多集群冗余备份，秒级切换
-
低成本：写入资源，存储大小及介质等优化
-
弹性扩展：写入资源由云端后台调配和管理，以应对流量波动
-
免运维：无须关注写入资源和写入压力, 极大降低集群运维成本
存算分离优化 - OpenStore混合存储架构，存储成本降低60%以上
-
采用存算分离架构，降低数据冗余存储
-
采用对象存储降低存储成本
-
多级缓存及并发查询保证查询性能
专业级查询优化:
- 针对日志场景的典型查询case进行深度优化，提高用户查询性能， 如bkd查询优化等
- 贴近用户业务，针对用户使用过程中的查询问题进行定制优化，如在支持A客户中遇到的cardinality开源缺陷导致的查询性能问题等。
向量索引调优：
向量索引在AI搜索场景中越来越重要，A公司为提高性能，降低整体成本，充分采用了阿里云ES的若干优化手段。成功的将成本降低一倍以上，查询性能提升数倍以上：
-
自研FalconSeek云原生索引应用 ：阿里云最新发布全自研云原生C++内核引擎, 对文本检索与向量检索性能提升，向量性能进一步提升40%以上。 使用FalconSeek的Filter-Knn特性，性能提升最多4倍。
-
执行Force Merge：存量数据定期执行Force Merge，性能提升5倍以上。
-
原文排除向量字段：在写入的source中排除向量字段，存储空间节约1倍以上。
-
混合搜索： 采用RRF（Reciprocal Rank Fusion） 算法或自定义线性权重，将向量相似度得分与BM25文本得分进行加权融合，以兼顾检索的精确性与泛化性。
成本效能对比与选型建议
根据A公司迁移阿里云的测算分析，企业在构建多场景AI搜索时，可重点关注以下成本指标：
| 维度 | 建议方案 | 价值产出 |
|---|---|---|
| 计算资源 | 自研FalconSeek引擎应用 选用计算型ecs.g8i或r8i系列 | 提升向量运算（HNSW等算法）的吞吐量 |
| 存储资源 | OpenStore存算分离架构 | 解决日志/冷数据存储高成本痛点 |
| 写入性能 | Indexing Service高写入服务， 开启物理复制（Physical Replication） | 降低高并发写入时的CPU占用 |
| 运维效率 | 统一公用集群与素材中台集群 | 减少20%以上的碎片化人力投入 |
总结：One Stack一站式搜索, 简单架构是最好的架构
回看 A 公司的搜索技术演进之路，其实就是一条从"做加法"到"做减法"的路。
对于架构师：你的系统拓扑图变清晰了，数据链路变短了，系统稳定性变强了。
对于运维：只要精通 ES 一门产品技术手艺，就能搞定全公司的核心数据检索全链路。
对于老板：TCO（总拥有成本）显著下降，同时获得了企业级的安全合规保障。
不要让复杂的工具链拖累你的业务创新的速度。
从今天开始，参考 A 公司的路径，重新审视你的架构。尝试阿里云 Elasticsearch企业版，体验"All in ES"带来的极简与高效。