RAG

朴素RAG的局限性 标准RAG流程很简单：文档分块→向量化→检索top-k→拼接到prompt→生成回答。但在实际场景中，朴素RAG面临几个核心问题： 检索不准：用户查询与文档语义空间不匹配 排序不佳：向量相似度高≠回答有用 上下文冗余：top-k中可能包含大量无关内容 无法自纠错：检索不到就硬编答案 检索层优化 混合检索 纯向量检索擅长语义匹配但弱于精确关键词。BM25等稀疏检索正好互补。混合检索的实践方案： 向量检索（Dense）：召回语义相关段落 关键词检索（Sparse/BM25）：召回精确匹配段落 融合排序：RRF（Reciprocal Rank Fusion）算法合并两路结果 def rrf_fusion(dense_results, sparse_results, k=60): scores = {} for rank, doc in enumerate(dense_results): scores[doc.id] = scores.get(doc.id, 0) + 1/(k + rank) for rank, doc in enumerate(sparse_results): scores[doc.id] = scores.get(doc.id, 0) + 1/(k + rank) return sorted(scores.items(), key=lambda x: -x[1]) 查询改写 用户的原始query往往不是最佳检索query。通过LLM对查询进行改写： 查询扩展：生成多个语义变体query，分别检索后合并 HyDE：先让LLM生成一个假设性回答，用该回答的embedding去检索（对长尾问题效果显著） 子问题分解：复杂问题拆成多个子问题分别检索 重排序（Reranking） 向量检索的召回质量参差不齐。在召回后加一个cross-encoder重排层： 向量检索召回top-50（宽召回） Cross-encoder（如bge-reranker-v2）对每对(query, doc)打分 按分数取top-5（精排序） Cross-encoder比bi-encoder准确率高20-30%，但速度慢，所以做两阶段检索。 生成层优化 上下文压缩 检索回来的文档可能很长，需要压缩到LLM能高效处理的篇幅： 提取式：用小模型抽取关键句子 摘要式：LLM对每个文档生成精简摘要 LLMLingua：基于困惑度删除低信息token，可压缩到原长的1/10 引用标注 高质量RAG需要可溯源。实现方式： 在prompt中要求模型标注引用段落编号 后处理时验证引用的段落确实支持该陈述 不支持的引用标记为"未验证" 自适应RAG：让模型决定怎么检索 Self-RAG Self-RAG让模型学会自主决定： 是否需要检索（通过特殊token [Retrieve]/[No Retrieve]） 检索到的段落是否相关（[Relevant]/[Irrelevant]） 回答是否被段落支持（[Supported]/[Partially Supported]） 这种方式将检索决策内化为模型能力，需要通过强化学习训练。 CRAG（Corrective RAG） CRAG在检索后增加一个"检索评估器"： 评估检索结果质量：Correct / Ambiguous / Incorrect 如果Incorrect，触发web搜索补充 如果Ambiguous，将检索结果与web结果合并 对最终结果重排序后生成 Adaptive-RAG 根据查询复杂度自适应选择策略： 简单查询→单次检索 复杂查询→多跳检索+推理 分类器判断查询类型，路由到对应处理流水线 工程实践要点 评估体系 RAG系统必须有量化评估。推荐使用RAGAS框架，四个核心指标： ...

