构建智能体式应用的第一步，是找到并分类对应用有价值的数据，然后将这些数据迁移到向量数据库中。这个过程通过一个工作流完成：首先对数据进行切分，然后从这些切分后的数据块中创建嵌入，最后将它们存储到向量数据库中。
在日常生活中，当我们通过移动应用或浏览器界面使用 LLM，例如 ChatGPT、Grok 或 Gemini 时，我们通常只输入文本就已经满足。但在企业环境中，真正的收益来自于将额外的文本和图像与 prompt 一起提供给 LLM。这使得 LLM 能够在生成响应时考虑上传的数据。这些数据可能包括信息、公式、算法、定义，或者任何 LLM 可能觉得有用的内容。
在本章中，我们将通过考察如何识别数据，以及那些用于指导如何使用数据的流程型文档，来把这一过程规模化、 operationalize。随后，我们会介绍如何使用 ETL 工具构建 ingestion pipeline，以处理分布式、多格式的企业数据，并讨论一些关键工程考虑因素，例如吞吐量、可扩展性和成本。
我们还会讨论如何通过增量更新保持数据最新，如何确保敏感信息的安全和合规，以及如何通过数据清洗、混合搜索和知识结构化等技术提升检索质量。
这些主题共同展示了如何构建健壮的数据 pipeline，从而支持可靠、有效的 GenAI 应用。
本章将涵盖以下主题：
- 识别需要摄取到向量数据库中的文档
- 成本优化和限流
- 选择合适的 ETL 工具
- 规划你的数据 pipeline
识别需要摄取到向量数据库中的文档
在寻找相关文档时，你不应该只考虑那些提供原始数据的文档，还应该考虑那些包含流程信息和公式的文档，因为你希望 LLM 使用这些信息。这类文档通常会与包含你希望 LLM 处理的数据的文档结合使用。
下面的例子展示了如何通过将不同类型的数据与 prompt 结合，构建不同类型的应用。
ZZZ Auto Insurance
ZZZ Auto Insurance 希望使用非标准，也就是非 GAAP 的会计准则 IFRS 17，来分析其财务报表，并查看结果与 GAAP 有何不同。会计人员上传 IFRS 17 手册，以及公司的财务文档。随后，LLM 可以通过一个专家编写的 prompt，生成符合 IFRS 17 的报告摘要。这个 prompt 会指示 LLM 使用 IFRS 手册来判断如何生成报告。
这个例子上传了两类数据：
- IFRS 17 手册，其中包含“如何做”的信息和示例。
- 财务数据，也就是被操作的数据。
这是一个极其强大的范式。它类似于计算机科学中在一个类里分离数据和函数的概念，见图 5.1，只不过这一次分离发生在文档层面。
图 5.1——面向对象编程语言和 RAG 架构中的数据与逻辑分离
为了同时使用信息文档和流程文档，你需要编写一个类似这样的 prompt：“使用 IFRS 17 手册来分析所提供的财务文档……” 同时还要附上通过对向量数据库进行语义查询而从文档中生成的 chunk。
但在使用这个强大想法之前，我们需要先找到这些文档，并将它们迁移到向量数据库中，这样相关 chunk 才能在查询时被检索出来。迁移任务可以很小，只涉及几十份文档；也可以是一个非常大的项目，涉及数千份文档。无论哪种情况，选择一个好的 ETL 工具都能让你的工作轻松得多。
选择合适的 ETL 工具
使用内部文档来增强组织内 GenAI 能力的企业，可能会面临许多挑战。第一个挑战来自这样一个事实：企业可能有数千份文档，存储在多个内部系统中。调用 LLM 时，不可能附加超过少量文档，一方面是由于 LLM 的资源限制，另一方面是因为将大量无关数据暴露给 LLM，可能导致它返回意外结果。因此，必须找到一种方法，只向 prompt 提供文档集合中最相关的页面、段落或章节。
读者可能已经猜到，GenAI 项目的第一步，是收集 LLM 将使用的所有文档，并将它们切分进向量数据库。在企业环境中，将文档迁移到向量数据库会出现若干挑战：
- 文档可能并不存储在单一位置，也不一定存储在同一种介质上。它们可能分散在许多位置和介质中，包括文件服务器、磁盘、关系数据库、SharePoint、Workday、AWS S3、GCS、HTTPS 和 SFTP 等。
- 可能需要摄取多种类型的文档，例如 PDF、电子表格、纯文本和 DOCX。
- 你想检索的内容可能分散在许多文档中，可能是数百份甚至数千份。
- 一个 collection 中的文档可能没有按主题分类，因此可能需要一个预处理步骤来识别主题。
- 每份文档都有不同的结构。例如，有些 PDF 有章节和子章节；另一些则是非结构化的。
除了这些复杂性之外，你还需要定义处理错误、执行公司政策以及更新文档版本的策略。在规划迁移项目时，应考虑下面这份检查清单：
- 你如何处理错误？当 pipeline 中发生错误时，应该回滚整个批次、记录文件，还是采取其他动作？
- 你如何围绕个人身份信息，也就是 PII、SOX 和 GDPR 等监管要求执行安全规则？
- 当文档发生变化时，你如何更新信息，更新频率是多少？
- 当发布文档新版本时，你如何处理版本管理？
- 你如何按主题从一个 collection 中收集数据？
- 你应该运行多少条并行 ingestion pipeline？
为了解决这些问题，最好的起点是寻找一个成熟的 ETL 工具，并确保它符合你所在组织的需求和专业能力。如果你的公司已经获得某个 ETL 工具的授权，那么它很可能就是你项目的首选候选工具。
否则，也有几种不错的 ETL 技术可以用来构建你的 ingestion pipeline：
自己编码： 只有在数据仓库数量相对较少时，这才是一个好选择。像 Spring Boot 的 ETL pipeline 这样的库，可以为自建数据 pipeline 项目提供管道能力。
LangChain 等 GenAI 工具： 这是一个值得探索的选项，但考虑到这些工具出现的时间很短，并且在企业环境中的暴露和验证相对有限，如果它们在吞吐量、安全性和整体成熟度方面表现不佳，也不应该令人意外。
成熟 ETL 平台： 一个已经在许多企业系统中经过测试，并且拥有健壮支持和文档的成熟 ETL 平台。
在本书的示例中，我们选择第三种选项：成熟 ETL 平台。虽然这并不一定总是每个项目的最佳选择，但它是最符合本书目的的选择。许多 ETL 工具花费多年时间才达到当前成熟度，并赢得了技术领导者和开发者的信任。当我们考察它们的采用曲线时，可以看到，在发展多年之后，它们仍然处于成熟过程中。
正如第 1 章所提到的，在如今围绕 AI 出现的这种泡沫式亢奋时期，许多工具会出现，试图替代已经存在的产品，但最终却失去动力，甚至彻底失败。我们应该谨慎评估新工具，询问它们究竟提供了什么真正新的东西，以及它们是否已经达到现有工具的成熟度。
本书示例使用 Airbyte。Airbyte 拥有庞大的社区，是一个开源产品，并支持多种语言。与本书主题一致，我们选择了一个不要求你学习 Python 这类新语言才能构建 GenAI 应用的产品。当然，如果你已经懂 Python，Airbyte 也提供了一个优秀的 Python SDK。
除了技术选择之外，你还需要认真规划项目，围绕输入和输出、可接受延迟、安全性以及其他约束做出决策。业务团队和 IT 团队应该共同协作，识别近期和长期的目标与约束。下一节将提供在开始开发之前必须考虑哪些事项的指导。
规划你的数据 pipeline
在开始构建数据 pipeline 之前，你应该完成以下事项：
- 进行容量规划和吞吐量分析。
- 规划新文档版本的增量同步。
- 为健壮的管理、测试和 CI/CD pipeline 进行构建。
- 识别安全、PII 和合规要求。
- 为持续摄取设计测试和验证计划。
让我们从理解如何进行容量规划和吞吐量分析开始。
容量规划和吞吐量
如果你以前构建过 ETL pipeline，那么你可能会通过计算 GB 来为作业估算规模，例如需要处理多少 GB 的 PDF。对于向量摄取来说，正确的指标不是 GB，而是在不超过速率限制或预算约束的情况下，每秒可以生成并写入向量数据库多少个嵌入，也就是 EPS，embeddings per second。
就像传统工程师在 Web 服务中思考每秒请求数 RPS 一样，使用向量数据库的数据工程师必须思考每秒嵌入数 EPS。每次 embedding 调用都会占用 API 配额、消耗网络带宽，并产生成本。对于企业 ingestion pipeline，一个现实的设计目标通常在 50 到 200 EPS 之间，具体取决于 embedding provider。超过这个范围之后，瓶颈通常会从计算转移到 I/O，或者 embedding API 的限流限制。如果需要更高 EPS，就必须考虑并行化策略。
Hugging Face 维护了一个方便的 embedding model 排行榜，名为 MTEB Leaderboard，其中包含速度指标。你可以在以下地址找到它： huggingface.co/spaces/mteb…
可以按 Speed 过滤整体性能。如果你想自己 benchmark EPS，mteb 工具也很方便。完整文档可见：
github.com/embeddings-…
为了估算吞吐量，可以将每个 chunk 的 token 数乘以每份文档的平均 chunk 数。一份 50 页 PDF 可能产生 200 个 chunk；摄取 10,000 份这样的文档，可能需要创建并存储 200 万个嵌入。按照 100 EPS 计算，这大约需要 5.5 小时。这类粗略估算非常关键，因为一旦摄取开始，从头停止并重启会非常昂贵。
同样的逻辑也适用于更新。当夜间批处理新增或修改 1% 的文档时，这 1% 仍然可能代表数万个嵌入。你的 pipeline 必须准备好处理这些增量负载，同时不能拖慢其他依赖 vector store 的流程。
处理变化和持续运行
现代企业很少拥有静态数据。合同会续签，手册会修订，法规会更新。一个健壮的 pipeline 应该假设任何文档都可能在任何时候发生变化。
管理变化并确保持续运行，通常有两种策略：
全量重载： 删除并重新嵌入整个 collection。简单，但昂贵。
增量更新： 只检测并重新嵌入发生变化的部分。
Airbyte 和类似 ETL 工具通过它们的增量同步功能支持这两种方法。你可以定义一个 cursor 字段，例如 updated_at，也可以对文件内容取 hash。当字段发生变化时，只有该记录会被重新处理。这种机制能够降低成本，并保持向量数据库最新。
对于实时要求，可以使用变更数据捕获，也就是 CDC connector。CDC 会监听源系统的事务日志，并将 insert、update 和 delete 流式传入你的 pipeline。虽然真正逐事件的流式处理并不总是必要，但采用短轮询间隔的 CDC，例如一分钟，就可以实现近实时同步。一个有用的心智模型，是想象一条传送带：新文档从一端加入，处理完成的文档从另一端出来，传送带永不停下。你的 ingestion pipeline 应该能够持续运行，即使某个 connector 或外部 API 失败。每次失败都应该被记录、重试，并在必要时隔离出来，供人工检查。
在现代组织中，除非你能证明 pipeline 满足公司安全和隐私合规要求，否则它不会被批准。你的 ETL 解决方案必须具备恰当的安全架构，包括静态加密和传输加密，这一点至关重要。
确保安全、隐私和合规
安全问题必须在组装 pipeline 之前解决。文档通常包含 PII、商业秘密或机密通信。没有控制措施就通过第三方服务传输这些内容是有风险的，并可能违反 GDPR 或 SOX 等法律。嵌入本身也具有与源文档相同的敏感性。
在摄取之前，要定义分类级别，例如 public、internal、restricted 和 confidential。分类将决定哪些 connector、存储系统或 embedding service 可以处理这些数据。高度敏感的文档可能需要使用本地部署模型进行嵌入，而不是使用云 API。
为了确保隐私和安全，你可能需要采用以下技术：
字段级脱敏： 在嵌入前编辑或遮蔽电话号码、身份证号或账号。
静态加密和传输加密： 传输使用 TLS，对存储的 chunk 和嵌入使用 AES-256。
审计轨迹： 存储有关谁在什么时候上传了什么内容的 metadata。
版本管理： 当出现新的文档版本时，保留前一个版本以便追踪。
在大型组织中，合规团队可能会要求可证明的控制措施。例如，Airbyte Enterprise 支持基于角色的访问、密钥保险库集成，以及加密日志。
管理并行 pipeline 和 CI/CD
并行性可以大幅缩短摄取时间，但如果没有认真规划，也可能导致不稳定。每个 connector 都应该声明自己的并发级别。对于 CPU 密集型任务，例如从 PDF 中提取文本，你可以进行水平扩展。然而，对于 embedding 这类 API 密集型任务，如果过于激进地提高并发，就会导致限流和请求失败。
一种平衡设计通常会将 pipeline 分成三个并发阶段：
Extraction： 读取并解析文档，生成干净文本。
Embedding： 生成向量嵌入，可能以批处理方式进行。
Loading： 将嵌入和 metadata 写入向量数据库。
图 5.2——ETL pipeline 的三个阶段：Extract、Transform、Load
每个阶段都可以独立扩展，并通过消息队列或临时存储进行通信。每个阶段都可以确认消息完成，确保即使某个子进程在处理中途崩溃，也不会丢失任何文档。
虽然这种架构设计保证了可靠性和可扩展性，但它必须由强工程实践支撑。
GenAI pipeline 是软件，因此应该像任何微服务一样遵循同样的 DevOps 纪律。将 connector 配置和 transformation code 纳入版本控制。在推送到生产环境之前，先在 staging 环境中进行测试。将 schema 变化，例如修改 metadata 字段，视为需要审查和回滚计划的 migration。
持续集成确保 pipeline 的每次变化，例如从 text-embedding-ada-002 切换到 text-embedding-3-large，都会触发自动化测试，用于验证向量维度兼容性和检索准确性。当所有测试通过后，持续部署再将变化推进到生产环境。
当与 CDC 或增量同步结合时，CI/CD 允许你在不停机的情况下安全演进 pipeline。工程师可以放心推出 chunking 逻辑、embedding 参数或安全过滤器的改进，并确信现有数据仍将保持一致。
测试和验证
测试 ingestion pipeline 不只是检查文件是否到达目标位置。你需要确认数据的语义含义在这段旅程中被保留下来了。
先从每个阶段的单元测试开始：
Extraction tests： 验证 PDF 到文本的转换是否保留段落和标题。
Embedding tests： 比较已知句子对之间的余弦相似度。
Load tests： 确保向量维度与 embedding model 的输出一致。
然后，使用样本 prompt 运行集成测试。用几个已知问题查询向量数据库，并人工检查返回的前五个 chunk。如果匹配结果在语义上相关，那么你的嵌入和 metadata schema 是健康的。如果不相关，就需要重新检查 chunk size 或预处理逻辑。
最后，实现持续验证。随着新文档到来，抽样 1% 的嵌入并重新计算相似度。平均相似度或检索准确率的漂移，往往意味着发生了静默损坏，或者不同运行之间的预处理不一致。
从这个规划过程中浮现出的最重要实践考虑之一，就是成本优化和限流。
成本优化和限流
因为发送去做 embedding 的每个 token 都代表成本，所以限流不仅是一项技术控制，也是一项财务控制。大多数 embedding provider 都会发布速率限制，例如每分钟 3,500 个请求。许多 ETL 工具允许为每个 connector 设置速率限制，因此你可以确保流量保持在配额之内。
一个常见错误是限流过于激进，导致 GPU 空闲，而文档却在队列中积压。正确方法是动态限流，根据来自 API 响应代码的实时反馈调整并发。指数退避这类 back-off 算法，例如 1 秒、2 秒、4 秒、8 秒，效果很好。如果 embedding 创建或向量数据库插入的延迟成为问题，可以逐步减少提交的请求数量。
对于非常大的积压任务，可以将摄取安排在非高峰时段，或者使用 batch embeddings，将多个 chunk 合并到单次请求中。在高容量系统中，这些优化可以将成本削减一半。
评估检索质量
一旦数据进入 vector store，就需要衡量它表现如何。检索质量可以用标准指标量化，例如 precision@k，即返回的 top-k chunk 中相关 chunk 所占比例，以及 recall@k，即所有相关 chunk 中被检索到的比例。对于企业文档而言，precision@5 > 0.8 通常是可以接受的基线。
你可以通过维护一套“问题 → 预期答案”对的测试集，来自动化这项评估。定期重新运行这套测试，以便在代码或模型更新后检测回归。这一实践会把 GenAI 实验转化为一种以可衡量结果为基础的工程纪律。
知识结构和高级检索（可选）
当数据复杂或体量庞大时，我们需要使用高级技术，并利用向量数据库的高级功能。下面列出一些高级选项。
在企业数据中发现分类法
一旦文档被摄取到向量数据库中，并且检索系统开始返回语义相关的 chunk，一个新的挑战就会出现。系统可能检索到相关文本，但可能还无法理解这些信息与组织内部更广泛概念结构之间的关系。在传统信息系统中，这种结构通过 taxonomy 表示：一种概念和主题的层级分类，用于将信息组织成有意义的类别。
在许多企业中，taxonomy 已经以碎片化形式存在。产品目录定义商品类别。合规部门维护监管文档分类。客户支持系统维护描述常见问题的主题层级。然而，这些 taxonomy 很少是统一的。当来自不同系统的文档被摄取进向量数据库时，这些系统内部曾经存在的语义结构往往会丢失。
Taxonomy discovery 通过识别摄取数据中的潜在概念结构来解决这个问题。现代 GenAI 系统不再仅仅依赖预定义层级，而是可以直接从嵌入本身发现相关概念的集群。嵌入向量在高维空间中表示语义含义。当使用 k-means 或 hierarchical clustering 等聚类算法对嵌入进行分组时，讨论相似概念的文档会自然形成集群。
例如，一家大型保险公司可能会摄取数千份保单文档、理赔流程和监管指南。如果没有 taxonomy，检索可能会返回正确文档，却无法揭示这些文档如何与 underwriting rules、claims handling 或 regulatory reporting 等更广泛概念相关。通过聚类嵌入，系统可以推断出类似 taxonomy 的概念分组。工程师随后可以审查并标记这些集群，把它们转化为显式的知识类别。
Taxonomy discovery 的一个重要优势是，它会随数据一起演进。随着新文档被摄取，嵌入可以定期重新聚类，以检测新兴主题。这种能力在术语快速演进的行业中尤其有用。例如在网络安全领域，新的威胁类别会定期出现。自动 taxonomy discovery 有助于确保知识结构跟上新信息的变化。
构建 taxonomy 时使用的另一种技术，是将关键词提取与嵌入相似度结合。首先使用 TF-IDF 或基于 transformer 的关键词模型等方法，从文档中提取重要术语。然后对这些关键词进行嵌入，并通过比较识别概念关系。当与聚类结合时，这个过程会生成候选 taxonomy tree，供领域专家进一步精修。
随着时间推移，taxonomy 会成为向量数据库之上的一个有价值层。检索系统可以将 taxonomy label 作为 metadata filter，从而实现更精确的搜索查询。系统不再只基于语义相似度检索文档，而是可以将检索限制在特定概念分支中。这会同时改善性能和可解释性。
因此，taxonomy discovery 会把向量数据库从一个简单的相似度搜索工具，转变为一个结构化知识系统。它提供了一种概念脚手架，使企业能够在规模化层面上推理自己的信息。
混合搜索与纯向量检索的局限
向量数据库之所以流行，是因为它们能够支持语义搜索。它们不是匹配精确关键词，而是检索那些在向量空间中嵌入接近的文档。当用户用自然语言表达问题时，这种能力会显著改善搜索结果。
然而，纯语义检索也有局限。某些查询需要精确匹配，而不是语义近似。当用户搜索产品代码、法律条款编号或特定技术标识符时，传统关键词搜索往往优于向量相似度。
因此，许多现代 GenAI 架构会使用混合搜索，也就是将向量相似度与 BM25 等词汇搜索方法结合起来。每种方法都可以弥补另一种方法的弱点。
词汇搜索在检索包含精确单词或短语的文档时极其有效。它快速、确定性强，并且容易理解。它的弱点在于处理语义变化。如果用户询问 “vehicle coverage rules”，但文档使用的是 “automobile insurance policy” 这个短语，词汇搜索可能无法检索到正确内容。
向量搜索通过捕捉语义含义解决这个问题。尽管词语不同，“vehicle insurance” 和 “automobile coverage” 的嵌入在向量空间中会很接近。然而，向量搜索有时会检索到语义相关但不够精确，无法回答具体问题的文档。
混合搜索会结合两种检索方法的分数。一种常见实现是计算词汇分数和向量相似度分数，然后用加权公式进行合并。在两种度量上都表现良好的文档会排在最前面。
在实践中，混合搜索通常能为企业知识系统产生最佳检索质量。词汇组件确保不会错过精确匹配，而向量组件则捕捉关键词搜索无法发现的语义关系。
混合搜索也提升了透明度。工程师可以检查词汇组件，以理解某个文档为什么匹配查询。这种可解释性在受监管环境中特别有价值，因为自动化决策必须能够被解释。
如今，许多向量数据库已经直接支持混合检索。其他系统则与 Elasticsearch 或 OpenSearch 等传统搜索引擎集成。在这些系统中，词汇搜索会先检索候选文档，然后用向量相似度重新排序。这种两阶段架构在性能和相关性之间取得平衡。
随着 GenAI 系统变得越来越大，混合检索变得越来越重要。组织很少只依赖单一检索技术。相反，它们会结合多个检索信号，以便在各种查询类型下获得可靠结果。
数据清洗在 GenAI pipeline 中的重要性
检索系统的有效性高度依赖底层数据质量。即使是复杂的 embedding model，也无法弥补准备不充分的文本。被摄取的文档通常包含格式化噪声、重复章节或无关 metadata，而这些都会降低检索质量。
因此，数据清洗是 pipeline 中的关键阶段。在文档被嵌入之前，应该将它们规范化为一致的文本表示。这通常包括移除在页面中反复出现的页眉、页脚和页码。这些重复片段会通过在无关文档之间引入人工相似性，扭曲嵌入。
扫描 PDF 会带来另一个常见问题。光学字符识别系统有时会引入错误，例如合并单词或错误字符。如果这些错误保留在文本中，那么基于它们生成的嵌入可能无法准确反映文档含义。拼写纠正和句子分割等预处理步骤可以缓解这个问题。
去重同样重要。企业通常会在不同系统中存储同一文档的多个副本。如果重复内容被分别嵌入，检索系统可能返回多个完全相同的 chunk，降低结果多样性。Hashing 技术可以在摄取前识别重复内容。
Metadata enrichment 是数据准备的另一个方面。文档很少孤立存在；它们属于部门、项目或监管类别。为每个 chunk 附加这种上下文 metadata，可以提升检索精度，因为查询可以按 document type、author 或 date 等属性过滤结果。
清洗还包括术语标准化。组织经常使用多个名称表示同一概念。例如，一份文档可能使用 “customer”“client” 或 “policyholder”。虽然 embedding model 能捕捉语义相似性，但一致术语可以提高可解释性，并减少歧义。
一个设计良好的数据清洗流程，会提高 GenAI 系统的整体可靠性。它确保嵌入表示的是有意义内容，而不是格式化噪声。随着文档集合规模增长，精心预处理所带来的好处会越来越明显。
图数据库与知识图谱的出现
虽然向量数据库擅长相似度搜索，但它们并不擅长表示实体之间的显式关系。许多企业知识系统需要的不只是语义邻近性；它们还必须捕捉结构化关系，例如所有权、依赖关系或因果连接。
图数据库通过将信息表示为节点和边来满足这一需求。每个节点代表一个实体，例如产品、文档、组织或概念。边表示这些实体之间的关系。
当与向量检索结合时，图数据库提供了一种强大的互补能力。向量搜索识别相关信息片段，而图遍历揭示这些片段之间如何相互关联。
考虑前面保险公司分析财务报表的例子。向量搜索可能会检索到描述会计规则的段落。图数据库随后可以将这些规则连接到相关实体，例如监管机构、金融工具或合规流程。这种关系结构使系统能够以更加结构化的方式推理信息。
知识图谱也支持可解释性。当 GenAI 系统生成答案时，图可以展示导致该结论的关系链。这种能力在金融、医疗和法律等领域尤其重要，因为这些领域的决策必须是可审计的。
构建知识图谱通常从 ingestion pipeline 中开始。命名实体识别模型会识别文本中的实体，例如人、组织或产品。关系抽取模型随后推断这些实体如何连接。得到的实体和关系会与原始文档一起存储在图数据库中。
一旦图存在，检索就可以结合向量搜索与图遍历。一个查询可能首先通过嵌入检索相关文档，然后通过图关系扩展搜索，以收集额外上下文。这种技术有时被称为 GraphRAG，它会用结构化知识丰富响应。
因此，图数据库将 GenAI 系统的能力扩展到了相似度搜索之外。它们引入了显式推理结构，使企业数据能够进行更深入的分析。
走向集成式知识检索
本节讨论的技术，代表了 GenAI pipeline 的自然演进。早期系统主要关注摄取文档和生成嵌入。随着组织积累使用这些系统的经验，它们开始认识到，仅靠语义搜索并不足以完成复杂知识任务。
Taxonomy discovery 将概念结构引入文档集合。Hybrid search 同时提升语义查询和词汇查询的检索准确率。Data cleaning 确保嵌入准确反映源材料含义。Graph database 为围绕实体及其连接进行推理提供关系框架。
这些组件共同将一个简单的向量数据库转变为一个综合知识平台。系统不再检索孤立的文档片段，而是在更广泛的概念和关系上下文中检索结构化信息。
随着 GenAI 应用逐渐成熟，结合向量数据库、词汇搜索引擎和图数据库的架构正变得越来越常见。这些混合系统映射了人类组织知识的方式：既通过相似性，也通过关系。
其结果是，一个能够支持复杂分析任务的检索系统：从回答自然语言问题，到跨大型文档集合探索相互连接的概念。
总结
乍一看，为 GenAI 构建数据 pipeline 像是一个管道问题：连接 connector、抽取文本、加载向量。但实际上，它更像是一项系统工程实践，结合了可靠性、安全性、成本优化，以及对向量嵌入模型的扎实理解。
好消息是，你已经知道的每一项最佳实践，例如日志、重试策略、队列、版本控制等，都可以直接应用到数据 pipeline 构建中。唯一的新东西在于你迁移的对象，也就是嵌入而不是记录，以及你衡量成功的方式，也就是语义相关性而不是行数。
在下一章中，我们将使用 Airbyte 构建一个完全可运行的 pipeline，将一组非结构化文档连接到 Pinecone 向量数据库，并为其加上可观测性和错误恢复能力。到本章结束时，你将拥有一个可复现的 ingestion framework，可以在你的 GenAI 项目中重复使用。
