1、索引基础：什么是RAG索引、为什么需要索引、索引的核心组件

聊RAG系统，绕不开一个核心问题：索引。

我见过不少团队，模型选得不错，Prompt也调得挺细，结果上线后召回率惨不忍睹。查来查去，根子都在索引上。说白了，索引就是RAG系统的地基。地基没打好，上面再花哨也白搭。

1.1 什么是RAG索引

先给个直观的定义：RAG索引，就是把原始文档加工成一种“机器好理解、检索快准狠”的结构化数据。

你想想看，大模型本身不认识PDF、Word、Markdown文件。它只认。索引要做的，就是把人类可读的文档，转成模型能高效检索的中间表示。

我个人习惯把索引比作“图书馆的图书目录卡”。没有目录卡，你要在一百万本书里找一本讲“Python异步编程”的，只能一本本翻。有了目录卡，直接定位到书架、楼层、具体位置。RAG索引干的也是类似的事——把非结构化文本，映射成可快速定位的向量空间和元数据表。

1.2 为什么需要索引

有人可能会问：“我直接把整篇文档塞给模型不行吗？”

嗯，理论上可以。但实际项目里，你会遇到三个绕不开的坎：

• 上下文窗口限制：的128K上下文看着挺大，但你要检索的是百万级、千万级的文档库。一次推理根本装不下。
• 检索效率：暴力扫描所有文档，时间复杂度O(n)。当n到百万级别，用户等不起。索引能把检索降到O(log n)甚至近似常数时间。
• 相关性精度：整篇文档里可能只有一段话有用。索引让你能精准定位到“段落级”甚至“句子级”的相关内容。

我在项目中遇到过最典型的场景：一个金融合规问答系统，文档库有50万份PDF。没做索引前，一次检索要8秒，召回率不到60%。做了分块+向量索引后，检索降到200毫秒，召回率提升到92%。这就是索引的价值——用空间换时间，用结构换精度。

1.3 索引的核心组件

一个完整的RAG索引，由三个组件构成。缺一个，系统就不完整。我按重要程度排个序：

组件	职责	存储内容	典型技术
文档存储	保存原始文本块	分块后的文本内容	Elasticsearch、MongoDB、PostgreSQL
向量存储	保存语义向量	文本块的Embedding向量	FAISS、Pinecone、Weaviate、Qdrant
元数据存储	保存结构化属性	文件名、日期、作者、章节、标签等	关系型数据库、键值存储

1.3.1 文档存储

文档存储是索引的“原材料仓库”。原始文档经过分块（Chunking）后，每个块会存到这里。

为什么不能只存向量？因为向量是压缩后的语义表示，丢失了原始文本的细节。当模型需要生成答案时，它需要引用原始文本，而不是向量。

我曾经犯过一个错：只建了向量索引，没保留原始文本块。结果检索出来的向量找不到对应的原文，整个生成环节直接崩了。嗯，从那以后，我再也不敢省略文档存储了。

1.3.2 向量存储

向量存储是RAG索引的“灵魂”。它存的是文本块的Embedding向量——通常是768维或1536维的浮点数数组。

检索时，系统把你的查询也转成向量，然后在向量空间里找“最近邻”。说白了，就是算余弦相似度或欧几里得距离，找到最接近的那几个块。

我个人习惯用FAISS做本地原型，用Pinecone或Qdrant做生产环境。选型时主要看三点：

• 检索速度：是否支持IVF、HNSW等近似最近邻算法
• 可扩展性：能否支持亿级向量
• 过滤能力：是否支持向量检索+标量过滤混合查询

1.3.3 元数据存储

元数据存储是索引的“索引”。它存的是每个文本块的“身份证信息”。

举个例子：一份2024年的财报PDF，分成了50个块。每个块除了文本内容和向量，还需要记录：

• 来源文件名：2024_annual_report.pdf
• 页码：12-15
• 章节：资产负债表
• 日期：2024-12-31
• 作者：财务部

有了元数据，你就能做预过滤。比如用户只问“2024年的数据”，系统可以先过滤掉所有非2024年的块，再在剩下的块里做向量检索。这能大幅提升精度和速度。

1.4 索引核心架构图

下面这张图，把三个组件的关系画清楚了。你看一眼就能明白数据是怎么流转的：

数据流向很清晰：原始文档 → 分块 → 同时写入三个存储 → 检索时合并结果。三个组件通过块ID关联，缺一不可。

1.5 小结

这一章我们聊了索引的本质：它是文档、向量、元数据三者的有机组合。文档存储保底，向量存储提速，元数据存储提准。

我个人觉得，理解这三个组件的分工，是做好RAG索引调优的第一步。后面所有优化——分块策略、向量维度选择、元数据设计——都是围绕这三个组件展开的。

嗯，基础打牢了，后面才能走远。