向量数据库

选型先看规模，别先看流行度 向量库这两年铺天盖地，但绝大多数团队的真实数据量撑死在几十万到几百万条 chunk——这个量级，杀鸡用牛刀的代价是运维复杂度暴涨。Milvus 这类分布式系统要部署 etcd、MinIO、集群节点，一个人维护都吃力；而你的检索延迟可能只需要 50ms 以内，单机方案完全够。选型第一问永远是：我的向量条数大概多少？QPS 多少？要不要过滤？ 四类方案对号入座 方案 适合规模 优点 代价 Chroma 十万级内、原型验证 pip install 即用，纯嵌入式 不适合高并发生产 pgvector 百万级、已有 PostgreSQL 复用现有库，SQL 联合查询 百万以上 HNSW 调参吃紧 Qdrant 百万到千万、生产混合检索 原生过滤、稀疏向量、Rust 性能 多一个独立服务要运维 Milvus 亿级、大规模分布式 水平扩展成熟 部署重，组件多 一个常被忽略的点：pgvector 的隐性优势是和业务表同库。你的 chunk 带着文档 ID、权限、来源元数据，用 SQL JOIN 直接过滤（比如「只检索当前部门有权看的文档」），比在向量库里单独维护一套 ACL 简单一个数量级。中小团队如果本来就用 PostgreSQL，加个 pgvector 扩展往往是最优解，CREATE EXTENSION vector; 一行搞定。 三个踩坑提醒 第一，HNSW 参数别用默认：ef_construct 和 ef_search 直接决定召回率和延迟的 trade-off，Qdrant、pgvector 都要根据数据量实测，默认值往往偏保守。第二，维度别盲目追高：OpenAI text-embedding-3-small 是 1536 维，bge-m3 是 1024 维，维度越高索引越大、检索越慢，够用就行。第三，量化压缩：Qdrant 支持 scalar 量化和 HNSW on-disk，百万级以上不开量化，内存直接爆——这是很多人「数据一多就 OOM」的根因。 ...

纯向量检索的坑 很多人搭 RAG，第一步就踩坑：把文档切块、扔进 embedding 模型、存进向量库，查询时相似度 Top-K 拉出来就喂给大模型。问题是向量检索擅长语义相似，却对精确匹配天生迟钝——零件编号、合同条款编号、API 函数名、报错信息、英文缩写这类东西，语义上和查询「差不多」，但向量距离拉不开，很容易把该召回的那条挤到 Top-20 之外。这也是为什么很多 RAG 演示很好看、一上真实知识库就答非所问。 混合检索：两条腿走路 正确做法是双路召回：一路 BM25（关键词稀疏检索，Elasticsearch、OpenSearch、MeiliSearch 都内置），一路 dense 向量检索。两路各取 Top-20，再用 RRF（Reciprocal Rank Fusion，倒数排名融合）合并成最终 Top-5。RRF 公式很简单：每条文档的得分等于 Σ 1/(k+rank)，k 常取 60，不需要调权重，比手工加权稳得多。 检索方式 擅长 短板 BM25 关键词 编号、专有名词、代码、报错 同义改写召回差 Dense 向量 语义同义、模糊提问 精确匹配弱 混合 + RRF 两者兼顾 多一路索引，工程量翻倍 LangChain、LlamaIndex 都内置了 EnsembleRetriever /混合检索模块，Qdrant 从 1.10 版起原生支持稀疏向量混合检索，不用再维护两套数据库。 三个实操建议 第一，切块别一刀切：正文按 500-800 token 切，代码块、表格单独成块并打上 metadata（来源、章节、文档类型），检索时按 metadata 过滤比切块大小更影响质量。第二，K 值要留余量：双路各取 Top-20、融合后重排取 Top-5，别一路只取 Top-5——融合的前提是两路都有足够候选。第三，用真实提问集回归测试：准备 20-30 条业务高频问题，标注标准答案出自哪一段，每次改切块、改 embedding、改 K 值都跑一遍召回命中率，比凭感觉调参靠谱。 收束 混合检索不是锦上添花，是生产 RAG 的及格线。关键词路保精确，向量路保语义，RRF 把两路排到一起——这套组合在绝大多数企业知识库场景里，都比纯向量检索召回率高出一截。下一步真正值钱的，是在混合召回之后再接一层重排，那是下一篇要拆的事。 ...