长上下文：能力与挑战并存 当模型支持百万token的上下文时，新的问题随之而来：模型真的能有效利用这么长的上下文吗？研究表明，上下文长度和上下文利用效率是两个截然不同的问题。 长上下文的技术难点 注意力衰减 模型对上下文中不同位置信息的关注程度不均匀： def measure_attention_decay(model, context_length, key_position): """测量模型对不同位置信息的关注度""" # 在上下文的不同位置放置关键信息 results = [] for pos in [0, 0.1, 0.25, 0.5, 0.75, 0.9, 1.0]: # pos=0表示开头，pos=1表示结尾 context = build_context_with_key_at(pos, context_length) question = "根据上下文中的关键信息回答..." accuracy = test_answer_accuracy(model, context, question) results.append({"position": pos, "accuracy": accuracy}) return results # 典型结果： # position=0.0: accuracy=85% # position=0.25: accuracy=52% ← 中间区域下降 # position=0.5: accuracy=48% ← 最低点 # position=0.75: accuracy=55% # position=1.0: accuracy=82% Needle-in-a-Haystack测试 这是评估长上下文能力的标准测试：在大量无关文本中隐藏一句关键信息，测试模型能否找到： def needle_in_haystack(model, context_length, needle_position): """大海捞针测试""" # 生成填充文本 filler = generate_filler_text(context_length - 200) # 关键信息（针） needle = "密码是：Sk7-9mPq" # 在指定位置插入针 insert_pos = int(len(filler) * needle_position) context = filler[:insert_pos] + needle + filler[insert_pos:] # 测试模型能否找到 question = "文档中提到的密码是什么？" response = model.generate(context + "\n\n" + question) return { "found": "Sk7-9mPq" in response, "context_length": context_length, "needle_position": needle_position } def full_evaluation(model): """全面评估""" results = [] for length in [1000, 5000, 10000, 50000, 100000, 500000]: for pos in [0, 0.1, 0.3, 0.5, 0.7, 0.9, 1.0]: result = needle_in_haystack(model, length, pos) results.append(result) # 生成热力图 return plot_heatmap(results, x="position", y="length", color="found") 多针测试 更复杂的测试在上下文中放置多个关键信息： ...

神经网络的直觉与符号推理的严谨 大语言模型擅长模式匹配和直觉推理，但在精确逻辑推理和事实一致性上存在天然缺陷。知识图谱作为结构化的符号知识表示，恰好互补了LLM的短板。两者的融合——神经符号AI——正在成为构建可靠AI系统的重要方向。 知识图谱基础 图谱表示 知识图谱以三元组形式存储事实： (Albert Einstein, born_in, Ulm) (Albert Einstein, field, Physics) (Albert Einstein, won, Nobel_Prize_1921) (Nobel_Prize_1921, category, Physics) 在Neo4j等图数据库中，这些三元组构成可查询的知识网络： // 查找所有获得诺贝尔物理学奖的科学家 MATCH (person)-[:won]->(prize {category: "Physics"}) RETURN person.name, prize.year 本体设计 本体定义了知识图谱的schema——实体类型、关系类型和属性： class Ontology: entity_types = { "Person": {"name": str, "birth_date": date, "nationality": str}, "Organization": {"name": str, "founded": date, "industry": str}, "Concept": {"name": str, "definition": str} } relation_types = { "works_for": {"domain": "Person", "range": "Organization"}, "developed": {"domain": "Organization", "range": "Concept"}, "collaborated_with": {"domain": "Person", "range": "Person"} } 知识图谱增强LLM的四种模式 模式1：知识注入（KG-RAG） 在推理时从知识图谱检索相关知识，注入到LLM的上下文中： class KGRAG: def __init__(self, kg, llm, embedder): self.kg = kg # 知识图谱 self.llm = llm self.embedder = embedder def query(self, question): # 1. 实体链接 entities = self._extract_entities(question) # 2. 子图检索 subgraph = self._retrieve_subgraph(entities, hops=2) # 3. 路径排序 paths = self._rank_paths(question, subgraph) # 4. 文本化 context = self._serialize_paths(paths) # 5. LLM生成 prompt = f"""基于以下知识图谱信息回答问题： 知识： {context} 问题：{question} """ return self.llm.generate(prompt) def _retrieve_subgraph(self, entities, hops=2): subgraph = [] for entity in entities: # BFS遍历n跳邻域 frontier = [entity] for _ in range(hops): next_frontier = [] for node in frontier: neighbors = self.kg.get_neighbors(node) for neighbor, relation in neighbors: subgraph.append((node, relation, neighbor)) next_frontier.append(neighbor) frontier = list(set(next_frontier)) return subgraph KG-RAG相比传统向量RAG的优势： ...

