anything-llm [BUG]:在大型上下文窗口/多个文件中使用RAG

qnakjoqk  于 2个月前  发布在  其他
关注(0)|答案(8)|浏览(39)

运行AnythingLLM的情况如何?

未列出

发生了什么?

使用Railway示例,与Gemini Pro 1.5(1M上下文窗口)。
我试图通过固定许多大文件来充分利用上下文窗口的优势。然而,似乎ALLM并未在请求中提供所有固定的文件(+20个文件)。
此外,只有部分固定的文件出现在引用中。从答案来看,显然有些固定的文件没有被提供。

是否已知重现步骤?

我猜想使用Gemini Pro 1.5 API并固定大量文件,同时还有未固定的文件,然后验证ALLM是否正确提交了所有固定的文件,以及未固定文件中的片段,并正确反映在引用中的来源。

uidvcgyl

uidvcgyl1#

你确定有文件被遗漏,而不仅仅是模型忽略了上下文吗?在代码中,没有限制可以固定多少个文件,但仍然有一个上下文窗口,如果超过1M个令牌,它仍然会被从聊天中剪切。
由于你在铁路上,你应该在日志中看到当发送聊天时,如果上下文对于谷歌来说太大,它应该说类似于cannonballing context xxxx to xxxx或类似的东西 - 这表明你仍然发送了太多的文本,我们不得不截断它。

4sup72z8

4sup72z82#

你好,Tim!是的,我不确定这是否与重新部署有关,但突然间我在所有工作区从整个组织获取报告时遇到了主要问题。我已经暂时关闭了示例,并在周围测试了一个小时左右,删除了所有文件并切换了不同的AI模型(Claude 3-Opus或Gemini 1.5),不同的嵌入器(本地或Open AI Large)和矢量数据库(本地或Pinecone)。但是我的服务器从优秀变得出各种错误,因为不知道嵌入信息和固定文档的内容。我已经确保我处于1M范围内,只用几个较小的文件进行测试,但它似乎总是碰运气。顺便问一下,使用内部矢量数据库和内部嵌入模型与提到的那些相比有什么缺点吗?

2024年4月25日 16:31 Timothy Carambat ***@***.***>:你确定有文件被遗漏,而不仅仅是模型忽略了上下文吗?在代码中没有限制可以固定多少文件,但仍然有一个上下文窗口,如果超过1M个令牌,它仍然会被从聊天中剪切。由于你在Railway上,你应该在日志中看到当发送聊天时,如果上下文对于Google来说太大,它应该会说类似于cannonballing context xxxx to xxxx之类的话——这表明你仍然发送了太多文本,我们不得不截断它。请直接回复此电子邮件、查看GitHub上的<#1187 (comment)>或取消订阅< https://github.com/notifications/unsubscribe-auth/BHCK7BMDNA5FVTUTWW4PY2DY7EHTZAVCNFSM6AAAAABGYQE6ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGM2DSNRVHA >。你收到这封邮件是因为你创建了这个线程。

chhqkbe1

chhqkbe13#

你好,添加一些可能相关的信息。当我查看引用时,有时会显示一些固定的文件,但不会显示其他固定的文件(这些文件也应该具有非常高的关联性)。

2024年4月25日 16:31 skrev Timothy Carambat ***@***.***>:你确定有文件被忽略了吗?这不仅仅是模型忽略了上下文吗?在代码中,没有限制可以固定多少个文件,但仍然有一个上下文窗口。如果超过100万个令牌,它仍然会被从聊天中剪切。由于你在Railway上,你应该在日志中看到当发送聊天时,如果上下文对于Google来说太大,它应该说类似于cannonballing context xxxx to xxxx之类的话——这表明你仍然发送了太多的文本,我们不得不截断它。请直接回复此电子邮件,查看GitHub上的<#1187 (comment)>,或取消订阅< https://github.com/notifications/unsubscribe-auth/BHCK7BMDNA5FVTUTWW4PY2DY7EHTZAVCNFSM6AAAAABGYQE6ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGM2DSNRVHA >。你收到这封邮件是因为你创建了这个线程。

roejwanj

roejwanj4#