为什么记忆是Agent的最后一块拼图 2025年的AI Agent缺的不是工具调用能力，而是长期记忆。一个不能记住用户偏好、不能从历史交互中学习的Agent，每次对话都是从零开始。 2026年，这个问题正在被解决。 三大技术路线 1. MCP Memory协议 Anthropic推出的MCP协议生态中，Memory Server成为最热门的节点。Agent可以通过标准接口读写长期记忆，不再需要每个应用自己造轮子。 2. 向量数据库+知识图谱 纯向量检索容易产生"语义漂移"，2026年的主流方案是向量+图谱混合检索：向量负责语义相似，图谱负责逻辑关联。 3. 分层记忆架构 工作记忆：当前对话上下文 情景记忆：历史交互记录 语义记忆：提取的知识和偏好 程序记忆：学会的技能和工作流 实际效果 接入记忆系统后，Agent的用户留存率提升40%以上，因为它"认识你了"——记得你的项目、你的偏好、你上次聊到哪。 下一步 记忆系统标准化之后，下一个战场是记忆的隐私和所有权——谁拥有Agent的记忆数据？用户能不能导出、删除？

向量数据库：RAG时代的基石 所有RAG系统都需要向量数据库。2026年市场已经从"有没有"过渡到"哪个好"——选型不当会带来性能瓶颈、扩展困难、功能不足等问题。 三大主流方案 Milvus：大规模分布式 架构特点 Milvus采用存算分离架构： Coordinator：元数据管理和调度 Worker Node：查询节点和数据节点分离 对象存储：数据持久化（S3/MinIO） 消息队列：变更数据捕获（Kafka/Pulsar） 核心优势 水平扩展：支持十亿级向量 混合检索：向量+标量过滤 多索引：HNSW、IVF、DiskANN、GPU索引 云原生：K8s原生部署 适用场景 大规模生产环境（亿级向量） 需要高可用和水平扩展 团队有K8s运维能力 注意事项 部署复杂度高（微服务架构） 小规模场景（<100万向量）过重 内存占用较大 Qdrant：高性能轻量级 架构特点 Qdrant用Rust编写，单二进制部署： Collection：数据集合 Payload：向量关联的元数据 量化支持：标量量化(SQ8)、乘积量化(PQ)、二进制量化 磁盘索引：支持大于内存的数据集 核心优势 简单部署：单二进制+Docker 高性能：Rust实现，无GC暂停 丰富过滤：Payload过滤能力强大 量化压缩：内存占用极低 适用场景 中小规模（<1亿向量） 快速原型开发 对延迟敏感的场景 运维资源有限的团队 注意事项 分布式能力不如Milvus 不支持多租户隔离 生态插件较少 Weaviate：AI原生设计 架构特点 Weaviate定位为"AI原生数据库"： GraphQL API：内置API层 模块化向量化：内置多种embedding模型 对象存储+向量索引：一体化设计 多模态支持：图像/文本/视频嵌入 核心优势 开箱即用：内置embedding模型 GraphQL接口：前端友好 多模态：原生支持多种数据类型 混合检索：BM25+向量融合 适用场景 快速构建AI应用 需要多模态检索 前端团队主导的项目 不想单独管理embedding流程 注意事项 性能不如Qdrant极致 大规模部署经验较少 Go实现，性能依赖GC调优 性能对比 写入性能 数据库 单线程写入 批量写入(10K) 索引构建速度 Milvus 5K/s 50K/s 中等 Qdrant 8K/s 80K/s 快 Weaviate 3K/s 30K/s 中等 查询性能 数据库 p50延迟 p99延迟 并发QPS Milvus 5ms 20ms 10K+ Qdrant 2ms 8ms 5K+ Weaviate 8ms 30ms 3K+ 注：测试条件为1M向量，768维，HNSW索引，单节点。实际性能受数据规模、硬件、配置影响。 ...