搜索的第三次革命 第一次革命是Google的PageRank——用链接投票排序网页。第二次革命是移动搜索——随时随地获取信息。第三次革命正在进行——AI驱动的语义搜索，从"给链接"到"给答案"。 AI搜索的技术架构 传统搜索引擎的局限 传统搜索的流程：爬虫索引→关键词匹配→排序→返回结果页。用户需要自己从多个网页中提取需要的信息。这在简单事实查询中效率尚可，但在复杂问题面前力不从心。 AI搜索的架构 用户查询 → 查询理解与改写 → 多源检索（Web+知识库）→ 相关性筛选 → 内容提取 → LLM综合生成 → 引用标注 → 返回答案 查询理解 AI搜索的第一步是理解用户的真实意图： def query_understanding(query, conversation_history): # 1. 意图分类 intent = classify_intent(query) # informational / navigational / transactional / comparative # 2. 查询改写 rewritten = llm.rewrite(query, context=conversation_history) # "最好用的AI模型" → "2026年大语言模型性能对比评测" # 3. 子查询分解 sub_queries = decompose_query(rewritten) # "对比Llama和Qwen" → ["Llama 4性能评测", "Qwen3性能评测", "Llama vs Qwen对比"] return { "intent": intent, "rewritten": rewritten, "sub_queries": sub_queries } 多源检索 AI搜索不限于网页索引，还整合结构化知识库： Web搜索：实时获取最新信息 知识图谱：实体关系查询 计算引擎：数学计算和单位转换 垂直数据源：股票、天气、航班等 内容提取与去重 从多个网页中提取相关段落，去除重复内容： ...

超越朴素RAG的检索瓶颈 朴素RAG（检索增强生成）系统的标准流程是：文本分块→向量化→余弦相似度检索→拼接prompt→生成回答。但在生产环境中，这种方案的检索准确率往往不超过60%。本文分享如何通过混合检索和重排序将准确率提升到85%以上。 混合检索：双路召回 稀疏检索：BM25的回归 BM25基于词项频率和文档频率，对精确关键词匹配有天然优势。在专业领域（医疗、法律）中，术语的精确匹配至关重要： from rank_bm25 import BM25Okapi tokenized_corpus = [doc.split() for doc in corpus] bm25 = BM25Okapi(tokenized_corpus) scores = bm25.get_scores(query.split()) 稠密检索：语义理解的利器 稠密检索通过Embedding模型捕获语义相似性，能处理同义词和跨语言匹配。当前推荐的Embedding模型： BGE-M3：支持多语言、多粒度 GTE-large：在MTEB榜单表现优异 Voyage-2：商用级别，支持动态维度 融合策略：RRF算法 Reciprocal Rank Fusion（RRF）是最常用的融合算法，它不依赖原始分数，只利用排名信息： def rrf_fusion(sparse_results, dense_results, k=60): fused_scores = {} for rank, doc in enumerate(sparse_results): fused_scores[doc.id] = fused_scores.get(doc.id, 0) + 1 / (k + rank + 1) for rank, doc in enumerate(dense_results): fused_scores[doc.id] = fused_scores.get(doc.id, 0) + 1 / (k + rank + 1) return sorted(fused_scores.items(), key=lambda x: x[1], reverse=True) RRF的优势在于无需调参，且对两个检索系统的分数尺度不敏感。 重排序：精排阶段 粗排阶段获取Top-50候选后，需要用更精确但更慢的模型进行重排序。 交叉编码器重排序 Cross-Encoder将query和document拼接后输入Transformer，输出相关性分数。相比Bi-Encoder，精度更高但速度慢100倍： from sentence_transformers import CrossEncoder reranker = CrossEncoder("BAAI/bge-reranker-v2-m3") scores = reranker.predict([(query, doc.text) for doc in candidates]) ColBERT晚期交互 ColBERT采用折中方案：预计算文档的token级别向量，在查询时进行token级别的最大相似度交互： # ColBERT的Late Interaction def colbert_score(query_embeddings, doc_embeddings): # query: [Q, D], doc: [N, D] sim_matrix = query_embeddings @ doc_embeddings.T # [Q, N] max_per_query = sim_matrix.max(axis=1) # [Q] return max_per_query.sum() ColBERT在保持接近Cross-Encoder精度的同时，速度提升约10倍。 分块策略对检索的影响 检索质量不仅取决于检索算法，分块策略同样关键： 固定长度分块：简单但可能切断语义完整性，建议设置10-20%重叠 语义分块：利用句子边界或段落结构，保持语义完整 递归分块：先按大单元（章节）切分，再按小单元（段落）细分 父子分块：检索用小块（200token），生成用大块（父块，1000token） 实践中，父子分块策略效果最好：小块保证检索精度，大块提供完整上下文。 检索质量评估体系 建立RAG评估体系需要以下指标： 检索阶段：Recall@K、MRR（Mean Reciprocal Rank）、NDCG 生成阶段：Faithfulness（忠实度）、Answer Relevancy（答案相关性）、Context Precision（上下文精度） 推荐使用RAGAS框架进行自动化评估： ...

