LangChain中CSV嵌入耗时远超PDF的原因及优化问询

一、耗时差异的核心原因 #

• 总嵌入任务量差异：400页PDF的有效文本量通常远低于4万行单列CSV。假设PDF每页平均500字，总文本量约20万字符；而4万行CSV若每行平均100字，总文本量达400万字符，是PDF的20倍。加上RecursiveCharacterTextSplitter拆分后，CSV生成的chunk数量远多于PDF，每个chunk都需要单独调用嵌入模型，总调用次数呈量级增长。
• 文本处理效率差异：PDF加载时会自动过滤格式字符、空白页等无效内容，而CSV加载的是纯有效数据，无冗余内容需要剔除，实际需要嵌入的有效文本占比更高。
• 本地模型调用开销：Ollama本地模型每次调用存在固定启动/推理开销，当chunk数量从数千（PDF）飙升至数万（CSV）时，累计的调用开销会被放大，导致总耗时呈非线性增长。

二、缩短CSV嵌入时间的优化措施 #

• 调整文本拆分策略：
  • 若CSV每行文本长度远小于chunk_size=500，直接移除RecursiveCharacterTextSplitter，用每行作为独立chunk，避免不必要的拆分操作。
  • 若文本较短，可合并多行成一个chunk（比如将10行合并为一个500字左右的chunk），减少总chunk数量。修改代码示例：

    from langchain_core.documents import Document
    
    # 自定义合并逻辑，替代RecursiveCharacterTextSplitter
    merged_docs = []
    current_text = ""
    for doc in data:
        if len(current_text) + len(doc.page_content) <= 500:
            current_text += doc.page_content + "\n"
        else:
            merged_docs.append(Document(page_content=current_text))
            current_text = doc.page_content
    if current_text:
        merged_docs.append(Document(page_content=current_text))
    docs = merged_docs
    

• 启用批量嵌入：给OllamaEmbeddings设置更大的batch_size（比如32、64），减少模型调用次数：

  embedder = OllamaEmbeddings(model="nomic-embed-text", show_progress=True, batch_size=32)
  

• 切换轻量嵌入模型：替换为更快的模型如all-MiniLM-L6-v2，推理速度是nomic-embed-text的数倍，精度多数场景下足够：

  embedder = OllamaEmbeddings(model="all-MiniLM-L6-v2", show_progress=True, batch_size=32)
  

• 启用GPU加速：确保Ollama已配置使用GPU（本地安装后通常自动检测，若未启用可手动指定设备），GPU推理速度比CPU快5-10倍。
• 预过滤冗余数据：提前清理CSV中的空行、重复行、无效数据，减少需要嵌入的总行数。

三、操作失误检查 #

• 不必要的文本拆分：若CSV每行文本较短，使用RecursiveCharacterTextSplitter属于冗余操作，虽不会增加chunk数量，但会额外消耗拆分时间。
• 未设置批量参数：默认OllamaEmbeddings的batch_size可能为1，导致每次仅处理一个chunk，大幅增加调用开销。
• 未利用GPU：若本地有可用GPU但Ollama未启用，会全程用CPU推理，速度极慢。

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