向量数据库：AI应用的基础设施 RAG系统、语义搜索、推荐系统——这些AI应用的核心基础设施都是向量数据库。2026年的向量数据库市场已经从早期的"够用就行"进化到"精打细算"的阶段，选型直接影响系统性能和成本。 核心技术维度 索引算法 向量数据库的性能核心在于近似最近邻搜索（ANN）算法： HNSW（Hierarchical Navigable Small World）： 原理：多层图结构，顶层稀疏快速导航，底层密集精确搜索 优势：查询速度快，召回率高 劣势：内存占用大，构建慢 适合：中小规模（<1000万），高召回需求 IVF（Inverted File Index）： 原理：将向量空间聚类为N个桶，查询时只搜索最近的几个桶 优势：内存效率好，支持大规模数据 劣势：需要训练聚类模型，召回率受桶数影响 适合：大规模（>1000万），召回率可接受场景 PQ（Product Quantization）： 原理：将高维向量分成子向量，每个子向量量化编码 优势：存储压缩比高（10-100倍） 劣势：精度损失 适合：超大规模，成本敏感场景 组合索引：IVF+PQ或HNSW+PQ结合各自优势： # Milvus中的组合索引配置 collection_config = { "index_type": "IVF_PQ", "params": { "nlist": 1024, # IVF聚类中心数 "m": 16, # PQ子向量数 "nbits": 8, # 每个子向量的编码位数 }, "metric_type": "COSINE" } 量化与压缩 class QuantizationComparison: """不同量化方案的效果对比""" results = { "FP32 (无压缩)": { "recall": 1.0, "memory": "100%", "speed": "基准" }, "FP16": { "recall": 0.999, "memory": "50%", "speed": "1.2x" }, "INT8 (标量量化)": { "recall": 0.99, "memory": "25%", "speed": "1.5x" }, "PQ8 (乘积量化8bit)": { "recall": 0.95, "memory": "12.5%", "speed": "2.0x" }, "PQ4 (乘积量化4bit)": { "recall": 0.88, "memory": "6.25%", "speed": "2.5x" } } 主流方案对比 Milvus from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 连接Milvus connections.connect(host="localhost", port="19530") # 创建Collection fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True), FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1024), FieldSchema(name="metadata", dtype=DataType.JSON), ] schema = CollectionSchema(fields, "文档向量集合") collection = Collection("documents", schema) # 创建索引 collection.create_index( field_name="embedding", index_params={ "index_type": "HNSW", "metric_type": "COSINE", "params": {"M": 16, "efConstruction": 256} } ) # 搜索 results = collection.search( data=[query_vector], anns_field="embedding", param={"params": {"ef": 64}}, limit=10, expr='department == "engineering"' # 标量过滤 ) 优势： ...

