巴别鸟智巢AI的RAG+Deep Search 工程实现：向量入库与深度搜索的拆解

原创于 2026-08-20 04:36:57 发布 · 115 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

最近在选型企业知识库方案，顺手研究了下巴别鸟智巢AI的技术实现。官方宣传页上写的是"RAG+Deep Search"，听着很唬人，但工程层面到底怎么落地的，我拆开看了看，给同样在做技术选型的朋友一个参考。

一、先说架构：三层分离

巴别鸟智巢AI的整体架构可以拆成三层：

接入层：用户请求先到业务网关，网关负责权限校验、请求路由和流量控制。这一层用 Nginx 做七层负载均衡，配合 Lua 脚本实现令牌桶限流。

推理层：包含 Embedding 服务、Deep Search 推理服务和 Permission Filter 服务。Embedding 服务负责把文件切片向量化；Deep Search 服务负责召回和重排；Permission Filter 做行级权限过滤。

存储层：向量数据库用 Milvus（分布式版本），元数据存在 PostgreSQL，全文检索用 Elasticsearch 7.x，对象存储用 MinIO。

整体是典型的云原生架构，各层独立扩缩容，私用化部署时也可以拆开按需分配机器。

二、向量入库：自动化的那一套

2.1 文件如何变成向量

巴别鸟的入库流程有几个关键步骤：文件先进入对象存储（MinIO），然后根据文件类型走不同的解析链路——文本文件直接读，Office/PDF 用 LibreOffice 转文本，CAD 图纸走 ODA SDK 解析图层信息。解析完成后按语义段落切成 Chunk，Chunk 大小默认 512 tokens，重叠 64 tokens。

切片的策略很有意思。巴别鸟没有用简单的滑动窗口，而是按文档结构（标题、段落、表格）做语义分块，这样检索出来的片段更完整，上下文不会断在半句。

切片后的文本送入 Embedding 模型。这一步巴别鸟用了多向量模型策略：文本类文件用 BGE-Large-ZH（中文效果最好的开源 Embedding 之一），表格类文件用专门的表格理解模型，图片和 CAD 图纸走 CLIP 系列模型。

向量化完成后，结果写入 Milvus，原始文件路径、Chunk 文本、文件元信息写入 PostgreSQL，全文内容写入 Elasticsearch。整个流程是消息队列驱动的，用 Kafka 做任务调度，支持失败重试和优先级队列。

2.2 Milvus 存储层的几个细节

Milvus .collection() 建表时要设计好 Schema。巴别鸟的 collection 大概长这样：

collection = Collection('zhichao_documents')
collection.schema = Schema([
    FieldSchema(name='id', dtype=DataType.VARCHAR, max_length=64, is_primary=True),
    FieldSchema(name='raw_text', dtype=DataType.VARCHAR, max_length=4096),
    FieldSchema(name='file_name', dtype=DataType.VARCHAR, max_length=256),
    FieldSchema(name='file_type', dtype=DataType.VARCHAR, max_length=32),
    FieldSchema(name='owner_id', dtype=DataType.VARCHAR, max_length=64),
    FieldSchema(name='department', dtype=DataType.VARCHAR, max_length=64),
    FieldSchema(name='chunk_index', dtype=DataType.INT32),
    FieldSchema(name='embedding', dtype=DataType.FLOAT_VECTOR, dim=1024)
])

注意 embedding 的 dim=1024，对应 BGE-Large-ZH 的向量维度。Milvus 建表后要建索引，HNSW 索引是标配，efConstruction=200，M=16。HNSW 在召回率和性能之间平衡得比较好，适合知识库这种 QPS 不是特别高但召回质量要求高的场景。

入库时用 batch insert，batch size 控制在 1000 条左右，过大容易 OOM，过小吞吐量上不去。如果用 GPU 版 Milvus，插入速度能提升 3-5 倍。

2.3 版本与依赖

实测在 Ubuntu 22.04 + NVIDIA T4 环境下，Milvus 2.3.x 稳定性和性能都不错。Embedding 服务用 vLLM 推理框架，batch 模式下吞吐量能到 500-800 QPS。LangChain 版本用 0.1.x，Python 3.10+。

三、深度搜索：召回 + 重排的两阶段

3.1 Query 处理链路

用户输入查询后，系统先做 Query 改写：同义词扩展（如"合同"扩展到"协议"、“合约”）、关键实体提取、查询压缩去掉冗余词。改写后的 query 同时发给两条召回链路：

向量召回：query 向量化后去 Milvus 做 ANN 检索，默认 top_k=100，返回 100 条候选。Milvus 的AnnSearchRequest() 支持 JSON 格式的过滤器，这里会把当前用户的部门信息作为预过滤条件，减少后续权限过滤的压力。

全文召回：query 去 Elasticsearch 做 BM25 检索，同样取 top 100。Elasticsearch 的优势是支持中文分词（ik_max_word 插件），关键词命中的文档能拿到很高的相关性分数。

3.2 RRFR 融合

两条链路的候选结果合并是个技术活。巴别鸟用的是 Reciprocal Rank Fusion（RRF）：

RRF_score = Σ 1 / (k + rank_i)

k 一般取 60。这个公式的好处是不用人工调参，对两条链路的结果做无损融合，高频出现在两条链路的文档会排在前面。融合后取 top 50 送去重排。

3.3 Cross-Encoder 重排

粗召回的结果送入 Cross-Encoder 重排模型。巴别鸟用的是 BAAI/bge-reranker-large，输入是 query 和 candidate 文本对，输出一个 0-1 的相关性分数。

重排的工程实现有几点要注意：

rerank_client = InferenceClient(model="BAAI/bge-reranker-large", device="cuda")
candidates = [doc.text for doc in candidates]
pairs = [[query, cand] for cand in candidates]
scores = rerank_client.predict(pairs, batch_size=32)

batch_size 不能太大，T4 显卡 32 比较稳，A100 可以开到 128。重排后取 top 20 组装 Context。

3.4 Permission Filter

重排后的 20 条结果不是直接返回，要过 Permission Filter。这里巴别鸟做的是行级权限校验：

def permission_filter(user_id, doc_ids):
    # 查用户所在部门及角色
    user = get_user_info(user_id)
    # 批量查文档的部门可见性
    docs = get_doc_permissions(doc_ids)
    return [d for d in docs if user.department in d.visible_departments]