实用笔记：索引层——docling流程如何为您准备数据

本指南将逐步构建从原材料到可运行系统的完整流程，内容涵盖：索引层——docling-pipelines如何为RAG准备文档。重点在于可操作的步骤、明确的检查点，以及可直接放入代码仓库的代码，无需猜测其用途。 在概览阶段，应在修改代码之前明确输入内容、该步骤的负责人以及完成标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏的状态。 可将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，定义成功标准，杜绝无声的半完成状态。

什么是RAG？向量数据库的作用是什么？

在研究什么是RAG以及相关流程时，首先要列出规范：所需的输入、成功标志，以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外费用。 在调整提示词之前，先用固定的问题集测试召回率。仅仅更换提示词很难改善较差的检索效果。

为什么普通数据库做不到这一点？

在处理“为何某个阶段无法运行”这一问题时，首先需列出相关约定：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 应将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中管理，这样操作人员无需查看整个系统结构即可进行审计。 在调整提示词之前，需先使用固定的问题集来测试召回率。仅仅更换提示词往往无法解决检索效果不佳的问题。

docling-pipelines中对VectorDB的支持

在 docling-pipelines 阶段处理 VectorDB 支持功能时，首先需明确相关约定：所需输入、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 同时记录正常流程与恢复流程。重试机制、人工审核环节以及死信处理都是产品功能的一部分，而非后续需要补充的内容。 在调整提示词之前，先使用固定的问题集来衡量检索覆盖率。仅仅更换提示词很难改善较差的检索效果。 在 docling-pipelines 阶段处理 VectorDB 支持功能时，首先需明确相关约定：所需输入、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 将此阶段视为输入与经过验证的输出之间的契约。为相关产物命名，定义成功检测标准，并杜绝无声的半完成状态。

VectorDB Operator 的工作原理

将 VectorDB Operator 阶段视为可度量的对象，才能使其发挥最佳作用。在扩大范围之前，先记录一份理想的运行日志、一个故障案例以及回滚说明。在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。应将分块策略与检索策略分开，当质量指标发生变化时，修改其中一项无需强制重写另一项。

六边形架构：兼容任意 VectorDB

将六边形架构的插件阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。 配置应与应用程序代码分开。环境文件、密钥存储和功能标志应集中存放于一处，以便操作人员无需查看整个架构就能进行审计。 将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应强制要求重新编写另一项。

VectorDBOperator
      │
      └── VectorStorePort (interface / abstract contract)
              ├── OpenSearchAdapter   (ships with docling-pipelines)
              ├── MilvusAdapter       (ships with docling-pipelines)
              └── YourCustomAdapter   (implement VectorStorePort → plug in)

分块文档与非分块文档

将“分块文档与非分块文档”阶段视为可度量的评估维度时，其效果最佳。在扩大范围之前，需记录一份理想的处理结果、一个失败案例以及回滚说明。 同时记录正常流程与恢复流程。重试机制、人工审核环节以及错误处理都属于产品功能的一部分，而非后续需要补充的内容。 应将分块策略与检索策略分开。当质量指标发生变化时，调整其中一项不应强制要求重新编写另一项。 将“分块文档与非分块文档”阶段视为输入内容与经过验证的输出结果之间的契约。为相关成果命名，明确成功标准，绝不允许出现无声无息的半完成状态。

过期分块清理

在“过时数据块清理”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况可以避免在从演示环境过渡到共享环境时出现意外费用。必须注明实际作为答案依据的段落；如果没有引用，操作人员就无法区分是幻觉内容还是索引缺失导致的错误。

自动检测的向量维度

在“自动检测向量维度”阶段，修改代码之前需先明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审核。 需注明实际作为答案依据的段落。若没有引用，操作人员就无法区分是幻觉内容还是索引缺失导致的错误。

配置完整的RAG流程

在配置完整RAG阶段时，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及错误处理都是产品功能的一部分，而非后续需要补充的内容。 必须注明实际用于支撑答案的对应内容。如果没有引用依据，操作人员就无法区分是幻觉内容还是索引缺失导致的错误。 在配置完整RAG阶段时，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 应将此阶段视为输入与经过验证的输出之间的契约。需为相关输出文件命名，明确成功判定标准，并禁止默许部分完成的情况。

