[FEAT]: 一般扩展钩子,用于自定义文档处理

□你希望看到什么?

我想为选定的 AnythingLLM 处理点提出一个一般的插件/扩展机制,从文件处理开始,然后嵌入。

这一提议源于#6364,但有意提出不同的解决方案.

在6364中,我提议对SOP式文件进行结构意识/平面分解。 这个问题没有按计划解决,我认为,这实际上更清楚地突出了更广泛的问题:这种专门处理战略也许不应成为头等大事。

但是,对于受不同RAG限制的部署,这一要求本身仍然存在。

而不是将另一个块化算法上游,我想探索AnythingLLM能否暴露一个被支持的扩展接合,这样用户就可以在核心外实施专门的处理行为.

换句话说:

#6364提出了这种行为.

这个问题提出了可以让部署人员自己拥有类似行为的接合。

在概念上,摄取管道可能在文件被嵌入之前的某个地方暴露出可选的钩子:

页:1 收集器 ↓ 已解析文档 ↓ [可选扩展钩] ↓ 普通文档/块 ↓ 嵌入 ↓ 向量 DB

默认路径将完全维持在今天。

如果没有配置扩展名, AnythingLLM 将继续使用其现有的文档处理和分拆行为.

如果配置了一个扩展,它可以接收解析后的文件,并返回应通过现有嵌入管道继续运行的正态单元。

例如,界面在概念上可以看起来像:

{\fn黑体\fs22\bord1\shad0\3aHBE\4aH00\fscx67\fscy66\2cHFFFFFF\3cH808080}你来干什么?
进程文件( {
文档,
上下文,
选项,
- 答应我
文档: 阵列
页面关联:字符串,
元数据 ?: 对象,
}>
}>

准确的API对我来说不重要. 重要部分是核心定义了稳定的输入/输出合同和生命周期,而处理算法则仍然处于核心之外.

然后插件可以执行诸如:

• 结构意识或专题意识块;
• 语义分解;
• 每平方厘米加工;
• 桌子意识处理;
• 元数据浓缩;
• 过滤或正常化;
• 特定文档格式的自定义处理;
• 其他具体部署预处理战略。

所有这些行为都无需成为核心的“任何LLM”特征。

□为什么这对我们来说很重要

我们的 AnythingLLM 部署被作为RAG 层在语音呼叫助手后方使用,而不是传统的聊天界面.

这造成了一些不同的检索限制。

在聊天中,额外的上下文往往相对便宜. 用户还可以检查之前的消息,询问后续问题,或者更自然地从微弱的回答中恢复.

在语音互动中,不必要的检索上下文的操作成本较高:

• 更多的背景可以增加端到端反应延迟;
• 不相关的相邻内容可以 . . . . . . .