**Meta Description**: RAG系统好不好用，80%取决于数据清洗。本文拆解真实项目中从1TB混合文档构建RAG的完整流程：文件过滤、智能分块、嵌入优化、检索调优，附可复用的代码模板。
—
做RAG系统的人，一开始都会被炫酷的对话界面吸引。自然语言提问，AI秒回，还带引用——看起来多美好。
但真正上手过的人都知道，RAG的难点从来不在LLM和向量数据库的集成上。那部分代码写起来不到100行。真正让人头疼的，是数据本身。
## 问题在哪：文档的”原始状态”
假设你拿到一个项目文件夹，里面是这样的：
– 上千份PDF，有些扫描版，有些文字版
– 大量Office文档（.docx、.pptx、.xlsx）
– 视频文件、模拟结果文件、备份文件
– CSV数据导出、日志文件、配置文件
– 还有一些你认不出格式的遗留系统文件
总大小：**1TB以上**。
这不是假设，这是[HackerNews上最近一个热帖（322分）的真实场景](https://en.andros.dev/blog/aa31d744/from-zero-to-a-rag-system-successes-and-failures/)。该团队为一家工程公司构建内部RAG工具，索引覆盖了公司近十年的所有项目文档。结果第一步就跑崩了——LlamaIndex试图把几GB的视频文件当作文本加载进内存。
**核心教训：向量数据库不管多强，也拯救不了垃圾输入。**
## 第一步：文件过滤——不是所有文件都需要索引
这是最容易忽略、也最重要的一步。直接把整个文件夹扔给LlamaIndex或LangChain，它会试图处理所有文件。
典型的过滤策略：
“`
排除清单：
– 视频/音频：mp4, avi, mov, mkv, wmv, flv, webm
– 图片（非OCR场景）：jpg, jpeg, png, gif, bmp
– 二进制/模拟数据：.sim, .dll, .exe, .zip, .tar
– 系统文件：.tmp, .log, .bak, .swp
– 大型CSV（非文本数据）：有时CSV里全是传感器读数，对RAG毫无意义
“`
参考上述案例，他们通过扩展名过滤排除了约40%的文件体积。这一步不能少。
**代码模板（Python）：**
“`python
EXCLUDED_EXTENSIONS = {
‘.mp4’, ‘.avi’, ‘.mov’, ‘.mkv’, ‘.wmv’, ‘.flv’, ‘.webm’,
‘.mpg’, ‘.mpeg’, ‘.3gp’, ‘.mts’,
‘.jpg’, ‘.jpeg’, ‘.png’, ‘.gif’, ‘.bmp’, ‘.tiff’,
‘.exe’, ‘.dll’, ‘.so’, ‘.dylib’,
‘.zip’, ‘.tar’, ‘.gz’, ‘.7z’, ‘.rar’,
‘.tmp’, ‘.log’, ‘.bak’, ‘.swp’, ‘.DS_Store’
}
def is_indexable(file_path):
ext = os.path.splitext(file_path)[1].lower()
return ext not in EXCLUDED_EXTENSIONS
“`
## 第二步：智能分块——不要用固定长度切文档
很多入门教程教你的分块方式是这样的：
“`python
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
“`
对于一篇技术文档，这基本上是灾难。关键内容可能在1020字符处被拦腰切断。
更好的做法是基于文档结构分块：
1. **Markdown/HTML文档**：按标题层级切（# → ## → ###）
2. **PDF**：按段落边界切，优先用章节标题
3. **代码文档**：按函数/类定义切
4. **表格数据**：整表作为一个chunk，不要拆
在LlamaIndex中可以用 `SemanticSplitterNodeParser` 或 `HierarchicalNodeParser`，它们会根据内容语义决定分块边界，而不是机械地数字符。
据该案例团队的分享，切换到语义分块后，检索准确率从62%提升到了83%。
## 第三步：嵌入模型选型——不是越大越好
选择嵌入模型时，几个关键指标：
– **维度**：384维（如all-MiniLM-L6-v2）vs 768维（如nomic-embed-text）vs 1536维（如OpenAI text-embedding-3-small）
– **语言支持**：中文文档优先选 multilingual 模型
– **token限制**：长文档需要支持512+ token窗口
– **延迟**：本地部署时，维度越低推理越快
该案例选用了 `nomic-embed-text`（768维），理由是”在技术文档上的表现和成本之间取得了平衡”。据其公开数据，处理451GB有效文档后，平均查询响应时间控制在2-3秒内。
## 第四步：检索优化——纯向量检索不够
纯向量检索的问题在于：它只知道”语义上相似”，但不知道”这个数字是2024年的还是2023年的”。
**混合检索方案**：
“`
向量检索（语义相似度） + 关键词检索（BM25） + 元数据过滤
“`
比如查询”2024年Q3的项目预算”，混合检索会：
1. 向量搜索找到”预算””项目”相关文档
2. BM25确保”2024″和”Q3″精确匹配
3. 元数据过滤只返回日期字段在2024年7-9月的文档
实现方式参考：
“`python
from llama_index.core.retrievers import VectorIndexRetriever
from llama_index.core.retrievers import KeywordTableSimpleRetriever
from llama_index.core.query_engine import RetrieverQueryEngine
# 混合检索
vector_retriever = VectorIndexRetriever(index=index, similarity_top_k=3)
keyword_retriever = KeywordTableSimpleRetriever(index=index)
# 融合结果
from llama_index.core.retrievers import FusionRetriever
retriever = FusionRetriever(
retrievers=[vector_retriever, keyword_retriever],
mode=”reciprocal_rerank” # RRF融合排序
)
“`
[据相关研究](https://jxnl.co/writing/2024/01/07/inverted-thinking-rag/)，纯向量检索的top-5准确率约75%，而混合检索可以提升到90%以上。
## 第五步：生产环境的成本考量
最后，别忘了算账。该案例中，索引451GB文档的算力成本是184欧元（Hetzner云服务器）。看起来不便宜，但考虑到内容是全公司的历史文档，这个投入在检索效率提升面前是划算的。
几个省钱技巧：
– **用批处理嵌入**：不要逐条处理，积攒一批再调用
– **分级存储**：热数据（高频查询）用高精度嵌入，冷数据用低维度嵌入
– **增量索引**：只有新文档才需要索引，不要全量重建
## 总结
RAG系统80%的工作量在数据工程上，而不是AI。如果你的RAG效果不好，先别调prompt，去看看数据：
1. 过滤掉不该索引的文件
2. 按文档结构分块，而不是按字符数
3. 选对嵌入模型（技术文档优先考虑 nomic-embed-text 或 multilingual 模型）
4. 向量+关键词混合检索
5. 关注成本，别让索引费用吃掉你的预算
参考来源：
– [From zero to a RAG system: successes and failures](https://en.andros.dev/blog/aa31d744/from-zero-to-a-rag-system-successes-and-failures/) — HN 322 points
– [How to build a terrible RAG system](https://jxnl.co/writing/2024/01/07/inverted-thinking-rag/) — Jason Liu
– [Ragas: Open-source evaluation for RAG](https://github.com/explodinggradients/ragas)
