✅派聪明 RAG 系统的接口文档

一、用户管理模块

01、用户注册接口

URL: /api/v1/users/register
Method: POST
Request Body:

{
  "username": "string",   // 用户名，唯一
  "password": "string"    // 密码（明文传输，后端加密存储）
}

Response:

{
  "code": 200,// 成功
  "message": "User registered successfully"
}

{
  "code": 400, // 失败
  "message": "Username already exists"
}

02、用户登录接口

URL: /api/v1/users/login
Method: POST
Request Body:

{
  "username": "string",
  "password": "string"
}

Response:

{
  "code": 200,// 成功
  "message": "Login successful",
  "data": {
    "token": "JWT_TOKEN_STRING"
  }
}

{
  "code": 401, // 失败
  "message": "Invalid username or password"
}

03、获取用户信息接口

URL: /api/v1/users/me
Method: GET
Headers:
- Authorization: Bearer JWT_TOKEN_STRING
Response:

{
  "code": 200,// 成功
  "message": "Success",
  "data": {
    "id": 1,
    "username": "example_user",
    "role": "USER",
    "orgTags": ["dept1", "team2"],
    "primaryOrg": "dept1"
  }
}

{
  "code": 401, // 失败
  "message": "Unauthorized"
}

04、组织标签管理接口

①、创建组织标签（管理员）

URL: /api/v1/admin/org-tags
Method: POST
Headers: ...

15人已点赞

热门评论

清清 2026年03月15日 10:00

@派聪明文档删除和文件删除有什么区别

回复1 取消回复

派聪明 2026年03月15日 10:01

根据提供的参考资料，**文档删除**和**文件删除**在功能定位和实现上存在本质区别： ### 1. **文件删除（物理删除）** - **接口位置**：文件上传与处理模块 - URL: `/api/v1/documents/{file_md5}` - Method: `DELETE` - **功能**：彻底删除存储系统（如MinIO）中的原始文件，释放物理存储空间。 - **适用场景**：当用户需要从服务器**永久移除文件**时使用。 - **响应示例**： ```json { "status": "success", "message": "文档删除成功" } { "status": "error", "message": "文档不存在" } ``` ### 2. **文档删除（逻辑删除）** - **接口位置**：知识库检索模块 - URL: `/api/documents/{file_md5}` - Method: `DELETE` - **功能**：仅删除知识库中的**索引记录**，文件本身仍保留在存储系统中，但无法通过检索接口（如`/api/search/hybrid`）被查询到。 - **适用场景**：当用户需要**移除文件在知识库中的可见性**（如敏感内容处理），但保留原始文件时使用。 - **响应示例**： ```json { "status": "success", "message": "文档删除成功" } { "status": "error", "message": "没有权限删除此文档" } ``` ### 核心区别总结 | **维度** | **文件删除** | **文档删除** | |----------------|----------------------------------|----------------------------------| | **操作对象** | 物理存储的文件（如MinIO） | 知识库索引记录 | | **影响范围** | 彻底移除文件，释放存储空间 | 仅移除检索索引，文件仍存在 | | **接口路径** | `/api/v1/documents/{file_md5}` | `/api/documents/{file_md5}` | | **模块归属** | 文件上传与处理模块 | 知识库检索模块 | ### 使用建议 - 若需**永久删除文件**（如清理存储），使用文件删除接口。 - 若需**隐藏文件在知识库中的可见性**（如权限管理），使用文档删除接口。

回复取消回复

8 条评论

walter 2026年06月10日 11:53

@派聪明为什么聊天对话数据不持久化存储

派聪明 2026年06月10日 11:54

根据您提供的参考资料，接口文档中**并没有说明“聊天对话数据不持久化存储”**。相反，从资料的设计来看，聊天记录实际上是**进行了持久化存储**的。原因和依据如下： 1. **支持获取历史记录**：资料中提供了一个 `GET /api/conversation/history`接口，可以通过 `userId`获取当前会话的对话历史（包含完整的用户提问和AI回答）。这表明数据在服务端被保存了下来，否则无法通过接口查询。 2. **支持多会话管理**：系统提供了 `POST /api/conversation/create`接口，用于为用户生成唯一的 `conversationId`（如 abcdef123456）并建立关联。这种独立会话ID的生成与绑定机制，是典型的将对话持久化到数据库的设计模式。因此，基于现有参考资料，系统具备聊天数据持久化存储的能力。

在您提供的参考资料中，并未直接说明聊天对话数据不进行持久化存储的原因。但从API设计逻辑和技术应用场景推测，主要有以下几个原因： 1. **内存级RAG上下文机制**：该系统是一个“RAG私有知识库”，聊天助手（WebSocket）的核心是接收提问并在检索后“逐段返回”实时回答。这种对话多侧重于即时交互，主要用于提供实时的上下文连贯性，而不一定需要作为永久数据保留。 2. **接口设计的特定定位**：资料中的“获取聊天历史”接口（`/api/conversation/history`）实际上**已经提供了对话数据的持久化与查询功能**（通过 `userId` 关联获取当前会话的 `messages`记录）。如果某些场景下感觉数据未被持久化，可能是因为系统采取了**定期自动清理、覆盖或仅做短期临时存储**的策略，以节省服务器存储资源。 3. **隐私与数据安全**：系统主打“私有化”部署与私有组织架构（如各个部门、团队的私有空间），为保障企业用户的数据隐私，系统可能会默认对聊天记录采取阅后即焚或按需存储策略，避免敏感的问答记录被长期留存。

根据提供的参考资料，系统中其实是存在持久化存储机制的。如果您感觉数据未持久化，通常是由以下几个原因或机制设计导致的： **1.依赖前端主动传递会话ID** 在 WebSocket聊天接口中，`conversationId`（如 `abcdef123456`）被设定为**“可选”**参数。如果客户端在发送消息时没有携带该参数，系统可能会将其视为临时会话，仅使用当前会话的状态而不进行持久化落盘。只有在传递了有效的 `conversationId` 时，聊天记录才会被关联并保存。 **2.需通过专门接口触发历史记录获取** 资料中设计了专门的 `/api/conversation/history`（GET请求）来根据 `userId`获取对话历史。这意味着聊天记录的持久化依赖于后端对会话ID的有效管理。如果未通过“创建聊天接口”(`/api/conversation/create`) 成功生成并关联 `conversationId`，历史数据将无法被正确检索。 **3.系统层面的可能原因** * **测试环境设定**：当前的系统可能处于开发或测试阶段，仅开启了内存级别的临时存储。 * **用户状态失效**：聊天历史接口依赖 `userId`，如果鉴权失效或传参错误，也会导致看起来没有历史记录被持久化保存。总结来说，系统架构上是支持聊天记录持久化并回溯查询的，核心关键在于**必须确保客户端建立连接后成功创建了 `conversationId`，并在每次发送消息时正确携带该 ID 和用户信息**，系统才会将其完整持久化并允许通过历史接口调用。