本地处理1000+ PDF: 构建生产级RAG系统

为什么默认RAG在大规模下失效

• 索引超出RAM： LanceDB、ChromaDB和FAISS默认都是内存驻留的。当索引超过可用RAM（16 GB笔记本上通常是5-8 GB向量）时，它们会退化为磁盘读取，p95查询延迟从~300ms跳到1-3秒。
• 纯余弦搜索遗漏罕见词： 密集embedding会低估罕见的专有名词、药品名称、法条编号和代码标识符。查询"Section 230(c)(1)"会检索到关于"Section 9"的chunks，因为embedding无法区分数字上的精确性。BM25能捕捉到这些；纯余弦搜索会漏掉。
• 规模扩大后Top-K=4太窄： 在1000个chunks时，top-4的召回率还不错。到50000个chunks时，真正最佳的chunk常常排在第12-30位——超出了top-4窗口。检索看起来在工作（答案看似合理），但实际上悄悄建立在错误的段落上。
• 没有元数据过滤会浪费索引： 在一个10000文档的语料库上问"Smith对X说了什么"，会搜索索引中的每一个chunk，而系统本应先过滤到"Smith撰写的文档"。原生RAG没有元数据预过滤的概念。
• 默认512/0的chunk大小会切碎长上下文： PDF段落和法律条款很少能塞进512个token。0重叠的默认设置会在边界处丢失语义。1000/200的调优能修复中等规模语料库的问题；超过5000个文档就需要分层分块。
• 更新时的embedding漂移： 当你在原始索引建立三个月后新增1000个PDF时，sentence-transformer模型版本可能已经变化。在同一个索引中混用两个模型版本的embedding会悄悄降低检索质量——每种架构在更换embedding模型时都要求完全重新索引。

架构决策树：先按语料库大小选择

• 1000个文档以下（约5000个chunks以下）： AnythingLLM Desktop，chunk大小1000、重叠200，embedding模型用nomic-embed-text-v1.5。不需要自定义代码。搭建步骤见30分钟入门指南。
• 1000-5000个文档（5k-25k个chunks）： LlamaIndex本地模式，采用分层索引（DocumentSummaryIndex + VectorStoreIndex），Ollama作为LLM提供方，embedding模型用nomic-embed-text-v1.5，向量存储用LanceDB或ChromaDB。约150行Python，作为长驻进程运行。
• 5000-10000个文档（25k-50k个chunks）： 自定义技术栈，包含Ollama、ChromaDB、通过Whoosh或Tantivy实现的BM25混合搜索，以及在top-50候选上运行的BGE-reranker-v2-m3。约300-400行Python。在这个规模上，reranker是不能省略的。
• 10000个文档以上（50k+个chunks）： Ollama + Qdrant单节点模式，基于payload的元数据过滤，使用Qdrant原生稀疏向量的混合搜索，BGE-reranker-v2-m3，以及按文档ID索引的分层摘要索引。生产级的单用户方案。
• 多用户（任意规模）： 在上述任意方案前放一个Open WebUI，或者用一个小型FastAPI包装同一套Qdrant + Ollama后端。多用户改变的是运维方式（认证、隔离、限流），而不是检索架构本身。

架构对比表

方案一：AnythingLLM 调优版（100-1,000 文档）

• LLM： 通过Ollama运行Llama 3.3 8B Q4_K_M（推理时约占用5 GB内存）。在24 GB+的系统上，Qwen 3 14B Q4能明显提升综合能力。
• Embedding模型： 把AnythingLLM原生默认的embedder换成通过Ollama运行的nomic-embed-text-v1.5。默认embedder是"AnythingLLM扩展不了"这类反馈里最主要的原因。
• 分块： 1000个token，重叠200个token，在每个工作区的Vector Database设置里单独调整。默认的512/0对于任何超过几十个文档的语料库都是错误的。
• Top-K： 从默认的4提高到6-8。在1000个文档规模下，真正最佳的chunk经常排在第5-7位，LLM忽略弱相关chunk的能力，比它凭空补全缺失信息的能力要强。
• 工作区划分： 按文档类别（论文、合同、笔记）各建一个工作区。每个工作区都是独立索引的LanceDB；不支持跨工作区查询，但单个工作区内的召回率会高得多。

方案二：LlamaIndex 本地部署（1,000-5,000 文档）

