深入理解 RAG 架构：从向量检索到混合搜索的最佳实践
Deep Dive into RAG Architecture: Best Practices from Vector Search to Hybrid Search
| iDev Engineering | 2026-08-27T11:11:13
本文从工程实践角度深入剖析 RAG（检索增强生成）架构的核心组件，探讨向量检索与关键词搜索的融合策略，分享 iDev 在大规模知识库场景下的优化经验。
This article provides an in-depth analysis of RAG architecture core components from an engineering perspective, discussing strategies for combining vector search with keyword search, and sharing iDev's optimization experience in large-scale knowledge base scenarios.
RAG 架构概述RAG（Retrieval-Augmented Generation）通过将外部知识库与大语言模型结合，解决了模型知识时效性和领域专业性的问题。在 iDev 平台中，RAG 架构支撑着代码搜索、文档问答和智能补全等核心功能。向量检索引擎选型主流方案对比Milvus：高性能、可扩展，适合大规模生产环境Qdrant：Rust 实现，单机性能优秀Weaviate：内置向量化模块，上手简单pgvector：PostgreSQL 原生扩展，运维成本低iDev 选择 Milvus 作为主向量引擎，配合 pgvector 处理中小规模的项目级检索。混合搜索策略融合公式我们采用 RRF（Reciprocal Rank Fusion）算法融合向量检索和 BM25 关键词搜索的结果：score = sum(1 / (k + rank_i)) for each retriever k = 60 # 默认平滑因子查询改写在用户查询进入检索管道前，我们使用小模型进行查询扩展和意图识别，将单一查询拆分为 2-3 个子查询，显著提升召回率。分块策略文档分块是 RAG 系统中最易被忽视但影响最大的环节。iDev 采用基于语义的自适应分块，每个 chunk 控制在 256-512 token，并保留前后文重叠区域。性能优化通过引入缓存层、预计算和异步索引更新，iDev 的 RAG 系统在千万级文档规模下仍能保持 P99 检索延迟低于 150ms。
RAG Architecture OverviewRAG (Retrieval-Augmented Generation) addresses the challenges of model knowledge timeliness and domain expertise by combining external knowledge bases with large language models. In the iDev platform, RAG architecture supports core features including code search, document Q&A, and intelligent completion.Vector Search Engine SelectionComparison of Major OptionsMilvus: High performance, scalable, suitable for large-scale productionQdrant: Rust implementation, excellent single-node performanceWeaviate: Built-in vectorization modules, easy to get startedpgvector: Native PostgreSQL extension, low operational costiDev chose Milvus as the primary vector engine, complemented by pgvector for small to medium-scale project-level retrieval.Hybrid Search StrategyFusion FormulaWe use the RRF (Reciprocal Rank Fusion) algorithm to merge results from vector search and BM25 keyword search:score = sum(1 / (k + rank_i)) for each retriever k = 60 # default smoothing factorQuery RewritingBefore user queries enter the retrieval pipeline, we use a small model for query expansion and intent recognition, splitting a single query into 2-3 sub-queries, significantly improving recall.Chunking StrategyDocument chunking is the most easily overlooked yet most impactful component in a RAG system. iDev uses semantic-based adaptive chunking, controlling each chunk to 256-512 tokens with overlapping context windows.Performance OptimizationBy introducing caching layers, pre-computation, and asynchronous index updates, iDev's RAG system maintains P99 retrieval latency under 150ms even at tens of millions of documents.