记忆系统：智能体的"海马体" 人类大脑的海马体负责将短期记忆转化为长期记忆，AI Agent同样需要一套完善的记忆机制才能实现真正意义上的智能行为。当前主流的Agent框架中，记忆系统设计往往是最被低估却又最关键的组件。 三层记忆架构模型 1. 工作记忆（Working Memory） 工作记忆对应Agent的上下文窗口，是当前正在处理的信息。以GPT-4 Turbo为例，128K token的上下文窗口就是其工作记忆容量。但工作记忆存在两个核心问题： 容量限制：即使是128K也有上限，长对话会丢失早期信息 注意力衰减：研究表明，LLM在上下文中间位置的信息处理能力显著下降（Lost in the Middle现象） 工程实践中，我们通常采用滑动窗口策略配合摘要压缩来管理工作记忆： class WorkingMemory: def __init__(self, max_tokens=128000): self.max_tokens = max_tokens self.messages = [] self.current_tokens = 0 def add(self, message): self.messages.append(message) self.current_tokens += count_tokens(message) if self.current_tokens > self.max_tokens * 0.8: self._compress() def _compress(self): # 保留最近N条消息，将早期消息摘要化 recent = self.messages[-10:] old = self.messages[:-10] summary = llm_summarize(old) self.messages = [{"role": "system", "content": summary}] + recent 2. 情景记忆（Episodic Memory） 情景记忆记录Agent过去的交互经历，包括具体对话、决策过程和结果反馈。这一层通常通过向量数据库实现，如Chroma、Pinecone或Weaviate。 关键设计点在于索引策略。单纯按语义相似度检索往往不够，还需要加入时间衰减因子，因为更近的交互经验通常更具参考价值： def retrieve_episodic(query, top_k=5, alpha=0.7): # 语义相似度 semantic_scores = vector_db.search(query, top_k=20) # 时间衰减 for item in semantic_scores: days_ago = (datetime.now() - item.timestamp).days time_score = math.exp(-0.05 * days_ago) item.final_score = alpha * item.similarity + (1 - alpha) * time_score return sorted(semantic_scores, key=lambda x: x.final_score, reverse=True)[:top_k] 3. 语义记忆（Semantic Memory） 语义记忆是Agent的长期知识库，存储经过验证的事实、规则和概念。与情景记忆的区别在于：情景记忆是"经历"，语义记忆是"知识"。 典型的语义记忆构建流程包括： 从多次交互中提取共性知识 通过知识图谱建立实体间关系 定期进行知识一致性检查和冲突消解 记忆检索的工程优化 在实际项目中，记忆检索的延迟是用户体验的关键瓶颈。以下是一些经过验证的优化策略： 分层检索：先从语义记忆中快速过滤（关键词匹配），再进行向量相似度精确排序，可以将检索延迟从500ms降低到50ms以内。 预计算缓存：对于高频查询，预先计算并缓存检索结果。利用用户意图分类器判断是否命中缓存。 异步写入：记忆写入不应阻塞主流程。采用写前日志（WAL）模式，先快速持久化到本地，再异步同步到向量数据库。 记忆遗忘机制 好的记忆系统不仅需要记住，还需要遗忘。参考Ebbinghaus遗忘曲线，我们可以设计自适应遗忘策略： 高频访问的记忆：保留权重高，不易遗忘 被验证为错误的记忆：主动降低权重 超过30天未访问的非核心记忆：降级到冷存储 结语 记忆系统是AI Agent从"工具"向"助手"跃迁的关键基础设施。随着Agent应用场景的复杂化，记忆架构的设计将越来越接近人类认知模型。下一篇文章我们将探讨基于MCP协议的记忆共享机制，实现多Agent间的知识传递。 ...

向量数据库：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全面领先——更快的速度、更低的延迟、更少的内存。 ...