• 技术栈： Ollama + LlamaIndex + LanceDB（或ChromaDB）+ 通过OllamaEmbedding适配器调用的nomic-embed-text-v1.5。持久化到磁盘；作为长驻Python进程运行，通过CLI或小型FastAPI包装器交互。
• 在VectorStoreIndex之上叠加DocumentSummaryIndex： LlamaIndex在索引时为每个文档生成摘要，检索时先通过摘要搜索命中相关文档，再在这些文档内搜索chunks。这是成本最低的分层检索模式。
• 查询路由： RouterQueryEngine把事实查询路由到chunk索引，把综合类查询路由到摘要索引。约30行代码；在长文档语料库上能让答案质量翻倍。
• 句子窗口检索： 一个可选的第二索引，检索目标句子及其前后N个句子。适合法律和学术类语料库——答案是一句话，但其含义依赖于周围的段落。
• 持久化： index.storage_context.persist(persist_dir=...)会保存全部内容。在NVMe SSD上，5000文档索引的重新加载时间是10-30秒。

# Minimal LlamaIndex local RAG with hierarchical indices (~30 lines)
from llama_index.core import VectorStoreIndex, DocumentSummaryIndex, SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.llm = Ollama(model="llama3.3:8b-instruct-q4_K_M", request_timeout=120)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text:latest")
Settings.chunk_size = 1000
Settings.chunk_overlap = 200

docs = SimpleDirectoryReader("./pdfs").load_data()

# Summary index for routing + chunk index for retrieval
summary_index = DocumentSummaryIndex.from_documents(docs)
chunk_index = VectorStoreIndex.from_documents(docs)

summary_index.storage_context.persist("./storage/summary")
chunk_index.storage_context.persist("./storage/chunks")

# At query time, route by question type
response = chunk_index.as_query_engine(similarity_top_k=8).query(
    "What sample size did Smith et al. use?"
)
print(response)

方案三：Ollama + ChromaDB 自定义方案（5,000-10,000 文档）

• 技术栈： Ollama + ChromaDB（服务器模式）+ 用Whoosh或Tantivy实现BM25 + BGE-reranker-v2-m3（约570 MB，CPU上每秒50-100个候选）。可作为单个Python进程运行，也可拆分为ingest工作进程和查询工作进程。
• 检索时的混合搜索： 并行运行BM25和密集向量检索，各取top-25，去重后，用cross-encoder对合并后的top-50重新排序。最终top 6-8个传给LLM。
• ChromaDB元数据字段： 索引时为每个chunk填充source_filename、page_number、document_type、author、year。查询时按payload过滤（where={"document_type": "contract"}）能把检索空间缩小5-10倍，且不损失质量。
• 批量索引： ChromaDB以32-128个chunk为一批进行embedding。在RTX 4070上，BGE-reranker是瓶颈（CPU上50-100个候选/秒；GPU上400+个/秒）。
• 持久化： ChromaDB写入一个SQLite + Parquet目录。50000个chunk的索引在磁盘上约3-5 GB。备份就是复制目录。

方案四：Ollama + Qdrant 生产级方案（10,000+ 文档）

• 技术栈： Ollama + Qdrant（Docker、单节点）+ 原生稀疏向量（Qdrant 1.10+内置的BM25等效实现）+ BGE-reranker-v2-m3 + 一层小型Python编排逻辑。
• 原生混合搜索： Qdrant在同一个collection中支持密集向量+稀疏向量，查询时进行加权融合。不需要维护单独的BM25进程。
• HNSW调优： 在50000+个向量规模下，把索引构建的ef_construct提高到200、m提高到32，查询时使用ef=128。默认值可用，但会用约10%的召回率换取更快的构建速度。
• 用于过滤的payload schema： Qdrant把payload当作一等公民。把author、document_type、year、tags索引为keyword payload，实现亚毫秒级的预过滤。
• 分层检索： 维护两个collection——summaries（每个文档一个向量）和chunks（常规chunk）。先在summary collection中路由查询，再在命中的文档ID范围内做chunk搜索。
• 持久化： Qdrant写入一个挂载卷。10万个chunk的collection在磁盘上约占6-12 GB，具体取决于payload大小和HNSW设置。

# Qdrant collection with dense + sparse vectors and metadata filtering
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, SparseVectorParams, SparseIndexParams
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config={
        "dense": VectorParams(size=768, distance=Distance.COSINE),  # nomic-embed-text-v1.5
    },
    sparse_vectors_config={
        "bm25": SparseVectorParams(index=SparseIndexParams(on_disk=False)),
    },
)

# Query: hybrid search + payload filter, no separate BM25 process needed
from qdrant_client.models import Filter, FieldCondition, MatchValue, Prefetch

results = client.query_points(
    collection_name="docs",
    query=dense_vec,
    using="dense",
    prefetch=[
        Prefetch(query=sparse_vec, using="bm25", limit=25),
        Prefetch(query=dense_vec, using="dense", limit=25),
    ],
    query_filter=Filter(
        must=[FieldCondition(key="document_type", match=MatchValue(value="contract"))]
    ),
    limit=50,  # before rerank
)

