wanghanlin/RAG: 本地 RAG 知识库 - RAG - Gitea: Git with a cup of tea

本地 RAG 知识库

History

wanghanlin 2001dc3a0f fix(doc): 修复重新处理文档会按 2000 字截断预览重建导致内容丢失问题 - knowledge_document.content 上传时被截断到 2000 字符（有意的预览设计），但 reprocessDocument 把它当原文重建分块，而 DocumentProcessingService 以 cleanBeforeFirstAttempt=true 运行（先删光旧向量）——对超过 2000 字符的文档执行 POST /document/batch/reprocess 会永久丢失其余内容修复 - content 改存原文全文（列已是 TEXT，无需 DDL），并写 extra_config.contentComplete 作为完整性标记 - 实体 content 加 @JsonIgnore：全文任何接口都不返回（否则 GET /document/list 无字段投影，每行都会带上整篇正文）；文档详情接口单独组装响应，返回 2000 字预览（键名仍是 content）与 contentTruncated 标志，前端据此提示截断 - reprocessDocument 的数据源按优先级解析： 1) 有 contentComplete 标记 → 用库内全文（语义最忠实，JSON 的 fields/pointer 模式不受影响，也不依赖文件是否还在） 2) 历史遗留文档（无标记，content 是截断预览）→ 按 fileType 从原始文件重解析（md → MarkdownDocumentLoader，json → JsonDocumentLoader，其余 → Tika），成功后回填全文并打标记，此后不再依赖原始文件 3) 两者都不可用 → 明确报错拒绝，绝不静默按截断预览重建无法完整还原时在标记 PROCESSING 之前抛错，事务回滚，文档状态与已有向量都不受影响 - contentTruncated 判据覆盖历史数据：长度恰好等于上限且无 contentComplete 标记时同样判定为已截断，避免把截断预览误报成完整内容 - 同步 content 列注释（DatabaseInitConfig / init-database.sql / knowledge-base.sql），该注释会在下次启动幂等刷新到库验证（真实库 + 557 篇存量文档环境） - 上传 4891 字符正文：库内存全文，详情接口返回 2000 字预览 + contentTruncated=true - 重新处理：chunk_count 与首次完全一致（修复前会降为个位数），内容无丢失 - 模拟历史数据（截断 + 无标记）：有文件时从文件重解析成功并回填全文；文件也丢失时明确拒绝，且文档状态与 chunk_count 保持不变（向量未被破坏） - 回填后再删文件重跑仍成功（已自愈）；GET /document/list 不再含 content - RAG 对话回归正常已知降级 - JSON 的 basic/fields/pointer 解析模式上传时未持久化，历史 JSON 文档从文件重解析只能按 basic 还原（不丢数据，仅抽取口径可能变化，日志有 WARN） - 存量中疑似被截断的文档需重跑一次才能回填全文（均已保留原始文件，均可恢复）	2 days ago
..
config.test.ts	SDK 新增 6 项功能完善（类型导出/窗口配置/错误回调/测试/分组/通知）	3 months ago

wanghanlin 2001dc3a0f fix(doc): 修复重新处理文档会按 2000 字截断预览重建导致内容丢失

问题
- knowledge_document.content 上传时被截断到 2000 字符（有意的预览设计），
  但 reprocessDocument 把它当原文重建分块，而 DocumentProcessingService 以
  cleanBeforeFirstAttempt=true 运行（先删光旧向量）——对超过 2000 字符的文档
  执行 POST /document/batch/reprocess 会永久丢失其余内容

修复
- content 改存原文全文（列已是 TEXT，无需 DDL），并写 extra_config.contentComplete
  作为完整性标记
- 实体 content 加 @JsonIgnore：全文任何接口都不返回（否则 GET /document/list
  无字段投影，每行都会带上整篇正文）；文档详情接口单独组装响应，返回 2000 字预览
  （键名仍是 content）与 contentTruncated 标志，前端据此提示截断
- reprocessDocument 的数据源按优先级解析：
  1) 有 contentComplete 标记 → 用库内全文（语义最忠实，JSON 的 fields/pointer
     模式不受影响，也不依赖文件是否还在）
  2) 历史遗留文档（无标记，content 是截断预览）→ 按 fileType 从原始文件重解析
     （md → MarkdownDocumentLoader，json → JsonDocumentLoader，其余 → Tika），
     成功后回填全文并打标记，此后不再依赖原始文件
  3) 两者都不可用 → 明确报错拒绝，绝不静默按截断预览重建
  无法完整还原时在标记 PROCESSING 之前抛错，事务回滚，文档状态与已有向量都不受影响
- contentTruncated 判据覆盖历史数据：长度恰好等于上限且无 contentComplete 标记时
  同样判定为已截断，避免把截断预览误报成完整内容
- 同步 content 列注释（DatabaseInitConfig / init-database.sql / knowledge-base.sql），
  该注释会在下次启动幂等刷新到库

验证（真实库 + 557 篇存量文档环境）
- 上传 4891 字符正文：库内存全文，详情接口返回 2000 字预览 + contentTruncated=true
- 重新处理：chunk_count 与首次完全一致（修复前会降为个位数），内容无丢失
- 模拟历史数据（截断 + 无标记）：有文件时从文件重解析成功并回填全文；
  文件也丢失时明确拒绝，且文档状态与 chunk_count 保持不变（向量未被破坏）
- 回填后再删文件重跑仍成功（已自愈）；GET /document/list 不再含 content
- RAG 对话回归正常

已知降级
- JSON 的 basic/fields/pointer 解析模式上传时未持久化，历史 JSON 文档从文件重解析
  只能按 basic 还原（不丢数据，仅抽取口径可能变化，日志有 WARN）
- 存量中疑似被截断的文档需重跑一次才能回填全文（均已保留原始文件，均可恢复）

2 days ago

config.test.ts

SDK 新增 6 项功能完善（类型导出/窗口配置/错误回调/测试/分组/通知）

3 months ago