Multi-Model Knowledge Q&A Router：面向多模型与文档知识库的智能问答系统

这是一个面向企业知识库场景的全栈智能问答项目。项目支持将 Markdown、PDF、Word、Excel 等文档转换并管理为知识内容，通过 LLM 问答匹配与 RAG 检索两条链路，为用户返回可追溯的知识库答案。

项目的核心目标是解决“企业文档多、知识分散、传统关键词检索命中率有限、不同模型能力和成本难以平衡”的问题。我将前端管理、模型配置、文档处理、知识库管理、向量检索和服务部署整合为一个可本地运行的系统。

项目架构

前端：React 18 + TypeScript + Vite，提供知识库管理、文件管理、模型设置、问答调试、日志与召回测试等页面。
后端：Node.js + Express，提供 REST API 与 SSE 流式接口，负责知识库 CRUD、模型调用、文件处理和 RAG 检索编排。
数据库：PostgreSQL 16，存储知识库、FAQ、模型配置、提示词、日志、召回测试和 RAG 元数据。
模型服务：通过 OpenAI 兼容接口接入硅基流动，当前使用 Qwen/Qwen3-8B 进行问答匹配与内容生成。
RAG：支持 Embedding、Rerank、向量检索与关键词检索融合；可连接 Weaviate，也支持本地内存检索回退。
部署：PostgreSQL 使用 Docker 容器与持久化 Volume 部署，应用通过环境变量管理模型与数据库配置。

核心功能

1. 知识库与 FAQ 管理

支持创建、重命名、删除多个知识库。
知识库中的问答数据存储在 PostgreSQL 中，避免 JSON 文件在并发、检索和扩展上的限制。
支持 FAQ 问题、答案、相似问法、启用状态等结构化管理。
支持将 RAG 知识库中的问答内容导入到传统 FAQ 问答链路中。

2. 多模型配置与路由

项目将模型能力按不同业务场景拆分为多个槽位，而不是将模型调用写死在代码中：

问答模型：用于根据用户问题匹配最合适的 FAQ。
FAQ 生成模型：用于根据文档内容自动生成标准问题和相似问法。
PDF/VLM 模型：用于复杂文档提取与内容精修。
RAG 模型：分别配置 Embedding、Rerank 和最终回答模型。

模型地址、Key、模型名称、最大 Token、温度等参数均可以在设置页调整，并持久化到数据库中。这样可以快速切换 OpenAI 兼容模型服务，降低模型替换成本。

3. 流式问答与置信度匹配

问答接口使用 SSE（Server-Sent Events）向前端实时推送执行过程，包括候选问题、匹配日志、模型输出和最终答案。相比一次性等待完整响应，流式输出可以明显改善用户的等待体验，也便于定位模型调用和匹配流程中的问题。

POST /ask/confidence/stream

请求内容：
{
  "question": "用户的问题",
  "kb_id": "知识库 ID",
  "top_k": 5
}

流式事件：
log → candidates → done / error

4. RAG 检索增强生成

针对长文档和复杂知识内容，项目实现了 RAG 检索链路：

将知识内容转换为可检索文本块。
使用 Embedding 模型生成向量。
结合向量检索和关键词检索获取候选内容。
使用 Rerank 模型对候选结果重新排序。
将高相关内容作为上下文交给大模型生成最终回答。

系统支持 Weaviate 向量数据库，也实现了本地内存检索回退机制，便于在没有额外向量数据库基础设施时快速开发和调试。

5. 多格式文档处理

支持 Markdown、TXT、HTML、PDF、Word、Excel、CSV 等文件。
支持文档上传、预览、编辑、拆分和转 Markdown。
PDF 内容提取可结合 Python 脚本和视觉语言模型进行精修。
文档中的图片资源会同步到统一资源目录，避免知识库答案中的图片路径失效。

技术难点与解决方案

难点 1：传统 FAQ 匹配与 RAG 检索如何共存

传统 FAQ 适合固定、高频、答案明确的问题；RAG 更适合长文档、开放式问题和复杂上下文。因此项目没有只采用单一问答模式，而是同时保留 FAQ 问答链路和 RAG 链路。前者强调低延迟和稳定性，后者强调知识覆盖范围与语义检索能力。

难点 2：模型服务的可替换性

不同模型供应商的 API 地址、模型名称、思维链参数和 Token 参数存在差异。项目通过统一的 OpenAI 兼容客户端封装模型调用，并将模型配置抽离到数据库与环境变量中，使系统能够快速接入硅基流动、OpenAI 兼容服务或本地 Ollama 模型。

难点 3：从文件型数据迁移到 PostgreSQL

早期版本使用 JSON 文件保存知识库、日志和配置，存在数据一致性差、难以查询、难以扩展的问题。新版将结构化数据迁移到 PostgreSQL，并通过 SQL Migration 管理表结构版本。文件本身仍保留在磁盘中，数据库只保存结构化元数据和业务数据。

难点 4：本地部署体验

项目使用 Docker 部署 PostgreSQL 16，并挂载持久化 Volume，避免本机安装数据库服务和手动管理数据目录。应用启动时自动执行数据库迁移，确保代码版本与数据库表结构保持一致。

docker run -d ^
  --name router-postgres ^
  --restart unless-stopped ^
  -e POSTGRES_DB=router ^
  -e POSTGRES_USER=postgres ^
  -e POSTGRES_PASSWORD=YOUR_PASSWORD ^
  -p 127.0.0.1:5432:5432 ^
  -v router-postgres-data:/var/lib/postgresql/data ^
  postgres:16

项目技术栈

Frontend：React 18、TypeScript、Vite、TanStack Query
Backend：Node.js、Express、SSE、Multer
Database：PostgreSQL 16、node-postgres、SQL Migration
LLM：Qwen/Qwen3-8B、OpenAI Compatible API、硅基流动
RAG：Embedding、Rerank、Hybrid Search、Weaviate
Document Processing：PDF、Word、Excel、Markdown、Python
Engineering：Docker、dotenv、Vitest、npm Workspaces

项目成果

完成从文件型知识库到 PostgreSQL 结构化存储的迁移。
实现 FAQ 匹配与 RAG 检索双链路问答架构。
实现多模型配置、流式输出、文档解析和知识库管理能力。
完成 Docker 化 PostgreSQL 部署，并验证前后端、数据库和真实大模型推理链路可用。
通过模块化设计降低模型供应商、向量数据库和部署环境的替换成本。

项目界面

问答界面

问题管理：

文件管理：