您的功能请求是否与问题相关？请描述。
对于RAG QA,我们通常希望充分利用模型的上下文窗口，通过插入尽可能多的检索到的文档。然而，用户很难提前知道在不溢出上下文窗口的情况下，可以将多少文档传递给LLM。目前，这只能通过试错来实现，而且很多时候选择一个“正确的”top_k是不可能的，因为数据库中的文档长度差异很大，所以一些查询可能会导致溢出，而其他查询则不会，这取决于检索到的文档。
描述您希望实现的解决方案
因此，我们希望创建一种Prompt Builder类型，可以截断一些插入到提示中的变量(例如截断文档，但不影响指令)。这基本上相当于根据检索到的文档的令牌计数计算动态top_k。为了能够执行这种截断操作，Prompt Builder需要是令牌器感知的。
这将允许用户设置一个相对较大的top_k,并有信心如果它们意外地导致上下文窗口溢出，最不相关的文档将被删除。这将为用户提供更一致的搜索体验，因为我们不再冒着删除通常出现在提示中插入文档之后的指令的风险。
9条答案
按热度按时间vxbzzdmp1#
在使用单独的组件时，我预见到的另一个(小)问题是不容易知道应该截断多少文档。要精确地知道文档应该截断到多少个令牌，需要了解PromptBuilder提示中占用了多少个令牌。除非向PromptBuilder添加功能，否则这是不容易实现的。
人们可以估算或计算他们提示模板中的令牌数量，然后使用该数量配置截断器。虽然不完美，但它会起作用。
rryofs0p2#
在使用单独的组件时，我预见到的另一个(小)问题是，不容易知道应该截断多少文档。要精确地知道文档应该截断到多少个标记，需要知道PromptBuilder提示中使用了多少个标记。除非向PromptBuilder添加功能，否则这是不容易实现的。
人们可以估算或计算他们提示模板中的标记数，然后使用该数来配置截断器。虽然不完美，但它会起作用。
我们可以向提示模板添加一个计数标记的方法，该方法接受一个分词器并返回去除所有jinja内容后的提示的标记数。
up9lanfz3#
我们能否将问题重新表述为：
"在管道中提供分词选项以限制文档或文本长度"
我可以在多个地方看到这种情况，并且有多种策略。对于提示中的文档，我们可以：
但这不仅适用于提示，对排名器也同样适用。
of1yzvn44#
但这不仅仅是提示，对排名者也同样适用。
出于好奇，你脑海中有什么情景会让这个只在排名者中相关？
eqzww0vc5#
实际上我太快了：D
Ranker一次只能获取一个文档。
ehxuflar6#
我将尝试一下。我会在
PromptTokenAwareBuilder下起草一些内容，并回来反馈。mzmfm0qo7#
这不更好吗？只需添加一个新的组件，根据你想要如何实现，裁剪上下文到所需的令牌数量。这样，我们就不需要逐个更改所有组件来采用这种方法，只需将此组件添加到管道中即可。
nwlls2ji8#
是的，我也考虑过这个问题。
我的想法是：
DocumentsTokenTruncater(可能不是一个很好的名字)可以接受一个文档列表，并根据不同的策略截断它们(例如，从左侧、右侧或每个位置截断)。A
TextTokenTruncater可以用于其他用例。这种方法的唯一问题是你希望在提示中使用的文档元数据。
总的来说，我觉得现在这个问题不太重要了，因为大多数模型的上下文长度已经增加了很多。
fzwojiic9#
这样，我们不需要逐个更改所有组件来采用这个，只需要将这个组件添加到管道中。
当我使用单独的组件时，我预见到的另一个(小)问题是不容易知道应该截断多少文档。要精确地知道文档应该截断为多少个标记，需要知道PromptBuilder提示中的多少个标记正在被使用。除非向PromptBuilder添加功能，否则这是不容易实现的。
总的来说，我觉得现在这个问题不太重要了，因为大多数模型的上下文长度已经增加了很多。
是的，我同意这一点，由于现在的上下文长度非常大，这个问题变得不那么紧迫了。