混合搜索：BM25+向量组合

• 为什么纯密集检索会失效： embedding会低估罕见token。像"RFC 9110 section 7.4"或"MNDA-2024-0143"这样的查询，会被embedding到通用的IETF/合同类chunk附近。BM25能捕捉到精确标识符；密集检索会漏掉。
• 为什么纯BM25会失效： 词汇匹配会漏掉改写后的说法。查询"我们怎么取消？"对上标题为"终止程序"的chunk，在密集空间中能匹配，但在BM25里得分为0。
• 倒数排名融合（RRF）是标准的合并方法： 对出现在任一结果列表中的每个chunk，按1/(60+rank_dense) + 1/(60+rank_bm25)计算分数，降序排列。60是一个平滑常数；实践中30-100之间都可用。
• 实用配方： 从每种方法各取top-25，通过RRF合并，取top-50送入reranker，最后取top 6-8传给LLM。这是超过1000个文档规模后的标准生产管道。
• 存储成本： BM25索引很小（每10000个文档约50-150 MB），相比之下同等规模的密集索引要500 MB-2 GB。在已有的密集索引上加装BM25成本很低。

重排序：Top-N 精炼阶段

• BGE-reranker-v2-m3（约570 MB，多语言，Apache 2.0）是2026年5月的默认选择。在现代CPU上每秒处理50-100个候选；GPU上400+/秒。对top-50重排的延迟成本，CPU上约200-500ms，GPU上约80-150ms。
• 为什么cross-encoder在检索上更有优势： 密集embedding独立编码查询和文档，模型从未同时看到二者。Cross-encoder联合读取`[CLS] query [SEP] candidate [SEP]`并直接给这对打分。Recall@5通常能提升15-25个百分点。
• 在哪里插入reranker： 混合搜索之后、LLM之前。从混合搜索取top-50，重排到top 6-8，把这些送给LLM作为上下文。
• 替代方案——Cohere Rerank API： 质量更高，但需要一次云端调用。对于完全本地的技术栈，BGE-reranker-v2-m3是务实的默认选择。mxbai-rerank-base-v2是有力的备选。
• 1000个文档以下可以跳过reranker： 质量提升不足以抵消延迟成本。超过5000个文档后跳过它，会有约15-25%的答案建立在错误的chunk上。

元数据过滤：预先缩小搜索空间

• 索引时应填充的通用payload字段： source_filename、page_number、document_type（论文/合同/笔记/wiki）、author、year、language，以及任何领域特定标签（如case_number、project_id、client_id）。
• 查询时预过滤： "2024年第三季度董事会纪要对定价说了什么？"→先按document_type=board_minutes AND year=2024 AND quarter=3过滤，再在约12个文档而非全部10000个中做向量搜索。
• 向量存储库支持： Qdrant的payload、Weaviate的properties、ChromaDB的metadata、LanceDB的schema列都支持过滤。性能有差异——Qdrant对已索引字段的payload过滤是亚毫秒级；ChromaDB在超过10万个chunk时的metadata过滤可能增加50-150ms。
• 自动提取元数据： 对法律类语料库，索引时用一次小型LLM处理，可以提取案件编号、日期和当事人姓名。在Llama 3.3 8B上每个文档约耗时30秒；每次导入只需运行一次。
• 与混合搜索结合： payload过滤先缩小范围→在过滤后的集合内做BM25+密集检索→再reranking。Payload过滤是任何大型RAG系统中成本最低的5-10倍加速手段。

分层检索：先摘要，再chunk

• 每文档摘要： 索引时，提示LLM为每个文档写一段100-200个token的摘要，将这些摘要embedding进单独的summaries collection。在Llama 3.3 8B上，每个文档成本约30-90秒。
• 两阶段检索： (1) 对查询做embedding，搜索summaries，取top-5个文档；(2) 在这5个文档内，通过混合搜索检索top-8个chunks；(3) 需要时进行reranking；(4) 送入LLM。
• 最有帮助的场景： 综合类和跨文档查询（"比较这几篇论文如何处理X"）。事实检索类查询（"Smith报告的数值是多少？"）单用chunk索引就够了——摘要这一道弯路只会增加延迟，不会提升质量。
• 成本权衡： 索引存储翻倍（摘要本身很小，但索引基础设施是双份的）。对未路由的查询延迟也会翻倍。收益体现在10000+文档规模下的降噪上。
• LlamaIndex内置了这个模式： DocumentSummaryIndex加RouterQueryEngine就是一个30行的实现。用ChromaDB或Qdrant的自定义Python实现约80-120行。

100、1000、10000 文档的实测基准