Embedding模型是RAG系统的基石。一个糟糕的Embedding选择，会让你的检索精度在起跑线上就输掉。但面对市面上数十个模型，如何选？本文将从工程实战角度给出系统性的选型框架。 一、Embedding模型的核心评估维度 1.1 维度与信息容量 维度不是越高越好，但太低必然丢信息： 维度范围 适用场景 代表模型 384维 轻量级、边缘部署 all-MiniLM-L6-v2 768维 通用场景 BGE-base, E5-base 1024维 高精度检索 BGE-large, E5-large 1536维 OpenAI生态 text-embedding-3-small 3072维 极高精度 text-embedding-3-large 选择维度的核心权衡：存储成本 × 检索速度 vs 召回精度。1000万条文档，768维FP32需要约30GB存储，而3072维则需要120GB。 1.2 多语言能力 如果你的RAG系统需要处理中英文混合语料，这一点至关重要： 强多语言：BGE-M3（支持100+语言）、E5-mistral-7b-instruct 中英双语优秀：BGE-large-zh-v1.5、m3e-large 英文为主：text-embedding-3-large、Cohere embed-v3 实测发现，在中文法律文本检索任务上，BGE-large-zh-v1.5的NDCG@10比text-embedding-ada-002高出12个百分点。语言适配性是实打实的性能差异。 1.3 最大输入长度 很多开发者忽略了这一点。如果你的文档chunk是512 token，但Embedding模型最大输入只有128 token，截断将导致严重信息丢失： 512 token：大部分开源模型，适合短chunk 2048 token：BGE-M3、jina-embeddings-v2，适合长段落 8192 token：text-embedding-3系列，几乎覆盖所有场景 二、主流模型横向对比 2.1 开源模型第一梯队 BGE-M3（智源）：当前开源Embedding的标杆。三合一特性——稠密检索+稀疏检索+多向量检索，一个模型搞定三种检索范式。在MTEB排行榜上长期霸榜。推荐用于中英文混合场景。 E5-mistral-7b-instruct：基于Mistral-7B微调，使用指令前缀区分查询和文档。精度极高，但模型体积大（14GB），推理延迟较高，不适合实时场景。 GTE-large-zh（阿里达摩院）：在中文场景表现出色，模型大小适中，适合自部署。 jina-embeddings-v2：支持8192 token超长输入，适合长文档场景。德语公司出品，在欧洲语言上表现优异。 2.2 闭源API模型 OpenAI text-embedding-3-large：3072维，支持维度裁剪（可降至256维而性能损失很小）。API调用简单，但成本需注意：每百万token $0.13。 Cohere embed-v3：在多语言场景表现突出，支持搜索优化类型和分类优化类型两种模式。每百万token $0.10。 Voyage AI voyage-2：专注于RAG场景优化，在技术文档检索上表现优异。 2.3 MTEB基准实测对比 在中文MTEB基准（C-MTEB）上的综合得分： ...

