LangChain文档问答方法速度对比及相关技术问询

背景 #

参考文档会定期更新，若采用Embedding Vector空间方法需每日更新嵌入，计划通过Cron Jobs预生成嵌入来补偿延迟。目前涉及4种LangChain文档问答方法：

• load_qa_chain：每次调用使用动态文档
• RetrievalQA：从文档嵌入空间获取数据
• VectorstoreIndexCreator：RetrievalQA的封装
• ConversationalRetrievalChain：使用嵌入空间，且具备记忆与对话历史功能

1. 忽略LLM模型时，四种方法中哪个最快及原因 #

忽略LLM时，RetrievalQA和VectorstoreIndexCreator是最快的，二者本质流程完全一致。
原因：这两种方法依赖预生成好的嵌入向量库，接收到问题后仅需两步操作：将问题转为嵌入向量，再通过向量库的索引做相似性检索定位相关文档片段——这个检索是基于向量索引的高效操作，耗时极短，且几乎不受文档总规模影响。
对比其他两种方法：

• load_qa_chain每次要处理完整的动态文档，若文档规模较大，需先分割为适配LLM上下文的块，这一步耗时远高于向量检索；
• ConversationalRetrievalChain在RetrievalQA的基础上多了对话历史处理、记忆维护的步骤，流程更复杂，耗时更长。

2. load_qa_chain、VectorstoreIndexCreator、ConversationalRetrievalChain的速度差异 #

速度排序（从快到慢）：VectorstoreIndexCreator > ConversationalRetrievalChain（无记忆） > ConversationalRetrievalChain（带记忆） > load_qa_chain（大文档场景）
具体差异：

• VectorstoreIndexCreator：速度稳定高效，因为依赖预生成向量索引，检索耗时几乎不随文档总量增长而变化。
• load_qa_chain：文档极小时，速度可能和VectorstoreIndexCreator接近；但文档规模变大后，分割、拼接prompt的耗时会急剧上升，速度会被拉开明显差距——毕竟每次都要处理完整文档，而不是只取检索到的片段。
• ConversationalRetrievalChain：无记忆版本的流程和RetrievalQA几乎一致，速度接近VectorstoreIndexCreator；带记忆的版本需要额外处理对话历史（整合历史生成检索query、维护记忆存储等），耗时会增加，且对话历史越长，开销越大。

3. 预生成嵌入的embedding DB是否比load_qa_chain更快 #

绝大多数情况下，预生成嵌入的向量库比load_qa_chain更快。
原因：

• 向量库的检索是基于索引的相似性匹配，耗时稳定，哪怕文档总量大幅增长，检索速度也不会明显下降；
• load_qa_chain每次都要处理完整动态文档，文档越大，分割、拼接prompt的耗时线性增长；如果文档未提前分割，还要额外做文本分割，进一步增加耗时；
• 唯一例外是文档极小（比如单段短文本），此时load_qa_chain无需分割，直接拼接prompt的耗时可能略低于向量检索，但这种场景极少。

4. ConversationalRetrievalChain带/不带memory和chat_history是否会影响速度 #

会明显影响速度，差异在于：

• 不带memory和chat_history的版本：流程和RetrievalQA基本一致，仅处理当前问题的向量检索，速度接近VectorstoreIndexCreator；
• 带memory和chat_history的版本：需要额外执行这些操作：
  • 从记忆中提取历史对话，和当前问题结合生成优化后的检索query；
  • 将新的问答对写入记忆进行维护；
  • 若要把对话历史加入LLM的prompt，还要额外拼接历史内容，增加prompt处理耗时。
• 对话历史越长，这些额外步骤的耗时越高，整体速度越慢。

内容的提问来源于stack exchange，提问作者Deshwal