RAG系统架构设计实践：从零搭建可追溯的领域知识库

为什么需要RAG？

大语言模型虽然强大，但存在几个关键问题：

知识截止：训练数据有时间限制，无法获取最新信息
幻觉问题：可能生成看似合理但实际错误的内容
领域缺失：垂直领域知识覆盖不足
不可追溯：无法告诉用户答案来自哪里

RAG（Retrieval-Augmented Generation）通过"先检索、再生成"的方式解决这些问题。

FitAtlas：一个真实的RAG实践

FitAtlas是一个健身领域的可追溯知识库，它的核心目标是：

导入抖音、小红书、书籍等合规整理的健身知识
保留完整的来源信息（作者、平台、链接、页码）
通过混合检索找到最相关的知识片段
让LLM基于检索结果生成有据可查的回答

系统架构总览

text

┌─────────────────────────────────────────────────────────┐
│                    React 工作台                          │
│              (问答 / 检索调试 / 素材导入)                  │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│                    FastAPI 服务                          │
│         (API / 入库调度 / 检索编排 / 提示词)               │
└─────────────────────────────────────────────────────────┘
                    │              │
                    ▼              ▼
        ┌───────────────┐  ┌──────────────────┐
        │  PostgreSQL    │  │  Embedding 服务   │
        │  + pgvector    │  │  (BGE-M3 TEI)    │
        │  + 全文索引     │  │                  │
        └───────────────┘  └──────────────────┘

关键设计决策

1. 为什么选择PostgreSQL而不是专用向量数据库？

事务一致性：向量和业务数据在同一个事务中更新
运维简单：只需要维护一个数据库
混合检索：pgvector + PostgreSQL全文检索原生集成
足够用：对于100-1000篇素材的规模，pgvector完全够用

2. 为什么向量存储在chunk而不是document？

text

❌ 整篇文档一个向量
   → 只能找到"胸部训练"整篇文档
   → 无法精确定位"上斜卧推角度"

✅ 每个chunk一个向量
   → 查询向量与每个chunk向量比较
   → 找到包含具体答案的片段

文档处理流水线

一份素材从上传到可检索，经历以下阶段：

text

上传文件 → 校验去重 → 保存原始素材
    ↓
提取文本 → 清洗标准化 → 保存全文
    ↓
智能分块 → 保留标题路径 → 生成chunk列表
    ↓
向量生成 → BGE-M3编码 → 归一化1024维向量
    ↓
索引写入 → 向量索引 + 关键词索引 → 原子提交
    ↓
发布成功 → 可参与检索

核心表关系

text

sources (素材来源)
    ↓ 一对多
documents (完整文档)
    ↓ 一对多
chunks (知识片段)
    ├── content: 提供给LLM的原始证据
    ├── embedding: 语义检索向量
    ├── search_vector: 关键词检索索引
    └── heading_path/page_number: 引用定位

原子发布保证

系统使用事务保证数据一致性：

删除该文档已有的旧chunks
写入新的chunks、向量和关键词索引
更新文档状态为published
整个过程在同一个事务中完成

结果：Embedding失败不会发布半成品向量，进程重启后任务可恢复。

混合检索策略

单一检索方式都有局限：

方式	优点	缺点
向量检索	理解语义相似性	可能忽略精确关键词
关键词检索	精确匹配术语	无法理解同义词

FitAtlas采用两路检索 + RRF融合：

text

用户问题
    │
    ├──→ BGE-M3查询向量 ──→ pgvector余弦相似度 Top 20
    │
    └──→ jieba分词 ──→ PostgreSQL全文检索 Top 20
                            │
                            ▼
                    RRF排名融合
                            │
                            ▼
                    最终 Top 8 片段

RRF算法

Reciprocal Rank Fusion只使用排名，不混合不同量纲的原始分数：

text

RRF分数 = 1/(60 + 向量排名) + 1/(60 + 关键词排名)

名次数字越小，贡献越大。两路排名都高的片段会排在最前面。

可追溯性设计

每个检索结果都包含完整的引用信息：

json

{
  "chunk_id": "...",
  "document_id": "...",
  "title": "胸部训练完整指南",
  "platform": "小红书",
  "author": "健身达人",
  "original_url": "https://...",
  "heading_path": ["卧推动作流程", "握距"],
  "page_number": null
}

LLM生成回答时必须使用 [S1]、[S2] 引用标记，用户可以追溯每个论断的来源。

经验总结

先保证检索质量，再优化生成：如果检索没有召回正确证据，LLM无法凭空创造
混合检索是必要的：向量检索和关键词检索互补，RRF是简单有效的融合方案
事务一致性很重要：向量和业务数据必须在同一个事务中更新
可追溯性是RAG的核心价值：用户需要知道答案来自哪里
从小规模开始验证：先用PostgreSQL pgvector，需要时再考虑专用向量数据库

下一步

本文基于FitAtlas健身知识库的实践经验。FitAtlas使用BGE-M3 + PostgreSQL pgvector构建可追溯的RAG系统。