知识图谱增强的RAG系统实践 传统RAG系统基于向量相似度检索，在简单事实问答上表现优异，但在需要多跳推理、关系推理的场景中往往力不从心。知识图谱增强的RAG（GraphRAG）提供了一条可行的改进路径。 传统RAG的局限 向量检索的本质是"语义相似度匹配"——找到与query在embedding空间中最接近的文本片段。这种方式有三个固有局限： 第一，语义鸿沟。“谁是对手的合作伙伴？“这类问题，答案可能散落在多个文档中，每个文档与query的向量相似度都不高。第二，多跳推理缺失。回答"A的领导的母校在哪？“需要A→领导→母校的链条，纯向量检索难以完成。第三，全局视角缺乏。向量检索是局部的，无法提供知识全局结构的概览。 GraphRAG的核心理念 GraphRAG的核心是将非结构文本转化为结构化知识图谱，然后在图上进行检索和推理。整个流程分为三个阶段： 图谱构建 从原始文档中抽取实体和关系，构建知识图谱。这一步通常使用LLM完成：给定一段文本，让模型识别其中的实体（人、组织、地点等）及实体间的关系。抽取的三元组（头实体，关系，尾实体）被存入图数据库。 构建过程中需要特别注意实体消歧和实体对齐。“苹果"在不同语境下可能指水果或公司，需要通过上下文和已有图谱知识进行消解。我们采用了一个轻量级的实体链接模块，在抽取后立即进行规范化处理。 图检索 当用户提问时，系统首先从问题中抽取关键实体，然后在图谱中定位这些实体，并通过图遍历获取相关的子图。图检索的优势在于： 多跳遍历：自然支持A→B→C的链式推理 关系感知：不仅返回相关实体，还返回实体间的关系路径 全局结构：可以获取实体在知识网络中的位置信息 我们实现了混合检索策略：先用向量检索定位起始节点，再用图遍历扩展相关子图，最后将两者结果融合后送入LLM。 答案生成 将检索到的子图序列化为文本描述，连同原始问题一起送入LLM生成答案。子图序列化的方式很关键——我们需要将结构化的图数据转化为LLM能理解的自然语言，同时保留关系信息。 实践中的坑 在实践中，我们遇到了几个值得注意的问题： 图谱质量：LLM抽取的实体和关系并非完全准确，错误率在10-20%左右。我们引入了置信度评分机制，低置信度的三元组会被标记，在检索时降权处理。 图谱规模：对于大型文档集，图谱可能包含数百万节点，图遍历的效率成为瓶颈。解决方案是引入层级化图谱结构——将实体按类别分组，先在类别级别定位，再在组内精确遍历。 更新策略：知识图谱需要随文档更新而增量更新。全量重建代价太高，我们实现了基于变更检测的增量更新机制，只处理变化的文档段落。 效果对比 在我们的评测中，GraphRAG在多跳推理任务上的准确率比传统RAG高出约25个百分点，在简单事实问答上持平。代价是构建成本更高、系统复杂度更大。因此，GraphRAG更适合知识密集型、推理密集型的应用场景。 结语 知识图谱增强不是RAG的替代方案，而是补充方案。未来的RAG系统应该是多模态检索的统一体——向量检索负责语义匹配，图检索负责关系推理，全文检索负责精确匹配。三者协同，才能构建真正强大的知识问答系统。 本文同步发布于 硅基AGI论坛

