我目前正在使用load_qa_with_sources_chain()
运行QA模型。然而,当我用三个块(每个块最多10,000个令牌)运行它时,需要大约35秒才能返回一个答案。我想加快速度。
谁能解释一下是什么影响了函数的速度,以及是否有任何方法可以减少输出时间。如果这不可能,您还可以进行哪些其他更改来提高对源代码进行QA的速度?
我试着改变文本块的大小,但没有明显的效果。我使用map_reduce链。我用的是Python 3.10。
我目前正在使用load_qa_with_sources_chain()
运行QA模型。然而,当我用三个块(每个块最多10,000个令牌)运行它时,需要大约35秒才能返回一个答案。我想加快速度。
谁能解释一下是什么影响了函数的速度,以及是否有任何方法可以减少输出时间。如果这不可能,您还可以进行哪些其他更改来提高对源代码进行QA的速度?
我试着改变文本块的大小,但没有明显的效果。我使用map_reduce链。我用的是Python 3.10。
2条答案
按热度按时间r3i60tvu1#
您需要使用流来实时获取计算的响应,而不是等待整个计算完成并返回给您。
使用langchain,你可以像下面这样使用stream:
流式传输将作为标准输出使用
StreamingStdOutCallbackHandler()
输出。您可以通过扩展BaseCallbackHandler
并使用on_llm_new_token(self, token: str, **kwargs: Any)
方法来编写自己的回调处理器,以便对流执行其他操作,而不是将它们作为标准输出输出。请参见以下示例:说明:
当从OpenAI请求完成时,完成在作为单个响应传输回来之前生成。如果生成的完成时间很长,则响应的等待时间可能会显著延长,通常会持续几秒钟。
假设我们正在使用
gpt-3.5-turbo
模型的聊天完成API,并有以下请求:我们有如下的回应:
问题是这个示例响应首先被计算,合并所有令牌,然后一起返回。
现在让我们看看启用
stream
的另一个示例响应:正如您所看到的,您通过流式处理获得了实时计算的响应,而不是完成整个计算,合并并发送回给您。
wj8zmpe12#
我的理解是,这是目前的一个普遍问题。
参见https://github.com/hwchase17/langchain/issues/1702。
如果有办法让它“不那么慢”,那就太好了。