RAGFlow：平台知识库与自建 RAG 链路怎样选择

问题与目标

自建 RAG 可以逐项控制解析、切分、检索和评估，但工程成本不低。RAGFlow 把文档上传、解析、Chunk 管理、检索测试、模型配置和 API 集成集中在平台中，适合快速搭建与运营知识库。

本篇不把界面点击步骤当成核心知识，而是用同一批自创文档与问题比较平台链路和自建链路。RAGFlow 版本迭代较快，菜单、解析模板和 API 字段应以部署版本的官方文档为准；本篇不展开其 Agent 工作流。

核心概念

选择不是“低代码或代码谁更高级”，而是可控性、交付速度、团队能力和维护成本之间的取舍。

可运行验证

准备两份完全自创的 Markdown：

docs/duty.md      关键告警必须立即通知负责人。
docs/recovery.md  告警恢复后观察十分钟并记录处理人。

再准备固定问题表：

id,question,relevant_source,expected
q1,关键告警通知谁,duty.md,负责人
q2,恢复后观察多久,recovery.md,十分钟
q3,普通告警是否必须停机,,无法确认

在 RAGFlow 中完成以下闭环：

1. 创建知识库并记录平台版本、Embedding 与解析模板；
2. 上传两份文档，等待解析完成，抽查正文、标题和 Chunk；
3. 使用 Retrieval Testing 运行三条问题，保存 Top-k、分数和来源；
4. 调整 Chunk 大小、关键词权重或 Reranker 后重复测试；
5. 创建 API Key，以最小权限从测试脚本调用部署版本对应的检索或对话 API；
6. 记录延迟、拒答和引用结果，与自建 07.17 项目使用同一评估表比较。

API 调用不要硬编码未经核对的路径：

import os
import httpx

base = os.environ["RAGFLOW_BASE_URL"].rstrip("/")
api_key = os.environ["RAGFLOW_API_KEY"]

# endpoint 与 payload 请从当前部署版本的 HTTP API Reference 复制并校验。
response = httpx.post(
    f"{base}/<versioned-endpoint>",
    headers={"Authorization": f"Bearer {api_key}"},
    json={"question": "关键告警通知谁？"},
    timeout=30,
)
print(response.status_code, response.text[:500])

这个占位写法是有意的：平台 API 属于易变外部契约，文章不能用猜测路径制造“看似可运行”的错误示例。部署时把核对后的请求保存成独立集成测试。

常见问题与排查

上传成功就认为知识库可用

检查解析状态、空 Chunk、乱码、表格顺序、来源元数据和检索测试。上传只是文件进入平台，不代表答案可召回。

改参数后只问一个问题

用固定问题集比较 Recall、引用、拒答与延迟。保存配置快照，否则无法解释效果变化来自哪里。

平台默认权限等于业务权限

验证知识库、文档、租户和 API Key 的隔离能力。若不能满足细粒度权限，应在网关或自建检索层补充前置过滤。

为安装平台一次性加载大量未知镜像

按官方部署清单核对 CPU、内存、磁盘、镜像来源和版本，先在隔离环境验证备份、升级和恢复。不要把课程中的旧配置直接视为当前生产要求。

小结

RAGFlow 把知识库常用能力平台化，自建链路提供更深控制。最可靠的选择方法是让两者面对同一批文档、问题和指标，再比较质量、权限、成本与维护工作，而不是只看搭建速度或功能列表。