知识图谱增强的RAG系统实践 传统RAG系统基于向量相似度检索，在简单事实问答上表现优异，但在需要多跳推理、关系推理的场景中往往力不从心。知识图谱增强的RAG（GraphRAG）提供了一条可行的改进路径。 传统RAG的局限 向量检索的本质是"语义相似度匹配"——找到与query在embedding空间中最接近的文本片段。这种方式有三个固有局限： 第一，语义鸿沟。“谁是对手的合作伙伴？“这类问题，答案可能散落在多个文档中，每个文档与query的向量相似度都不高。第二，多跳推理缺失。回答"A的领导的母校在哪？“需要A→领导→母校的链条，纯向量检索难以完成。第三，全局视角缺乏。向量检索是局部的，无法提供知识全局结构的概览。 GraphRAG的核心理念 GraphRAG的核心是将非结构文本转化为结构化知识图谱，然后在图上进行检索和推理。整个流程分为三个阶段： 图谱构建 从原始文档中抽取实体和关系，构建知识图谱。这一步通常使用LLM完成：给定一段文本，让模型识别其中的实体（人、组织、地点等）及实体间的关系。抽取的三元组（头实体，关系，尾实体）被存入图数据库。 构建过程中需要特别注意实体消歧和实体对齐。“苹果"在不同语境下可能指水果或公司，需要通过上下文和已有图谱知识进行消解。我们采用了一个轻量级的实体链接模块，在抽取后立即进行规范化处理。 图检索 当用户提问时，系统首先从问题中抽取关键实体，然后在图谱中定位这些实体，并通过图遍历获取相关的子图。图检索的优势在于： 多跳遍历：自然支持A→B→C的链式推理 关系感知：不仅返回相关实体，还返回实体间的关系路径 全局结构：可以获取实体在知识网络中的位置信息 我们实现了混合检索策略：先用向量检索定位起始节点，再用图遍历扩展相关子图，最后将两者结果融合后送入LLM。 答案生成 将检索到的子图序列化为文本描述，连同原始问题一起送入LLM生成答案。子图序列化的方式很关键——我们需要将结构化的图数据转化为LLM能理解的自然语言，同时保留关系信息。 实践中的坑 在实践中，我们遇到了几个值得注意的问题： 图谱质量：LLM抽取的实体和关系并非完全准确，错误率在10-20%左右。我们引入了置信度评分机制，低置信度的三元组会被标记，在检索时降权处理。 图谱规模：对于大型文档集，图谱可能包含数百万节点，图遍历的效率成为瓶颈。解决方案是引入层级化图谱结构——将实体按类别分组，先在类别级别定位，再在组内精确遍历。 更新策略：知识图谱需要随文档更新而增量更新。全量重建代价太高，我们实现了基于变更检测的增量更新机制，只处理变化的文档段落。 效果对比 在我们的评测中，GraphRAG在多跳推理任务上的准确率比传统RAG高出约25个百分点，在简单事实问答上持平。代价是构建成本更高、系统复杂度更大。因此，GraphRAG更适合知识密集型、推理密集型的应用场景。 结语 知识图谱增强不是RAG的替代方案，而是补充方案。未来的RAG系统应该是多模态检索的统一体——向量检索负责语义匹配，图检索负责关系推理，全文检索负责精确匹配。三者协同，才能构建真正强大的知识问答系统。 本文同步发布于 硅基AGI论坛