这是我们服务器持续测试的一张图片。它非常奇怪。现在,它似乎在答案的开头给出了一个奇怪的引用,而不是从Gemini Pro获取答案。答案也是错误的,没有考虑到最相关的文档(固定),它也没有列在引用中。然而,另一个固定文档(AB 04),其中包含当前查询的无信息,被列出了。[image: image.png]...
2024年4月25日下午4点57分,Richard Sahlberg ***@***.***>写道:嗨,添加可能相关的信息,当我查看引用时,有时会显示一些固定的文件,但不会显示其他固定的文件(应该具有非常高的关联性的文件)。2024年4月25日下午4点31分,Timothy Carambat ***@***.***>回复:你确定有文件被省略了吗?还是只是模型忽略了上下文?在代码中,没有限制可以固定多少个文件,但仍然有一个上下文窗口,如果超过1M个令牌,它仍然会被从聊天中剪切。由于你在Railway上,你应该在日志中看到当发送聊天时,如果上下文对于Google来说太大了,它应该说类似于cannonballing context xxxx to xxxx或者类似这样的话——这表明你仍然发送了太多的文本,我们不得不截断它。请直接回复此电子邮件、在GitHub上查看或取消订阅< https://github.com/notifications/unsubscribe-auth/BHCK7BMDNA5FVTUTWW4PY2DY7EHTZAVCNFSM6AAAAABGYQE6ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGM2DSNRVHA >。你收到这封邮件是因为你是这个线程的作者。消息ID: ***@***.***>

ar5n3qh5

ar5n3qh55#

你好,另一个问题。在我排查这个问题的过程中,我正在移除向量,而且据我理解,当你切换嵌入模型时,是否有必要删除所有文件?然后重新上传和重新嵌入?这是在切换模型时出现的信息框中的信息,但似乎没有必要删除并重新上传所有文件?如果有必要的话,能有一个选项来删除文件夹中的所有文件而不删除文件夹本身(我有大约30个文件夹)就太好了。BR Richard...
2024年4月25日 16:31 skrev Timothy Carambat @.*>:你确定有文件被忽略了吗?而不仅仅是模型忽略了上下文?在代码中没有限制可以固定多少文件,但是仍然有一个上下文窗口,如果超过1M个令牌,它仍然会被从聊天中剪切掉。由于你在Railway上,你应该在日志中看到当发送聊天时,如果上下文对于Google来说太大了,它应该会说类似于cannonballing context xxxx to xxxx之类的话——这表明你仍然发送了太多的文本,我们不得不截断它。直接回复此电子邮件,查看GitHub上的<#1187 (comment)>或者取消订阅< https://github.com/notifications/unsubscribe-auth/BHCK7BMDNA5FVTUTWW4PY2DY7EHTZAVCNFSM6AAAAABGYQE6ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGM2DSNRVHA >。你收到这个邮件是因为你创建了这个线程。

egmofgnx

egmofgnx6#