为什么大多数RAG项目都失败了 2026年，几乎所有企业都在尝试RAG，但真正在生产环境中稳定运行的比例不到30%。失败的原因惊人地一致——把RAG当作一个简单的"文档问答"系统，忽视了工程化部署中的无数细节。 本文将分享我们从多个企业RAG项目中总结的完整方案。 整体架构 一个生产级RAG系统包含以下七个核心模块： 1. 数据接入层 文档解析：支持PDF、Word、PPT、Excel、HTML、Markdown等格式。关键挑战是表格和图片的解析——我们采用Unstructured.io做基础解析，对表格使用专门的Table Transformer模型，对图片使用VLM生成描述。 数据源连接器：企业数据散落在各种系统中——SharePoint、Confluence、Jira、数据库、邮件服务器。我们为每个数据源开发专用连接器，支持增量同步和变更检测。 权限映射：企业数据有严格的权限控制。RAG系统必须在检索时尊重原始文档的访问权限。我们的方案是为每个文档片段标记ACL（Access Control List），检索时根据用户身份过滤。 2. 文档处理管道 分块策略：分块质量直接决定检索质量。我们采用三级分块策略： 语义分块：按段落和章节边界分块，保持语义完整性 重叠窗口：相邻块之间保留10-20%的重叠，避免边界信息丢失 层级分块：同时生成小块（256 Token）和大块（1024 Token），检索时小块匹配、大块提供上下文 元数据标注：为每个块标注来源文档、章节标题、文档类型、创建时间、作者等元数据。这些元数据在检索时用于过滤和重排序。 3. 索引层 嵌入模型选择：中文场景推荐BGE-M3或Qwen3-Embedding，英文场景推荐text-embedding-3-large。关键是选择支持长文本的嵌入模型——我们的块最大1024 Token，嵌入模型必须能处理这个长度。 向量数据库：根据数据规模选择： <100万块：Qdrant单机版足够，部署简单 100万-1000万块：Milvus集群版，支持水平扩展 1000万块：需要考虑分片策略和混合检索 混合索引：纯向量检索在精确匹配场景（如产品型号、人名搜索）效果差。我们同时建立BM25全文索引，检索时融合向量检索和BM25的结果。 4. 检索层 多路召回： 向量召回：语义相似度检索Top-K 关键词召回：BM25检索Top-K 元数据过滤：根据用户权限和时间范围预过滤 重排序：使用Cross-Encoder模型（如bge-reranker-v2）对召回的50-100个候选项重排序，取Top-5-10送入生成模型。重排序是RAG质量提升的关键一步——在我们的实验中，加入重排序后答案准确率提升约15%。 查询改写：用户的原始query往往不是最佳的检索query。我们使用LLM对query进行改写——扩展缩写、添加同义词、分解复合问题为子问题。 5. 生成层 Prompt模板：精心设计的Prompt模板对RAG质量至关重要。我们的模板包含： 系统指令：定义AI的角色和回答边界 检索上下文：格式化的检索结果，包含来源标注 用户问题：原始用户问题 输出要求：要求引用来源、不确定时说明 幻觉抑制：在Prompt中明确要求"仅基于提供的上下文回答，如果上下文没有相关信息请明确说明"。同时使用Self-Reflection机制——生成后让模型自检答案是否有上下文支撑。 6. 反馈与优化层 用户反馈收集：每个答案提供"有用/无用"反馈按钮和修正建议入口。这些反馈用于持续优化。 A/B测试框架：对索引参数、检索策略、Prompt模板的变更进行A/B测试，用数据驱动优化决策。 自动评估流水线：定期使用测试集自动评估系统质量，监控质量回归。 7. 监控与运维层 关键指标： 检索质量：召回率、精确率、MRR 生成质量：答案准确率、幻觉率、引用准确率 系统性能：端到端延迟、吞吐量、错误率 用户满意度：反馈评分、重试率 告警机制：当检索质量或生成质量低于阈值时自动告警，触发排查流程。 部署建议 起步阶段（1-2个月）：单机部署，Qdrant + 基础文档解析 + 单一嵌入模型。目标是验证核心流程跑通。 扩展阶段（3-6个月）：引入混合检索、重排序、查询改写。建立监控和反馈体系。 成熟阶段（6个月+）：集群化部署、多数据源接入、权限体系完善、持续优化闭环。 常见踩坑 过早优化：一开始就上复杂的GraphRAG或Agentic RAG，连基础RAG都没跑稳 忽视文档质量：垃圾进垃圾出，再好的检索算法也救不了低质量输入 分块策略一刀切：不同类型文档需要不同分块策略 不做重排序：仅靠向量检索的Top-K效果往往不够 没有评估体系：没有量化指标就无法判断优化是否有效 RAG不是一个项目，而是一个持续优化的工程。做好长期投入的准备，才能真正让它成为企业的知识引擎。 ...