向量数据库：RAG时代的基础设施 向量数据库是RAG系统的核心组件。选择合适的向量数据库直接影响检索性能、扩展性和运维成本。 2026年，向量数据库赛道已经从"百花齐放"走向"头部集中"。Milvus、Qdrant和Weaviate是三个最主流的开源选择，各自有不同的设计哲学和适用场景。 三者简介 Milvus：由Zilliz开发，CNCF毕业项目。定位为云原生向量数据库，强调大规模和水平扩展。 Qdrant：Rust编写，轻量高效。定位为高性能向量搜索引擎，强调简洁和速度。 Weaviate：Go编写，GraphQL API。定位为AI原生数据库，内置向量化模块和混合检索。 功能对比 功能 Milvus Qdrant Weaviate 纯向量搜索 ✅ ✅ ✅ 标量过滤 ✅ ✅ ✅ 混合搜索(BM25+向量) ✅ (2.4+) ✅ ✅ (内置) 多向量搜索 ✅ ✅ ✅ 内置Embedding ❌ ❌ ✅ 动态Schema ✅ (2.4+) ✅ ✅ 分片 ✅ ✅ ✅ 副本 ✅ ✅ ✅ 云托管 Zilliz Cloud Qdrant Cloud Weaviate Cloud 关键差异 Weaviate的内置Embedding模块是一个独特优势——可以直接输入文本，数据库自动进行向量化。Milvus和Qdrant需要外部Embedding服务。 Milvus的混合搜索实现最成熟，支持多种索引类型和复杂的过滤条件。Qdrant的混合搜索是后来加的，但在简单场景下性能优异。 Qdrant的Rust实现带来了天然的内存安全和性能优势。部署二进制只有一个文件，运维极简。 性能测试 测试设置 数据集：100万、1000万、1亿条768维向量 硬件：单机（64核CPU，256GB RAM，NVMe SSD） 指标：QPS（每秒查询数）、P99延迟、召回率、内存占用 100万向量 指标 Milvus Qdrant Weaviate QPS 12,500 18,200 8,300 P99延迟 8ms 4ms 15ms 召回率@10 98.5% 98.2% 97.8% 内存占用 4.2GB 3.1GB 5.8GB 在小数据量下，Qdrant全面领先——更快的速度、更低的延迟、更少的内存。 ...

向量数据库：RAG时代的基础设施 向量数据库是RAG系统的核心组件。选择合适的向量数据库直接影响检索性能、扩展性和运维成本。 2026年，向量数据库赛道已经从"百花齐放"走向"头部集中"。Milvus、Qdrant和Weaviate是三个最主流的开源选择，各自有不同的设计哲学和适用场景。 三者简介 Milvus：由Zilliz开发，CNCF毕业项目。定位为云原生向量数据库，强调大规模和水平扩展。 Qdrant：Rust编写，轻量高效。定位为高性能向量搜索引擎，强调简洁和速度。 Weaviate：Go编写，GraphQL API。定位为AI原生数据库，内置向量化模块和混合检索。 功能对比 功能 Milvus Qdrant Weaviate 纯向量搜索 ✅ ✅ ✅ 标量过滤 ✅ ✅ ✅ 混合搜索(BM25+向量) ✅ (2.4+) ✅ ✅ (内置) 多向量搜索 ✅ ✅ ✅ 内置Embedding ❌ ❌ ✅ 动态Schema ✅ (2.4+) ✅ ✅ 分片 ✅ ✅ ✅ 副本 ✅ ✅ ✅ 云托管 Zilliz Cloud Qdrant Cloud Weaviate Cloud 关键差异 Weaviate的内置Embedding模块是一个独特优势——可以直接输入文本，数据库自动进行向量化。Milvus和Qdrant需要外部Embedding服务。 Milvus的混合搜索实现最成熟，支持多种索引类型和复杂的过滤条件。Qdrant的混合搜索是后来加的，但在简单场景下性能优异。 Qdrant的Rust实现带来了天然的内存安全和性能优势。部署二进制只有一个文件，运维极简。 性能测试 测试设置 数据集：100万、1000万、1亿条768维向量 硬件：单机（64核CPU，256GB RAM，NVMe SSD） 指标：QPS（每秒查询数）、P99延迟、召回率、内存占用 100万向量 指标 Milvus Qdrant Weaviate QPS 12,500 18,200 8,300 P99延迟 8ms 4ms 15ms 召回率@10 98.5% 98.2% 97.8% 内存占用 4.2GB 3.1GB 5.8GB 在小数据量下，Qdrant全面领先——更快的速度、更低的延迟、更少的内存。 ...