腾讯 ima 基于 ES 的 AI 知识库技术架构实践
腾讯ima基于ES的技术实践 主讲人：王志铭腾讯ima高级工程师 知识库文档检索 Overview章节一· Overview 01 02 章节二·文档内容搜索中的ES特性 知识库RAG检索 挑战与思考 04 03 章节三· RAG检索中的ES特性 章节四·挑战与思考 什么是AI知识库 传统知识库vs AI知识库 AI知识库=大模型+ RAG检索 用自然语言提问，从文档中召回相关片段并直接生成答案，替代人工翻找。 KInfra与ES的使用场景 一个ES引擎，同时承载三种检索能力 标题、标签等元数据全文检索 中文拼音+ ngram模糊匹配 不涉及向量，独立返回结果 面向传统关键词检索场景，与RAG链路解耦 整体架构 为什么选Elasticsearch 04灵活中文支持 02原生向量能力 03原生混合检索 自定义analyzer + multi-field，一字段多索引flexible Chinese support 06腾讯云ES团队 07成熟稳定 核心价值 05大规模友好 一套ES引擎同时承载向量检索+全文检索+混合检索能力All-in-One Engine 选型优势 技术能力 工程能力 中文分词弹性扩展运维成熟 大原因综合选型优势 套引擎承载多种检索 ES = AI知识库最佳底座 知识库文档检索02 知识库文档检索 拼音搜索 自定义analyzer将中文转拼音 ngram分析器单字匹配 输入知→命中知识库 输入zhishi/zs→命中知识 ▸ngram切分粒度细，支持前缀/子串匹配▸适合搜索补全、模糊关键词召回场景 ▸支持全拼与首字母缩写两种输入方式▸通过自定义analyzer灵活配置分词策略 高亮highlight关键词高亮 multi-field 多字段映射 对匹配关键词高亮，提升前端展示体验 标题同时映射多种类型，一套索引多搜索 搜索结果：构建知识库底层架构 ▸同一字段以多sub-field索引，互不干扰▸一次写入，多种检索方式并行可用▸灵活组合，覆盖精确匹配与模糊召回 ▸ES原生highlighter自动标记匹配片段▸支持自定义标签与样式，无缝接入前端▸提升用户搜索体验与可读性 知识库RAG检索 RAG检索流程总览+向量召回 RAG检索链路+ dense_vector + BBQ量化 💡RRF融合是ES原生能力，两路召回内部融合排序，无需自研融合逻辑 ▎向量召回：dense_vector + BBQ量化 向量量化后落盘存储内存占用进一步降到最低规模优先·支撑更大向量 BBQ量化+ HNSW图量化降内存、保召回内存优先·低延迟场景 存储文档Embedding向量支持KNN近邻检索，承载稠密向量召回 KNN with filter ✗传统方式：先全量召回→再过滤uid /知识库ID（效率低、浪费召回）✓KNN with filter：向量检索时直接叠加过滤uid /知识库ID无需先全量召回再过滤，召回效率与精度同步提升 按场景灵活选型，兼顾召回率与资源成本 08 / 13 千亿数据挑战概览 多租户场景特征+ ES存储模型 ES存储模型 多租户场景特征 数据严格隔离 Index索引逻辑单元：定义mapping / settings /别名 多租户SaaS：租户数据严格隔离、互不可见检索本质：在「指定租户/知识库」子数据集内完成，非全量扫描 数据分布极端 数据总量大、租户极多，平均数据量却不大多数租户数据量小，少量极端用户可达上千万 Shard分片物理单元：独立Lucene实例，存_source /倒排/向量 QPS特征总QPS高、租户多单租户QPS不高且反复激活 routing路由按租户/知识库ID落具体shard ▸引出三大挑战 数据膨胀多集群多索引路由 查询扇出与分片热点自定义路由+ routing_partition_size 内存与存储压力BBQ量化+行存裁剪 数据无限膨胀：横向与纵向双重扩展 横向扩展+纵向扩展 横向扩展·多集群多索引路由 纵向扩展·索引Alias + Rollover 挑战 挑战 单知识库数据量持续增长（如超过1亿条），单shard容量触及上限 知识库数量不断增加，单集群容量与写入瓶颈难以为继单集群上限成为横向扩展的硬约束 解决方案 多集群+多索引路由，按tenant_id分段归属突破单集群上限，按租户分段定位(cluster, index) 解决方案通过索引alias + rollover方式，滚动生成新索引 路由示例 租户ID（如t-12345）→业务路由系统（tenant_id分段）示例：t-12345 → Cluster-01 / index-03 工作原理 写入指向alias →阈值rollover → alias切换→旧索引继续查询 ▸弹性承载总结 横向扩展承载更多知识库 两者组合无限膨胀下的弹性承载 纵向扩展承载更大单库数据量 2 向量检索的内存与存储压力 01bbq_hnsw ·量化降低内存BBQ Quantization + HNSW 02bbq_disk ·跳出内存约束Disk-based Vector Index 存储优化与选型总结 ⚠原理BBQ量化+ HNSW图索引量化压缩向量占用内存中构建HNSW图 ⚠原理向量量化后直接落盘基于磁盘构建索引不再受限于内存容量支撑更大规模向量适用规模优先场景 ⚠存储优化 _source excludes向量字段检索不依赖原向量省约一半冗余存储与IO开销 ✓核心价值大幅降低内存占用同时保持召回率适用内存优先、低延迟 ✓选型总结 bbq_hnsw以量化换内存效率常驻内存、低延迟场景 ▸关键参数num_candidatesm / ef_construction / rescore_vector.oversample（3×） bits量化位数1/2/4/7 visit_percentage访问簇百分比 bbq_disk以磁盘实现规模突破 ▸本质 磁盘可承载 量化压缩 仍在内存构建HNSW图但量化后每向量占用大减以量化换内存效率 从内存受限变为规模突破 按需选型 租户分片路由与隔离检索 自定义路由·减少扇出与热点 挑战1广播扇出随shard线性增长 经验值Shard规划经验值 挑战2大租户集中落少数shard ▸解决方案1_routing自定义路由按知识库ID路由到目标shard只命中相关shard大幅减少查询扇出 ▸解决方案2routing_partition_size同知识库ID分散多shard均衡负载、消除热点→读写负载不再倾斜 ▸三条上限①单节点shard ≤ 1000②每GB JVM堆≤ 20 shard③单shard ≤ 30 GB→控规模、避热点 参数slice_field=tenant_id 机制按tenant_id shard内细分slice 检索最佳QPS提升58%+ bbq_disk Slice ·租户级隔离检索 全局IVF聚类（NO SLICE）vs按tenant_id slice聚类 按tenant_id slice聚类·每租户只扫自己的slice租户数据隔离，检索仅扫描目标slice，效率高 T H A N K S 欢 迎 交 流 与 探 讨 王 志 铭腾 讯 科 技i m a研 发 中 心