存储规划与硬件要求

• 每1000个PDF（每份约12页）的原始文本： 约50-150 MB提取文本，具体因文档密度而有较大差异。
• 1000个文档的向量： 磁盘上约300-400 MB，含HNSW索引开销。如果跳过HNSW索引改用暴力搜索（5000个文档以下可接受），约120-180 MB。
• 10000个文档的向量： 磁盘上约3-5 GB。HNSW构建在现代CPU上耗时10-30分钟。
• 50000个文档的向量： 磁盘上约15-25 GB。索引构建时间是瓶颈——预留2-4小时一次性CPU工作量。
• 查询时的RAM： 密集检索需要索引的约30-50%驻留在工作内存中才能实现低延迟查询。5 GB的索引配合HNSW，在8-16 GB RAM下查询体验流畅；暴力搜索则需要完整索引常驻。
• 索引时的RAM： 峰值约为embedding模型大小的2-3倍（nomic-embed-text约600 MB）加上每批文本。8 GB空闲RAM足以完成索引阶段。
• GPU与CPU： 独立GPU或Apple Silicon的embedding吞吐量比CPU快4-8倍。对于10000+文档的一次性索引，GPU能节省1-3小时。对于查询时的embedding（一次一条查询），CPU完全够用。
• 磁盘类型很重要： 5000+文档规模下，NVMe SSD是实际底线。SATA SSD会给冷查询延迟增加30-100%；机械硬盘超过约2000个文档就不可用。

增量索引与去重

• 基于哈希的精确去重（导入时）： 对原始文件字节做SHA-256。跳过哈希已存在于索引中的文件。成本很低，能捕捉完全相同的文件，但漏掉近似重复（同一份扫描件的不同OCR结果、格式转换等）。
• 内容哈希去重： 对去除空白后提取的纯文本做SHA-256。能捕捉同一文档的不同文件格式版本。每个文件在导入时增加约5ms。
• 用MinHash处理近似重复： 对于同一文档多个草稿不断累积的法律和学术语料库，计算MinHash签名（每份文档约128字节），跳过与已有条目Jaccard相似度超过阈值的文件。
• 文档ID永久有效： 删除后永远不要复用文档ID。向量存储库常常会短暂保留孤立向量；复用ID会造成隐性混乱。使用UUID或基于哈希的ID。
• 更换embedding模型需要重新embedding： 每种架构在你更换embedding模型时都要求完全重新索引。在索引10000个文档之前，选一个至少能坚持一年不变的embedder。
• 删除： ChromaDB和Qdrant支持按ID逐点删除。LanceDB需要一次压缩（compaction）才能回收磁盘空间——如果你每月删除超过约5%的语料库，建议每周排一次压缩任务。

大规模RAG质量监控

• 建立一个小型黄金集合： 30-50条你已知正确答案的查询，来自真实使用场景。涵盖事实检索（5-10条）、综合类（5-10条）、跨文档（5-10条）、边界情况（5-10条），以及答案不在语料库中的已知漏检查询（5-10条）。
• 为每条查询追踪三个指标： 检索召回率（正确的chunk是否出现在top-K中？）、生成忠实度（答案是否与chunk内容相符？）、拒答率（对已知漏检查询，系统是否正确回答"语料库中没有"？）。
• 在每次有意义的改动后重新运行： 新的导入批次、更换embedding模型、调整chunk大小、修改提示词。将结果与上一次运行做差异对比，标记出检索召回率或答案发生变化的查询。
• Trulens或RAGAS可用于自动化评估框架，两者都能本地运行并与LlamaIndex集成。人工评估30-50条查询同样可行，往往还更准确。
• 延迟预算： 持续追踪p50和p95查询延迟。p95跳升50%通常意味着索引超出了RAM——这是需要升级到下一档架构的早期信号。

常见问题

延伸阅读

• AnythingLLM vs PrivateGPT vs Open WebUI：2026年本地RAG选型 — 在扩展之前，先了解如何选择桌面端RAG平台的基础背景。
• 2026年本地RAG最佳Embedding模型 — 在索引10000个文档之前，embedder的选择是最关键的一步决策。
• 面向私有企业数据的本地RAG — 当个人规模的RAG遇上企业合规要求时的自然升级路径。
• 30分钟在你的PDF上搭建本地RAG（Ollama + AnythingLLM） — 触及扩展悬崖之前的入门级搭建方案。
• RAG详解：如何让AI答案扎根于真实数据（2026） — 关于RAG本质及各个检索组件为何重要的概念性权威解读。
• 2026本地LLM硬件指南 — 面向10000+文档语料库的硬件选型参考。
• 本地强力LLM中心 — 该系列的完整指南库。