Meta Description: RAG系统好不好用，80%取决于数据清洗。本文拆解真实项目中从1TB混合文档构建RAG的完整流程：文件过滤、智能分块、嵌入优化、检索调优，附可复用的代码模板。
做RAG系统的人，一开始都会被炫酷的对话界面吸引。自然语言提问，AI秒回，还带引用——看起来多美好。
但真正上手过的人都知道，RAG的难点从来不在LLM和向量数据库的集成上。那部分代码写起来不到100行。真正让人头疼的，是数据本身。
问题在哪：文档的”原始状态”
假设你拿到一个项目文件夹，里面是这样的：
- 上千份PDF，有些扫描版，有些文字版
- 大量Office文档（.docx、.pptx、.xlsx）
- 视频文件、模拟结果文件、备份文件
- CSV数据导出、日志文件、配置文件
- 还有一些你认不出格式的遗留系统文件
总大小：1TB以上。
这不是假设，这是HackerNews上最近一个热帖（322分）的真实场景。该团队为一家工程公司构建内部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字符处被拦腰切断。
更好的做法是基于文档结构分块：
- Markdown/HTML文档：按标题层级切（# → ## → ###）
- PDF：按段落边界切，优先用章节标题
- 代码文档：按函数/类定义切
- 表格数据：整表作为一个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的项目预算”，混合检索会：
- 向量搜索找到”预算””项目”相关文档
- BM25确保”2024″和”Q3″精确匹配
- 元数据过滤只返回日期字段在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融合排序
)
“`
据相关研究，纯向量检索的top-5准确率约75%，而混合检索可以提升到90%以上。
第五步：生产环境的成本考量
最后，别忘了算账。该案例中，索引451GB文档的算力成本是184欧元（Hetzner云服务器）。看起来不便宜，但考虑到内容是全公司的历史文档，这个投入在检索效率提升面前是划算的。
几个省钱技巧：
- 用批处理嵌入：不要逐条处理，积攒一批再调用
- 分级存储：热数据（高频查询）用高精度嵌入，冷数据用低维度嵌入
- 增量索引：只有新文档才需要索引，不要全量重建
总结
RAG系统80%的工作量在数据工程上，而不是AI。如果你的RAG效果不好，先别调prompt，去看看数据：
- 过滤掉不该索引的文件
- 按文档结构分块，而不是按字符数
- 选对嵌入模型（技术文档优先考虑 nomic-embed-text 或 multilingual 模型）
- 向量+关键词混合检索
- 关注成本，别让索引费用吃掉你的预算
参考来源：
- From zero to a RAG system: successes and failures — HN 322 points
- How to build a terrible RAG system — Jason Liu