为什么大多数RAG项目都失败了 2026年，几乎所有企业都在尝试RAG，但真正在生产环境中稳定运行的比例不到30%。失败的原因惊人地一致——把RAG当作一个简单的"文档问答"系统，忽视了工程化部署中的无数细节。 本文将分享我们从多个企业RAG项目中总结的完整方案。 整体架构 一个生产级RAG系统包含以下七个核心模块： 1. 数据接入层 文档解析：支持PDF、Word、PPT、Excel、HTML、Markdown等格式。关键挑战是表格和图片的解析——我们采用Unstructured.io做基础解析，对表格使用专门的Table Transformer模型，对图片使用VLM生成描述。 数据源连接器：企业数据散落在各种系统中——SharePoint、Confluence、Jira、数据库、邮件服务器。我们为每个数据源开发专用连接器，支持增量同步和变更检测。 权限映射：企业数据有严格的权限控制。RAG系统必须在检索时尊重原始文档的访问权限。我们的方案是为每个文档片段标记ACL（Access Control List），检索时根据用户身份过滤。 2. 文档处理管道 分块策略：分块质量直接决定检索质量。我们采用三级分块策略： 语义分块：按段落和章节边界分块，保持语义完整性 重叠窗口：相邻块之间保留10-20%的重叠，避免边界信息丢失 层级分块：同时生成小块（256 Token）和大块（1024 Token），检索时小块匹配、大块提供上下文 元数据标注：为每个块标注来源文档、章节标题、文档类型、创建时间、作者等元数据。这些元数据在检索时用于过滤和重排序。 3. 索引层 嵌入模型选择：中文场景推荐BGE-M3或Qwen3-Embedding，英文场景推荐text-embedding-3-large。关键是选择支持长文本的嵌入模型——我们的块最大1024 Token，嵌入模型必须能处理这个长度。 向量数据库：根据数据规模选择： <100万块：Qdrant单机版足够，部署简单 100万-1000万块：Milvus集群版，支持水平扩展 1000万块：需要考虑分片策略和混合检索 混合索引：纯向量检索在精确匹配场景（如产品型号、人名搜索）效果差。我们同时建立BM25全文索引，检索时融合向量检索和BM25的结果。 4. 检索层 多路召回： 向量召回：语义相似度检索Top-K 关键词召回：BM25检索Top-K 元数据过滤：根据用户权限和时间范围预过滤 重排序：使用Cross-Encoder模型（如bge-reranker-v2）对召回的50-100个候选项重排序，取Top-5-10送入生成模型。重排序是RAG质量提升的关键一步——在我们的实验中，加入重排序后答案准确率提升约15%。 查询改写：用户的原始query往往不是最佳的检索query。我们使用LLM对query进行改写——扩展缩写、添加同义词、分解复合问题为子问题。 5. 生成层 Prompt模板：精心设计的Prompt模板对RAG质量至关重要。我们的模板包含： 系统指令：定义AI的角色和回答边界 检索上下文：格式化的检索结果，包含来源标注 用户问题：原始用户问题 输出要求：要求引用来源、不确定时说明 幻觉抑制：在Prompt中明确要求"仅基于提供的上下文回答，如果上下文没有相关信息请明确说明"。同时使用Self-Reflection机制——生成后让模型自检答案是否有上下文支撑。 6. 反馈与优化层 用户反馈收集：每个答案提供"有用/无用"反馈按钮和修正建议入口。这些反馈用于持续优化。 A/B测试框架：对索引参数、检索策略、Prompt模板的变更进行A/B测试，用数据驱动优化决策。 自动评估流水线：定期使用测试集自动评估系统质量，监控质量回归。 7. 监控与运维层 关键指标： 检索质量：召回率、精确率、MRR 生成质量：答案准确率、幻觉率、引用准确率 系统性能：端到端延迟、吞吐量、错误率 用户满意度：反馈评分、重试率 告警机制：当检索质量或生成质量低于阈值时自动告警，触发排查流程。 部署建议 起步阶段（1-2个月）：单机部署，Qdrant + 基础文档解析 + 单一嵌入模型。目标是验证核心流程跑通。 扩展阶段（3-6个月）：引入混合检索、重排序、查询改写。建立监控和反馈体系。 成熟阶段（6个月+）：集群化部署、多数据源接入、权限体系完善、持续优化闭环。 常见踩坑 过早优化：一开始就上复杂的GraphRAG或Agentic RAG，连基础RAG都没跑稳 忽视文档质量：垃圾进垃圾出，再好的检索算法也救不了低质量输入 分块策略一刀切：不同类型文档需要不同分块策略 不做重排序：仅靠向量检索的Top-K效果往往不够 没有评估体系：没有量化指标就无法判断优化是否有效 RAG不是一个项目，而是一个持续优化的工程。做好长期投入的准备，才能真正让它成为企业的知识引擎。 ...