SpecRAG 是一个面向 PRD、业务规则、流程制度、SOP、产品截图和其他业务文档的知识库导入与问答测试服务。
核心目标不是生成给人阅读的最终文档，而是把图片或文本业务文档转成可检索、可引用、可被 LLM 严格基于证据回答的知识库数据。
图片 / PRD / 业务文档
-> 知识库源文档
-> 知识单元清洗
-> query_hints 生成
-> 向量化入库
-> MCP Agent 检索、判断、整合答案
用户上传多张需求截图、产品设计截图或业务流程截图。系统先调用视觉模型分析图片，再由图片整合 Agent 生成“知识库源文档”。
保留这个中间文档的原因是：多张图片之间通常存在上下文关系，直接让清洗 Agent 从图片产出结构化 unit，容易丢失跨图关系。先生成源文档，可以把多图信息整合成一份连续文本，再交给清洗 Agent 拆分。
用户可以直接上传 Markdown 或纯文本业务文档，例如 PRD、业务规则、流程制度、SOP、操作手册、接口说明等。系统会做窄清理，只移除模型包裹、历史噪声块等非源文档内容，不改写业务事实。
知识单元是知识库的核心事实粒度。
一个 unit 应该表达一个相对完整的业务规则、功能动作、异常处理、权限规则、数据规则、操作步骤或流程片段。它需要能独立支持一次问答召回。
当前 schema 保留这些字段：
{
"unit_id": "RU-001",
"title": "短标题",
"unit_type": "feature",
"content": "完整需求说明",
"rules": ["规则1", "规则2"],
"source": {
"heading_path": ["章节路径"],
"start_line": 1,
"end_line": 10
},
"retrieval_meta": {
"query_hints": ["用户可能问法"],
"key_terms": ["原文关键证据词"]
}
}content 和 rules 是回答事实来源。query_hints 只用于增强召回，不能作为回答事实。
每个 unit 不只生成一条向量。当前会基于不同用途生成多类向量文本：
body：由标题、正文、规则和章节组成，负责基础语义召回。agent_hint_bundle：由 query_hints 和 key_terms 组成，负责匹配常见用户问法。feedback_hint：由用户后续反馈沉淀的新问法生成，负责持续优化召回。
这样做的原因是业务文档原文和用户问法经常不一致。只向量化原文，容易召回相近但不能回答的 unit；只向量化问法，又会丢失事实证据。多向量可以同时兼顾事实文本和用户表达。
问答测试走 MCP Agent 编排：
search_units：根据问题召回候选 unit。expand_search：问题较宽或首轮证据不足时扩大召回。get_unit：读取完整 unit 内容。judge_answerability：判断证据是否足以回答。synthesize_answer：把多个支持 unit 整合成自然语言答案。
Agent 不能直接回答业务问题，必须先调用 MCP 工具。证据不足时必须返回 no-answer，不能根据相近内容推断。
默认模式使用 PostgreSQL + Qdrant：
- PostgreSQL 保存事实数据：文档、知识单元、版本、来源、反馈问法和向量记录元数据。
- Qdrant 保存向量索引：负责高性能语义召回。
Qdrant 找到候选后，系统仍会回 PostgreSQL 读取完整 unit，再交给 LLM 判断和回答。Qdrant 不是事实主库。
SQLite 模式需要显式设置 KB_STORAGE_MODE=sqlite。它会在单个 SQLite 文件中保存文档、unit 和向量，适合开发、本地验证和小规模 demo，不作为默认生产形态。
开源版保留：
- 图片需求/流程截图导入。
- 文本业务文档导入。
- 知识单元清洗。
- query_hints 生成。
- PostgreSQL + Qdrant 企业存储适配。
- SQLite 本地知识库适配。
- MCP Agent 问答测试页面。
开源版不包含：
- 历史业务数据。
- 本地 API Key。
- 运行时产物。
- 与知识库导入、检索、问答无关的业务链路。