本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
最近在学习rag相关的知识，系统性的梳理了几篇文章，想着做个项目实践一下。正好在公司负责了一堆后台项目，就想着能不能搭个知识库平台，把这些后台系统的文档都作为一个知识库管理起来，省得每个项目查个什么东西还得去翻各种文档。过程中正好可以学习下rag相关的切分策略和检索召回逻辑。
所以，下面的这个项目就诞生了。
项目地址
项目定位
这个项目的愿景是可以用于企业内部自建知识库，但是企业内部的具体情况各不相同，所以这个项目主要做的事情就是以不同知识库管理各种文档，包括PDF，word，Excel，图片等。然后支持多种的切分策略，包括固定长度切分、按结构切分、表格感知切分、父子分层切分、语义切分、聊天记录切分。
重点讲讲聊天记录和表格切分。
聊天记录策略是专门为公司内部沟通场景做的，因为平时会经常和业务人员沟通各种功能和数据的修改和检查，有时候找问题就需要翻之前的聊天记录，就想着把这个也做成知识库，到时候都直接放到知识库里直接就搜出来了。
核心就是把聊天记录按话题切分，通过正则识别消息边界（说话人 + 时间戳），解析每条消息的发言者、时间、内容。
按时间间隔（默认 60 分钟）自动识别话题切换，同一个话题的消息尽量放在一个 chunk 里。
格式化后统一 embedding，保证检索时能按时间、参与者、话题精准命中。
表格切分就是专门处理 Excel、CSV 这类结构化表格文档。
这核心逻辑是按行分批切分：表格数据按 table_rows_per_chunk（默认 20 行）和 max_chars（默认 1200 字符）两个维度控制，哪个先触发就切一批。
每个 chunk 带表头：每批数据前面都会重复表头行，保证 chunk 独立可读，不用依赖上一个 chunk 的表头。
这里还特殊处理了一种FAQ类型的表格，而且有多级合并的情况。
如果检测到表头包含"一级/二级/三级(/四级)"这种层级分类字段，会走专门的 FAQ 渲染模式。
这个是按分类层级分组，同组的行尽量放在一个 chunk 里。渲染成 问题：xxx、一级分类：xxx、答案：xxx 的结构化文本，比原始表格更适合 LLM 理解和检索命中。
处理完每个chunk就类似下面这样：
后台管理页面
下面是项目后台管理页面的部分截图。
切分配置页面可以实施预览各种文档或者自定义文字，在不同切分策略下的效果。
项目里的文档上传和解析切分都归结为“任务”。任务都是异步处理
图片识别
图片的识别是用OCR和多模态大模型的混合方案。
OCR目前支持百度的paddleOCR（每天有2000的额度）。如果配置了多模态LLM ，会用LLM生成一个图片的语义描述，涵盖图表趋势、流程步骤、关键文字等。然后和OCR识别的文字一起作为文字内容embedding到向量数据库中。
所有的元数据和chunk后的数据都会在postgresql中存一份。如果查询的时候命中了某个chunk，则会关联到某个文档信息，如果是图片则会直接返回一个图片的URL，前端可以直接展示出来。
检索
这是一个检索测试页面，可以选择不同的知识库进行测试，并且支持纯向量检索和混合检索（就是融合了BM25的多路召回），也支持 Rerank 二次排序（接入外部 Rerank 模型）。
还支持把不同的知识库一键生成可以用于dify的外部知识库。直接选择知识库然后配置到dify的外部知识库就可以了。
我自己试着把这套系统在公司的几个项目中跑了一下，简单搭个页面或者在dify中搭个智能客服然后再加上外部知识库，能在后台系统中给内部用户用于检索系统功能性的问题。
需要完善的地方：
一个是日志系统需要根据自己的需求完善一下，一般是推荐放到系统侧，能和系统的用户和信息融合到一起，这个平台可以单独作为知识库的服务。
第二个就是权限，这个系统目前没有任何权限设置。倒是预留了PermissionChecker权限插件，可以通过自定义接口来对接企业内部的权限，来控制知识库的权限。毕竟这些都是企业内部的核心资料。
我这边主要是自己负责好多公司后台项目，我都是用自己整理的一些文档和说明。所以没有做什么权限控制，如果是公司用权限还是要做更精细的控制。
以上就是项目的一个大概介绍，如果也有探索rag知识库落地场景的佬可以互相交流一下。
==============================================
2026-06-05T16:00:00Z
更新：
目前更新了一个版本，支持了飞书和企业微信机器人接入，可以直接跟机器人聊天回答知识库内容，也可以接入到群聊里，默认是只有@机器人才会回答问题。
Sanc 3
赞一下，有个问题请教一下
我目前了解rag还是按照固定长度拆分，存入，检索时候按照“关键词检索”
比如我导入一本书，我想要第一章的概括，他好像只会检索“第一章”这个关键词的相关拆分，没有办法准确获取第一章完整内容，给大模型概括
我尝试做一个导入后做结构化知识整理，现在卡住了，看见你的拆分方式里有“按结构”，能否实现。
hupc (会飞的蹦蹦) 5
看你描述的场景应该不需要向量检索，你这个场景适合将每一章节切分成一个chunk ，这个需要针对你自己的文章特点调整下切分的逻辑。然后检索时你可以直接用bm25算法，也就是关键词检索，召回整个第一章节的chunk，然后再喂给大模型。
按“结构”拆分这是一个理论概念，它的理论就是把文档按照标题结构切分，这是通用的做法。但是具体到你的场景，你需要根据你的文章中每个章节的结构特点，把每个章节的内容切分成一块。我的项目里的“按结构”切分就是按照标题段落等切分成一个chunk，因为我这边大部分是手写的一些markdown文档，都有比较清晰的目录层级。也需要配合单个chunk的字符数来控制chunk的大小。
我觉得rag的各种切分只是一个思路，并没有一个万能的通用模式能使用各种情况，所以说要根据不同切分策略的思路去应用于自己的文档和需求。比如我的表格切分和聊天记录切分就是根据自己情况定制的一个切分规则。
hupc (会飞的蹦蹦) 6
这个其实就是通用产品和定制的区别，dify是一个通用的agent和工作流搭建平台，知识库只是它的一部分功能，我就是看dify里只有一个固定切分和父子切分，而且不能自定义切分逻辑，所以就自己搭了这么一个平台，可以自己根据自身文档的特点去定制一些符合自己需求的切分策略和检索策略。
然后把这些知识库作为外部知识库接入dify这些工具中。
对机器性能怎么样？之前想部署Ragflow，发现对机器性能要求还挺高的
hupc (会飞的蹦蹦) 9
这个对性能没什么要求，就是有Python和相关的扩展就行。向量化这些都是用的第三方的接口
区别在于fastgpt不好维护，搭建的容器多，但是求稳也行
lwimanutd (lwimanutd) 11
非常实用，刚好有在找类似的需求。
ws0105 (白雾生) 12
这个可以对接到钉钉或者飞书里面吗
hupc (会飞的蹦蹦) 13
不支持直接应用到飞书钉钉，但是有http接口，可以套一层应用放到第三方软件中。
能企业内部系统需求文档做一个完整的知识库，然后可以通过mcp形式（或者其他方式）走工作流开发，这个方向我试了好几个知识库都体验不好，不知道后面有没有好的解决方案；腾讯的ima在应用里面使用返回速度和质量都可以，但是走mcp就很慢很一般了
hupc (会飞的蹦蹦) 15
目前这个项目不支持MCP，对外的就定制了一个dify的接口，然后还有一个http接口进行扩展。
自建知识库的难点是要不断调试查询的准确性和切分的合理性。只要准确性可以了，做一些扩展，比如MCP或者skills等，相对于ima这些标准产品要容易的多。
hupc (会飞的蹦蹦) 16
今天更新了一版，支持接入飞书和企业微信了