🤔 如果一个文档被固定,那么它肯定会在发送给模型的消息中使用。
如果你 更改 嵌入模型,这将使所有以前嵌入的文档和工作区失效,因为嵌入器模型输出之间的差异使得向量搜索变得不可能。所以他们需要被删除并重新嵌入。
这就是发生的地方
anything-llm/server/utils/chats/index.js
第93行 in dfaaf16
| | awaitnewDocumentManager({ |
Gemini pro 有一个上下文 https://github.com/Mintplex-Labs/anything-llm/blob/dfaaf1680ff4de647de727fcd404ec044c5dd8e2/server/utils/AiProviders/gemini/index.js#L59C16-L59C25
由于我们管理上下文窗口,并且片段附加到系统,实际限制是
anything-llm/server/utils/AiProviders/gemini/index.js
第26行 in dfaaf16
| | system: this.promptWindowLimit()*0.15, |
或约 157,286 个标记。大约占15%
我们设置这些限制的原因是因为有些人喜欢输入非常非常大的输入,有些人喜欢输入非常大的系统提示。我们不得不以某种方式削减它。
我愿意打赌,因为你有这么多固定的文档,而且上下文仍然超过10万个标记,你的大多数文档都没有进入聊天。
我愿意打赌,在聊天窗口上运行 /reset 以清除历史记录将导致更好的第一React。我认为我们需要做的是让提示窗口值根据哪个值更大而动态变化。
如果系统很大 - 应该占据大部分窗口并缩小用户提示的分配。如果用户提示很大,那么缩小系统的分配。
上下文窗口有限,所以你不能两者兼得。这是肯定发生的事情。

fquxozlt

fquxozlt7#

你好,Tim,是的,听起来动态模式是必要的,或者在工作区区域需要一些设置。我们通常会将上下文窗口限制在10%以内,使用固定文件,用户提示和回答只是预期上下文窗口使用的一部分。请让我添加另一个功能愿望 - 有一个管理员选项卡或类似的地方,您可以一次性调整所有工作区的设置。我有25个工作区,有时我会以相同的方式更新它们,这变得有点烦人=)

诚挚的问候
Richard Sahlberg
Advokat/Partner Foyen Advokatfirma+46 737 19 51 @***. | LinkedIn
我们的服务受一般条款和条件的约束,这些条款和条件可在我们的网站上找到。此通信是机密的,仅供收件人或实体使用。它可能包含根据适用法律受到特权和豁免披露的信息。请在此查看我们的隐私政策,了解我们如何处理个人数据。2024年4月25日,下午6:31,Timothy Carambat ***@***.***>: 🤔 如果一个文档被固定,那么它肯定会在发送给模型的消息中使用。如果您更改嵌入模型,这将使以前嵌入的所有文档和工作区失效,因为嵌入器模型输出之间的差异将使向量搜索变得不可能。因此,它们需要被删除并重新嵌入。这就是发生的地方 https://github.com/Mintplex-Labs/anything-llm/blob/dfaaf1680ff4de647de727fcd404ec044c5dd8e2/server/utils/chats/index.js#L93
Gemini pro的上下文是 https://github.com/Mintplex-Labs/anything-llm/blob/dfaaf1680ff4de647de727fcd404ec044c5dd8e2/server/utils/AiProviders/gemini/index.js#L59C16-L59C25,因为我们管理上下文窗口,并且片段附加到系统,所以真正的限制是 https://github.com/Mintplex-Labs/anything-llm/blob/dfaaf1680ff4de647de727fcd404ec044c5dd8e2/server/utils/AiProviders/gemini/index.js#L26 或约157,286个令牌。大约15%我们设置这些限制的原因是因为有些人喜欢输入非常非常大的输入,而有些人喜欢输入非常大的系统提示。我们不得不以某种方式削减它。我愿意打赌,因为你有这么多固定的文档,而且上下文仍然超过100K个令牌,你的大多数文档都没有进入聊天室。我愿意打赌,在聊天窗口上运行/reset以清除历史记录将导致更好的第一React。我认为我们需要做的是根据哪个值更大来动态设置提示窗口的值。如果系统很大 - 那应该占据窗口的大部分并缩小用户提示的分配。如果用户提示很大,那么缩小系统的分配。上下文窗口有限,所以你不能两者兼得。这是肯定发生在这里的事情。—直接回复此电子邮件,查看GitHub上的邮件,或取消订阅。您收到此邮件是因为您创建了线程。消息ID:***@***.***>

m0rkklqb

m0rkklqb8#

关于这个问题的另一个想法是,我在AI模型中尝试了超过最大令牌数的固定,并从模型本身收到了错误消息,提示总令牌数太大。只是好奇如果在ALLM的所有部分都有设置限制/分数,这是如何可能的。

Richard Sahlberg
Advokat/Partner Foyen Advokatfirma+46 737 19 51 @***. | LinkedIn
我们的服务受一般条款和条件的约束,这些条款和条件可在我们的网站上找到。本通信保密,仅供收件人或实体使用。它可能包含根据适用法律受到特权豁免和披露的信息。请在此找到有关我们如何处理个人数据的隐私政策。2024年4月25日,下午6:31 Timothy Carambat ***@***.***>: 🤔 如果一个文档被固定,那么它肯定会在发送给模型的消息中使用。如果您更改嵌入模型,这将使以前嵌入的所有文档和工作区失效,因为嵌入器模型输出之间的差异将使向量搜索变得不可能。因此,它们需要被删除并重新嵌入。这就是发生的地方:https://github.com/Mintplex-Labs/anything-llm/blob/dfaaf1680ff4de647de727fcd404ec044c5dd8e2/server/utils/chats/index.js#L93
Gemini pro有一个上下文:https://github.com/Mintplex-Labs/anything-llm/blob/dfaaf1680ff4de647de727fcd404ec044c5dd8e2/server/utils/AiProviders/gemini/index.js#L59C16-L59C25,因为我们管理上下文窗口,并且片段附加到系统,所以真正的限制是:https://github.com/Mintplex-Labs/anything-llm/blob/dfaaf1680ff4de647de727fcd404ec044c5dd8e2/server/utils/AiProviders/gemini/index.js#L26 或约157,286个令牌。大约占15%。我们设置这些限制的原因是因为有些人喜欢输入非常大的输入,有些人喜欢输入非常大的系统提示。我们不得不以某种方式削减它。我愿意打赌,因为你有这么多固定的文档,而且上下文仍然超过100K个令牌,你的大多数文档都没有进入聊天。我愿意打赌,在聊天窗口上运行/reset以清除历史记录将导致更好的第一React。我认为我们需要做的是让提示窗口值根据哪个值更大而动态变化。如果系统很大——应该占据窗口的大部分并缩小用户提示的分配。如果用户提示很大,那么缩小系统的分配。上下文窗口有限,所以你不能两者兼得。这肯定是发生了什么事。—直接回复此电子邮件、查看GitHub上的邮件或取消订阅。您收到此邮件是因为您创建了线程。消息ID:***@***.***>

相关问题