{
  "flow_name": "rag-indexing-pipeline",
  "global_config": {
    "doc_column": "content",
    "storage": "in-memory",
    "execute_type": "local",
    "enable_micro_batching": true,
    "micro_batch_size": 10
  },
  "flow": [
    {
      "name": "ingest",
      "type": "ingest_source",
      "config": {
        "provider": "filesystem",
        "connection_params": { "paths": ["./documents"], "recursive": true },
        "include_filter": "pdf,docx,txt"
      }
    },
    {
      "name": "extract",
      "type": "extract_operator",
      "depends_on": ["ingest"],
      "config": {
        "text_extraction": { "provider": "docling_library", "doc_column": "content" }
      }
    },
    {
      "name": "chunk",
      "type": "chunker",
      "depends_on": ["extract"],
      "config": {
        "doc_column": "content",
        "chunk_size": 512,
        "chunk_overlap": 50
      }
    },
    {
      "name": "embed",
      "type": "embeddings",
      "depends_on": ["chunk"],
      "config": {
        "provider": "litellm",
        "embeddings_column": "embeddings",
        "provider_config": {
          "model_id": "openai/nomic-embed-text",
          "api_base": "http://localhost:11434/v1",
          "api_key": "${OLLAMA_API_KEY}"
        }
      }
    },
    {
      "name": "store",
      "type": "vectordb",
      "depends_on": ["embed"],
      "config": {
        "provider": "opensearch",
        "doc_id_column": "doc_id_hash",
        "create_index": true,
        "provider_config": {
          "index_name": "my_rag_index",
          "host": "localhost",
          "port": 9200,
          "username": "${OPENSEARCH_USERNAME}",
          "password": "${OPENSEARCH_PASSWORD}",
          "use_ssl": false,
          "engine": "faiss",
          "algorithm": "hnsw",
          "space_type": "l2"
        }
      }
    }
  ]
}

docling-pipelines --flow-file rag-pipeline.json

使用双嵌入的Milvus

在处理基于双嵌入的Milvus阶段时，首先明确需求规范：所需的输入参数、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改始终符合初始要求。 在功能结果之外，还需记录处理时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。 在调整提示词之前，先使用固定的问题集测试召回率。仅仅更换提示词往往无法改善较差的检索效果。

增量索引

在处理增量索引阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中管理，这样操作人员无需查看整个系统结构即可进行审计。 在调整提示词之前，先使用固定的问题集来测试召回率。仅仅更换提示词很难解决检索效果不佳的问题。

整体视角

在完成“整体规划”阶段时，首先需写下相关契约：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及错误消息处理都是产品本身的组成部分，而非后续的优化工作。 在调整提示词之前，需先用固定的问题集来衡量检索效果。仅仅更换提示词很难解决检索能力薄弱的问题。 在完成“整体规划”阶段时，首先需写下相关契约：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 将这一阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，绝不允许出现无声无息的部分完成情况。

操作检查清单

将操作检查清单阶段视为可度量的标准，效果最佳。在扩大范围之前，先记录一份完美的测试用例、一个故障案例以及回滚说明。

优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤出错时，故障应能指向具体的责任方，而非复杂的流程链。

将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。

在预算允许的情况下，使用测试数据而非真实的付费 API，在持续集成过程中添加用于检测关键路径的冒烟测试。

将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，杜绝默默完成部分任务的情况。

将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。

在推广该技术栈之前，应先冻结版本，为关键流程记录标准输出日志，并明确回滚步骤。共享环境需要设置速率限制、租户验证机制，以及负责密钥轮换的明确责任人。与其展示花哨的一次性演示，不如注重扎实的可靠性。

针对6ace628912a6的批量说明：请将提供商密钥移出代码仓库，设定单会话令牌上限，并将日志存储在评估用示例文件旁，以便后续模型更换时保持数据可比性。