企业级 RAG 知识库实战：文档解析、向量库、权限和评测怎么做

企业 RAG 的重点不是接个大模型，而是文档解析、权限过滤、混合检索、评测和治理。

这类问题为什么值得单独写

企业级 RAG 知识库实战：文档解析、向量库、权限和评测怎么做 不是一个单点技巧，而是一组工程取舍。生产环境里，真正困难的不是把 demo 跑通，而是当数据量、并发、权限、历史包袱和多人协作都出现时，系统还能稳定运行。

围绕 RAG、向量库、权限，要同时考虑业务口径、存储模型、计算成本、失败恢复和可观测性。只看某一个参数，往往会把问题从一个组件转移到另一个组件。

核心概念拆解

第一层是数据模型：字段怎么定义、主键是什么、时间字段用哪个、是否允许迟到和修正。第二层是计算模型：批处理、流处理、增量处理还是查询时计算。第三层是服务模型：报表查询、接口查询、离线导出、AI 检索使用的是不是同一套口径。

常用检查方式

-- 行数和主键去重
SELECT count(*) AS rows, count(distinct id) AS ids
FROM target_table
WHERE dt='${bizdate}';

-- 分区数据波动
SELECT dt, count(*) cnt
FROM target_table
WHERE dt >= date_sub('${bizdate}', 7)
GROUP BY dt
ORDER BY dt;

-- 核心金额对账
SELECT sum(amount), count(distinct user_id)
FROM target_table
WHERE dt='${bizdate}';

生产落地建议

• 先把核心链路跑稳，再扩展边缘场景。
• 所有关键表、任务、指标都要有 owner 和变更记录。
• 上线前必须有小流量验证、历史分区验证和回滚方案。
• 监控不要只看任务失败，还要看数据量、延迟、重复率和空值率。

常见误区

第一个误区是只追新技术，不解决数据口径和质量。第二个误区是把所有逻辑堆到一层，导致后面无法复用。第三个误区是没有补偿链路，一旦出现脏数据只能手工修。第四个误区是没有评测和对账，系统看似正常，结果已经偏了好几天。

上线检查清单

• 输入数据是否可追溯，是否有源头对账。
• 输出结果是否幂等，重跑会不会重复。
• 异常数据是否有旁路表，不要静默丢弃。
• 核心指标是否接入告警，是否能定位到负责人。

Chunk 规则比 Prompt 更重要

企业 RAG 里，回答不准往往不是模型不行，而是 chunk 切坏了。制度文档适合按标题层级切，接口文档适合按接口切，表格要保留表头和行列关系。页眉页脚、目录、版权声明这类噪声要清理，否则会被反复召回。

chunk_size: 600~1000 中文字符
chunk_overlap: 80~150
metadata: doc_id, title_path, page, department_acl, updated_at

权限过滤必须发生在召回前。先召回再让模型判断权限是不安全的，因为敏感片段已经进入上下文。多租户场景建议把 tenant_id、dept_id、security_level 都写入 metadata，并参与索引过滤压测。

线上问题怎么定位

用户说“答非所问”时，先保存 query、召回 TopK、rerank 分数、最终 prompt、模型答案和引用。只有这些链路日志完整，才能判断是解析问题、召回问题、重排问题还是生成问题。

生产环境可以直接套用的总结

如果把这篇内容落到真实项目里，建议至少补齐三类信息：第一是基线数据，包括日均数据量、峰值 QPS、任务耗时、存储大小和失败频率；第二是关键配置，包括并行度、分区数、TTL、超时时间、批大小、索引字段；第三是验证结果，包括上线前后耗时对比、资源消耗对比、核心指标对账和异常回滚记录。

写技术博客时也可以按这个顺序组织：先讲业务背景，再讲为什么原方案不稳，然后贴出关键配置或 SQL，最后用对比数据说明优化是否有效。这样文章不会空，也不会像模板填空。

延伸阅读和落地建议

本文按公开技术资料和生产经验重新整理，没有复制原文。真正落地到你的环境时，建议补充：集群版本、资源规格、任务截图、SQL 执行计划、核心监控曲线、上线前后对比数据。这样文章会更像真实生产复盘，也更适合长期维护。