.NET 数据摄取与向量化架构：构建企业级检索增强生成（RAG）管道

1. 摘要

随着生成式人工智能（Generative AI）技术的迅猛发展，企业级应用开发正经历着一场深刻的范式转变。传统的事务处理系统正在向基于大语言模型（LLM）的智能系统演进，其中检索增强生成（RAG）架构已成为解决模型幻觉、利用私有数据以及保持知识时效性的关键技术方案。在这一背景下，微软推出的 Microsoft.Extensions.DataIngestion 和 Microsoft.Extensions.VectorData 库，不仅是.NET AI 生态系统的重要补充，更是标志着从实验性 AI 开发迈向工程化、标准化 AI 数据管道的关键里程碑。

我们将深入探讨“统一文档表示”（Unified Document Representation）如何解决非结构化数据处理的异构性难题，剖析 IngestionPipeline 在流式处理和错误恢复方面的设计智慧，评估基于 Microsoft.ML.Tokenizers 的语义分块策略对检索质量的深远影响，并详细阐述 Microsoft.Extensions.VectorData 如何通过统一抽象层消除向量数据库的锁定风险。此外，本文还将对比 Semantic Kernel 的传统内存存储机制，提供从遗留系统向现代化架构迁移的路径指引。

2. 引言：.NET AI 生态系统的工程化转折

2.1 数据“管道工程”的崛起

在生成式 AI 应用的早期探索阶段，开发者往往将注意力集中在提示词工程（Prompt Engineering）和模型选择上。然而，随着应用规模的扩大，业界逐渐意识到，决定 RAG 系统成败的核心因素往往不在于模型的参数量，而在于供给模型的数据质量。数据摄取（Data Ingestion）——即从原始源获取数据、清洗、分块、嵌入并存储的过程——成为了 AI 应用中的“管道工程”。

在.NET 生态系统中，过去缺乏一套统一的标准来处理这一复杂的 ETL（Extract, Transform, Load）流程。开发者不得不依赖零散的第三方库来解析 PDF，手写逻辑来切分文本，并硬编码特定向量数据库的 SDK。这种碎片化的开发模式导致了代码的高耦合、低复用以及维护困难。Microsoft.Extensions.DataIngestion 的推出，正是为了填补这一空白，它提供了一套标准化的原语，使数据处理像 ASP.NET Core 中的依赖注入或日志记录一样，成为一种基础设施能力2。

2.2 模块化与解耦的设计哲学

微软此次推出的构建模块遵循了高度模块化和解耦的设计哲学。与封闭的“黑盒”解决方案不同，这些库被设计为一系列可组合的原子组件。

  • 读取器（Readers）：负责屏蔽数据源的差异，无论是本地文件、云存储还是内存流，都被规范化为统一的格式。
  • 处理器（Processors）：充当管道中的中间件，利用 AI 能力对数据进行增强，如自动生成摘要或提取关键词。
  • 分块器（Chunkers）：基于精确的 Token 计算策略，将长文档切分为适合 LLM 上下文窗口的片段。
  • 写入器（Writers）：处理数据的持久化，特别是向向量数据库的写入 1。

这种设计不仅提高了代码的可测试性，还赋予了开发者极大的灵活性。例如，开发者可以轻松地替换底层的向量数据库，而无需重写上层的数据处理逻辑；或者在管道中插入自定义的隐私清洗步骤，而不影响后续的嵌入生成。这种架构的弹性，是构建“未来就绪”（Future-ready）AI 应用的基石。

3. 统一文档表示：异构数据的标准化治理

在 RAG 系统中，数据源的多样性是一个巨大的挑战。企业知识库中混杂着 PDF 报告、Word 文档、HTML 网页、Markdown 笔记以及各种图像文件。如果针对每种格式都编写独立的解析和处理逻辑，系统将变得极其臃肿且难以维护。Microsoft.Extensions.DataIngestion 库通过引入 统一文档表示（Unified Document Representation） 的概念，从根本上解决了这一问题。

3.1 IngestionDocument 对象模型深度解析

核心类 IngestionDocument 是所有异构数据在内存中的统一投影。该设计的一个关键架构决策是采用了 以 Markdown 为中心（Markdown-centric） 的表示形式 1。

3.1.1 为什么选择 Markdown？

选择 Markdown 作为中间格式并非偶然，而是基于对大语言模型特性的深刻理解。现代 LLM（如 GPT-4, Llama 3）在其预训练阶段接触了大量的代码和 Markdown 文档，因此它们对 Markdown 的结构（标题、列表、代码块、引用）具有天然的理解能力。

相比于纯文本（Plain Text），Markdown 保留了文档的层级结构信息，这对于后续的“语义分块”至关重要。相比于 HTML 或 XML，Markdown 的 Token 密度更高，噪音更少，更适合作为 Prompt 的一部分输入给模型。因此，将所有源文档转换为 Markdown 结构的 IngestionDocument，实际上是在进行一种“面向 AI 的数据清洗”，最大化了模型理解数据结构的能力 2。

3.1.2 结构化组件详解

IngestionDocument 并非一个简单的字符串容器，而是一个包含丰富结构化信息的对象图。库中定义了一系列子类来精确描述文档的不同部分：

  • IngestionDocumentSection（文档节）：
    这是文档的高层逻辑划分，通常对应于 PDF 的页面、书的章节或 PPT 的幻灯片。保留这种物理或逻辑的分隔对于后续实现“按页引用”或“按章节检索”至关重要。例如，在法律文档检索场景中，用户往往希望知道引用的具体条款位于哪一页，IngestionDocumentSection 提供的上下文信息恰好满足这一需求 3。
  • IngestionDocumentHeader（文档标题）：
    该类捕获了文档的骨架（H1, H2, H3...）。在 RAG 检索中，标题往往概括了其下段落的核心语义。通过识别标题，分块策略（Chunking Strategy）可以更智能地决定切分点，避免将一个完整的语义块（如一个子章节）错误地切断。
  • IngestionDocumentParagraph（文档段落）：
    这是文本内容的原子单元。它承载了实际的信息负载。
  • IngestionDocumentTable（文档表格）：
    表格数据的处理是 RAG 中的难点。简单的文本提取往往会破坏表格的行列对齐，导致模型无法理解数据关系。IngestionDocumentTable 试图在对象模型层面保留表格的结构化特征，使得在转换为最终的 Prompt 时，可以重构出 Markdown 表格，从而让 LLM 能够正确地进行行读取或列对比 3。
  • IngestionDocumentImage（文档图像）：
    在多模态 RAG 场景中，图像不再是黑洞。该类不仅存储图像的二进制数据或引用路径，更重要的是它为后续的 AI 增强（如自动生成 Alt Text）预留了位置。这使得管道能够处理图文混排的文档，将图像信息转化为向量空间可检索的文本描述 3。

3.2 读取器抽象与实现策略

IngestionDocumentReader 是负责将外部原始数据转换为 IngestionDocument 的抽象基类。微软提供了一系列开箱即用的实现，同时也支持开发者扩展。

3.2.1 内置读取器分析

  • MarkdownReader：
    这是最基础的读取器，直接处理现有的 Markdown 文件。它不需要复杂的转换逻辑，是处理技术文档库（如 GitHub Wiki）的理想选择 3。
  • MarkItDownReader：
    这是一个功能强大的读取器，集成了微软的 MarkItDown 工具。它能够处理 Office 格式（Word, Excel, PowerPoint）、PDF 以及其他常见格式，并将它们“降维”打击为统一的 Markdown 格式。对于企业环境中的大量遗留文档，MarkItDownReader 是连接传统 IT 资产与现代 AI 系统的桥梁 3。
  • MarkItDownMcpReader：
    引入了对 模型上下文协议（Model Context Protocol, MCP） 服务器的支持。这是一个前瞻性的设计，表明该库准备好与更广泛的 AI 代理生态系统集成，允许通过标准协议跨进程或跨网络边界解析文档 3。

3.2.2 数据库摄取的挑战与自定义

尽管文件系统的读取器非常丰富，但在实际的企业应用中，大量高价值数据存储在 SQL Server、CMS 或 NoSQL 数据库中。目前的预览版中，IngestionDocumentReader 的设计在处理非文件源时存在一定的局限性。开发者社区反馈指出，当前的接口设计倾向于文件流，使得直接从数据库记录映射到 IngestionDocument 需要一些额外的适配工作 7。

为了解决这个问题，开发者通常需要实现自定义的 IngestionDocumentReader。这个自定义读取器不读取文件路径，而是接收数据库的主键 ID，在内部查询数据库，提取文本字段，并手动构建 IngestionDocument 对象。这体现了库的扩展性，同时也揭示了当前版本在“非文件”场景下的改进空间。

4. 数据摄取管道架构：流式、弹性与中间件

IngestionPipeline<T> 类是整个数据处理流程的指挥官。它不仅负责按顺序调用组件，还封装了复杂的并发控制、错误处理和资源管理逻辑。

4.1 管道组合与依赖注入

IngestionPipeline 的构造遵循了依赖注入（DI）的最佳实践。它要求在实例化时注入核心组件：Reader, Chunker, Writer。这种设计使得管道本身是无状态的，且高度可配置。

// 管道实例化代码结构示例
using IngestionPipeline<string> pipeline = new(
reader,
chunker,
writer,
loggerFactory: loggerFactory)
{
// 配置文档级处理器（中间件）
DocumentProcessors = { imageAlternativeTextEnricher },

// 配置分块级处理器（中间件）  
ChunkProcessors \= { summaryEnricher }

};

通过属性初始化器（Object Initializer）配置 DocumentProcessors 和 ChunkProcessors 的方式，类似于 ASP.NET Core 中的中间件管道构建。这允许开发者在核心流程的前后插入任意数量的自定义逻辑，例如在分块前进行 PII（个人敏感信息）清洗，或者在分块后进行关键词提取。

4.2 流式处理机制（IAsyncEnumerable）

在处理大规模语料库（如数百万份合同文件）时，内存管理是首要挑战。IngestionPipeline.ProcessAsync 方法的设计充分考虑了这一点，它返回 IAsyncEnumerable<IngestionResult>。

这种设计意味着管道是 流式（Streaming） 执行的。系统不会一次性将所有文档加载到内存中，而是采用“拉取”模式：处理完一个文档，释放相关内存，再处理下一个。这使得在有限内存的容器环境中运行大规模 ETL 任务成为可能。下游的消费端（Consumer）可以通过 await foreach 逐个获取处理结果，实现实时的进度反馈或即时的索引更新。

4.3 弹性设计：部分成功模式

在分布式系统和大规模批处理任务中，部分故障 是常态。某个特定的 PDF 文件可能损坏，或者某个网络调用（如调用 OpenAI API 生成摘要）可能超时。

IngestionPipeline 采用了“部分成功”的设计模式。单个文档的处理失败不会导致整个管道抛出异常并终止。相反，管道会捕获该文档处理过程中的异常，将其封装在 IngestionResult 对象中（包含 Succeeded 布尔标志和 DocumentId），并记录错误日志，然后继续处理下一个文档 1。

这种设计对于长时间运行的后台任务至关重要。它确保了 99.9% 的正常文档能够被正确索引，而那 0.1% 的失败文档可以通过日志被识别并单独重试，极大地提高了系统的整体可用性和鲁棒性。

4.4 泛型 T 的意义

值得注意的是 IngestionPipeline<T> 中的泛型 T。虽然最常见的场景是 T 为 string（处理文本数据），但这种泛型设计为未来留出了空间。理论上，它可以支持 IngestionChunk<Image> 或其他多模态数据类型，只要相应的 Chunker 和 Writer 支持该类型。这体现了库设计者对未来多模态 AI 场景的预判。

5. 分块策略与分词技术：RAG 性能的决定性因素

如果说数据是 RAG 的燃料，那么分块（Chunking）就是炼油的过程。分块的质量直接决定了检索的准确率（Recall）和生成的精确度（Precision）。Microsoft.Extensions.DataIngestion 在这方面提供了基于深厚算法基础的解决方案。

5.1 Microsoft.ML.Tokenizers：精确度的基石

传统的分块往往基于字符数（例如每 1000 个字符切一刀）。然而，LLM 的上下文窗口是基于 Token 计数的。中文字符、英文字母、特殊符号在 Token 化后的长度差异巨大。简单的字符切分往往会导致实际 Token 数超出模型限制，或者造成 Token 空间的浪费。

Microsoft.Extensions.DataIngestion 构建在 Microsoft.ML.Tokenizers 之上 。这是一个高性能的分词库，支持 BPE (Byte Pair Encoding) 等主流分词算法，包括 GPT-4 使用的 cl100k_base 编码。

这意味着管道中的分块操作是 Token 感知（Token-Aware） 的。当配置 MaxTokensPerChunk = 2000 时，库会确保切分出的片段在经过特定模型（如 GPT-4）的分词器编码后，严格不超过 2000 个 Token。这种精确控制对于最大化利用上下文窗口、防止 API 调用报错至关重要。

5.2 三大分块策略深度剖析

库提供了三种主要的分块器实现，分别对应不同的数据特征和业务需求。

5.2.1 HeaderChunker（基于标题的分块）

  • 工作机制：利用 IngestionDocument 中的 IngestionDocumentHeader 信息，沿着文档的标题层级（H1 -> H2 -> H3）进行切分。
  • 适用场景：结构化极强的文档，如用户手册、API 文档、法律法规。这些文档的每一节通常讲述一个独立的主题。
  • 优势：语义边界清晰，极大降低了断章取义的风险。它尊重了原作者的逻辑组织。
  • 局限：如果文档缺乏标题结构，或者某一节内容过长（超过 Token 限制），该策略可能效果不佳或退化为强制切分。

5.2.2 SectionChunker（基于节的分块）

  • 工作机制：基于 IngestionDocumentSection 进行切分，通常对应于物理页面或逻辑章节 。
  • 适用场景：扫描版 PDF 处理，或者像 PPT 这样每一页内容相对独立的文档。
  • 优势：便于实现“原文定位”，用户可以看到检索结果来自“第 5 页”。

5.2.3 SemanticSimilarityChunker（基于语义相似度的分块）

这是最智能、也是最具技术含量的分块策略。

  • 工作机制：
    该分块器不仅仅是看结构，而是看“意思”。它利用嵌入模型（Embedding Model）对正在处理的句子生成向量，并计算当前句子与前文上下文的 余弦相似度（Cosine Similarity）。当相似度分数突然下降时，意味着话题发生了转移（Topic Shift），分块器就会在此处“下刀”切分 1。

  • 配置选项 (IngestionChunkerOptions)：

    • MaxTokensPerChunk：硬性上限，即使话题没有结束，达到此长度也会强制切分，防止溢出。
    • OverlapTokens：重叠窗口。在切分点前后保留一定数量的 Token（例如 50 个），确保上下文的连续性，避免切断跨句子的指代关系 9。

  • 代码实现细节：
    // 实例化分词器
    var tokenizer = TiktokenTokenizer.CreateForModel("gpt-4");

    // 配置选项
    IngestionChunkerOptions chunkerOptions = new(tokenizer)
    {
    MaxTokensPerChunk = 2000,
    OverlapTokens = 50
    };

    // 实例化语义分块器，注入嵌入生成器
    IngestionChunker<string> chunker = new SemanticSimilarityChunker(
    embeddingGenerator,
    chunkerOptions);

  • 适用场景：会议记录、长篇叙事文章、散文、对话记录等缺乏明确标题结构的流式文本。

  • 优势：生成的块具有高度的语义内聚性（Cohesion），检索出来的片段往往是一个完整的话题，极大地提升了 RAG 的回答质量。

6. 智能增强层：从 ETL 到 AI-ETL

单纯的文本切分只是第一步。为了让数据更容易被检索，Microsoft.Extensions.DataIngestion 引入了 AI 增强（AI Enrichment） 的概念。通过在管道中插入由 LLM 驱动的处理器，可以在数据入库前对其进行“智力加工”。

6.1 内置丰富器（Enrichers）详解

这些丰富器实现了 IngestionChunkProcessor<T> 或 IngestionDocumentProcessor 接口，可以直接插入管道。

  1. SummaryEnricher（摘要丰富器）
    • 功能：对每个分块（Chunk）调用 LLM 生成一段简短的摘要 1。
    • 架构价值：
      • 双路检索：系统可以同时索引原始文本和摘要。有时候用户的查询更匹配摘要的概括性描述，而不是原文的细节。
      • 上下文压缩：在生成阶段，如果上下文窗口紧张，可以只将摘要发送给 LLM，而不是原始的长文本。
  2. KeywordEnricher（关键词丰富器）
    • 功能：分析分块内容，提取出关键实体（Entities）或术语 1。
    • 架构价值：支持 混合检索（Hybrid Search）。向量检索擅长语义匹配，但对于专有名词（如产品型号“X-2000”）可能不够精确。通过提取关键词并存储在元数据中，可以在查询时结合倒排索引（关键词匹配）和向量索引，大幅提升召回率。
  3. ImageAlternativeTextEnricher（图像描述丰富器）
    • 功能：调用多模态模型（如 GPT-4 Vision）分析文档中的图片，生成文本描述（Alt Text）4。
    • 架构价值：填补了传统文本 RAG 的盲区。使得图片内容变得“可搜索”。例如，用户搜索“Q3 销售趋势”，系统可以通过图片的 Alt Text 检索到包含趋势图的幻灯片页面。
  4. SentimentEnricher（情感分析丰富器）
    • 功能：判断文本的情感倾向（积极、消极、中性）3。
    • 架构价值：为数据打上情感标签。在客户服务场景中，可以利用此元数据过滤出“愤怒的客户反馈”优先处理。

6.2 自定义增强与中间件模式

除了内置丰富器，开发者可以轻松实现自定义逻辑。例如，编写一个 PiiRedactionEnricher，利用 Microsoft.Extensions.AI 的能力识别并掩盖文本中的身份证号或手机号。这种中间件模式使得数据管道不仅是传输数据的通道，更是执行数据治理、隐私合规和知识挖掘的核心场所。

7. 向量存储抽象：Microsoft.Extensions.VectorData

数据经过清洗、分块和增强后，最终需要存入数据库。Microsoft.Extensions.VectorData 库通过提供一套统一的抽象层，解决了向量数据库市场的碎片化问题 。

7.1 IVectorStore 接口：统一的 CRUD 与检索

核心接口 IVectorStore 及其相关组件（IVectorStoreRecordCollection）定义了与向量数据库交互的标准契约。这意味着上层应用逻辑不需要关心底层是 Qdrant、Redis 还是 SQL Server。

主要功能包括：

  • Schema 定义：通过 VectorStoreRecordDefinition 或属性标签（Attributes）定义数据模型，指定哪些字段是主键（Key）、数据（Data）或向量（Vector）15。
  • CRUD 操作：标准的增删改查 API。
  • 向量搜索：支持余弦相似度、欧几里得距离等多种度量方式。
  • 混合搜索与过滤：支持结合元数据过滤（例如 Category == 'Report'）的向量搜索 15。

7.2 VectorStoreWriter：智能写入器

VectorStoreWriter<T> 是连接摄取管道与存储层的桥梁。它不仅仅是一个简单的 DAO（Data Access Object），还包含了一些关键的业务逻辑：

  1. 自动嵌入生成（Automatic Embedding Generation）：
    如果在管道中只传递了文本分块而没有生成向量，VectorStoreWriter 可以配置一个 IEmbeddingGenerator。在写入数据库之前，它会自动调用嵌入模型生成向量。这大大简化了管道配置，将嵌入生成的责任委托给了写入阶段 4。
  2. 增量更新与幂等性：
    在 RAG 系统中，文档经常会被修改和重新上传。VectorStoreWriter 实现了智能的更新逻辑：在写入新分块之前，它会根据文档 ID 删除该文档旧版本的所有分块。这确保了数据库中不会残留过期的、导致幻觉的旧数据片段（Orphaned Chunks），保证了知识库的时效性和一致性 8。

7.3 广泛的连接器生态

得益于与 Semantic Kernel 团队的紧密合作，Microsoft.Extensions.VectorData 在发布之初就拥有了丰富的连接器支持。这些连接器以 Microsoft.SemanticKernel.Connectors.* 的形式发布，但实现了新的 VectorData 接口 17。

支持的向量存储 NuGet 包名称 典型应用场景
Qdrant Microsoft.SemanticKernel.Connectors.Qdrant 高性能、生产级开源向量数据库
Azure AI Search Microsoft.SemanticKernel.Connectors.AzureAISearch 企业级、全托管、支持混合检索
Redis Microsoft.SemanticKernel.Connectors.Redis 极低延迟的实时检索场景
PostgreSQL Microsoft.SemanticKernel.Connectors.PgVector 关系型数据与向量数据混合存储
SQLite Microsoft.SemanticKernel.Connectors.SqliteVec 本地开发、边缘计算、离线应用
Azure Cosmos DB Microsoft.SemanticKernel.Connectors.Cosmos* 大规模分布式存储
InMemory Microsoft.SemanticKernel.Connectors.InMemory 单元测试、快速原型验证

特别是 SQLite 连接器 (SqliteVec)：这是一个非常重要的补充。它利用 sqlite-vec 扩展，使得.NET 开发者可以在没有任何外部数据库依赖的情况下，在本地构建全功能的 RAG 应用。这对于移动应用、桌面应用或开发测试环境具有巨大的价值 4。

8. 与 Semantic Kernel 的融合与迁移

对于现有的 Semantic Kernel (SK) 用户，这套新库代表了未来的方向。

8.1 从 Memory 到 VectorData 的演进

在早期的 Semantic Kernel 版本中，向量存储是通过 Microsoft.SemanticKernel.Memory.IMemoryStore 接口管理的。这个旧抽象存在一些设计上的局限性，例如强制固定的 Schema（ID, Text, Vector），难以支持复杂的元数据过滤或自定义的数据结构。

新的 Microsoft.Extensions.VectorData.IVectorStore 提供了更泛型、更灵活的设计：

  • 支持自定义 POCO (Plain Old CLR Object) 作为记录模型。
  • 支持更复杂的查询和过滤语法。
  • 解耦了 Semantic Kernel 的核心编排逻辑，使其可以独立使用 20。

8.2 迁移指南

微软明确建议开发者迁移到新的抽象层。迁移的主要工作包括：

  1. 包替换：将旧的 Microsoft.SemanticKernel.Connectors.* 包升级到最新版本。
  2. 代码重构：将依赖 IMemoryStore 的代码改为依赖 IVectorStore。
  3. 命名空间更新：注意包名和类名的变化，例如 Sqlite 连接器更名为 SqliteVec，以明确其使用了向量扩展 。

Semantic Kernel 团队已经完成了底层工作，确保新版本的 SK 连接器完全实现了 VectorData 抽象，因此对于使用 SK 高级功能的开发者，这种底层替换是相对平滑的 14。

9. 实战案例分析：.NET AI Chat 模板

为了展示这些构建模块的综合运用，微软发布了 .NET AI Chat Template (dotnet new aichatweb)。这是一个参考架构，展示了如何将上述所有组件串联起来构建一个端到端的 RAG 应用 。

9.1 架构流程解析

该模板项目演示了一个典型的 RAG 工作流：

  1. 数据源层：
    • 模板默认包含 PDF 示例文件，位于 /wwwroot/Data 目录。
    • 使用 PDFReader (基于 MarkItDown) 将 PDF 解析为 IngestionDocument。
  2. 处理管道层：
    • 构建 IngestionPipeline。
    • 应用 SemanticSimilarityChunker 对文本进行智能分块。
    • 使用 Microsoft.Extensions.AI 进行嵌入生成。
  3. 存储层：
    • 默认配置使用 SqliteVectorStore 进行本地存储，方便开发者“开箱即用”而无需配置云资源。
    • 同时也支持通过配置切换到 Azure AI Search 进行生产部署 23。
  4. 应用层：
    • 基于 Blazor 的前端界面。
    • 后端服务接收用户提问，通过 IVectorStore 检索相关分块。
    • 将检索到的上下文注入到 Prompt 中，调用 Chat Client 生成回答。
    • 支持“引用跟踪”，即在回答中标记出信息来源（引用了哪个文件的哪一段）23。

9.2 定制与扩展

该模板不仅是一个示例，更是一个脚手架。开发者可以通过简单的配置修改（如更换 Vector Store 提供商），或者通过代码扩展（如添加自定义的 IngestionDocumentProcessor 来处理特定行业的文档格式）来快速构建垂直领域的 AI 应用。例如，结合 Auth0 等身份认证服务，可以在检索层实现基于用户权限的文档隔离（Document-level Authorization），确保数据安全 25。

10. 结论

Microsoft.Extensions.DataIngestion 和 Microsoft.Extensions.VectorData 的发布，不仅仅是几个 NuGet 包的更新，它代表了.NET 在 AI 时代的自我革新。

通过提供 统一的文档对象模型，微软解决了数据源异构的痛点；通过 流式管道架构，解决了大规模数据处理的性能瓶颈；通过 语义分块与 AI 增强，提升了 RAG 系统的智能高度；通过 标准化的向量存储抽象，构建了开放且兼容的数据库生态。

对于企业架构师而言，这意味着现在可以使用成熟、类型安全且高性能的 C# 代码来构建复杂的 AI 数据基础设施，而不再需要依赖不熟悉的 Python 工具链或不稳定的实验性脚本。随着.NET 10 的临近以及 AI 生态的持续演进，掌握这些构建模块将成为每一位.NET 开发者的核心竞争力。现在，正是构建下一代智能应用的最佳时机。

引用的著作

  1. Introducing Data Ingestion Building Blocks (Preview) - .NET Blog https://devblogs.microsoft.com/dotnet/introducing-data-ingestion-building-blocks-preview/
  2. Data ingestion - .NET | Microsoft Learn,https://learn.microsoft.com/en-us/dotnet/ai/conceptual/data-ingestion
  3. Microsoft.Extensions.DataIngestion Namespace, https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dataingestion?view=net-10.0-pp
  4. Microsoft.Extensions.DataIngestion.MarkItDown 10.1.1-preview.1.25612.2
  5. https://libraries.io/nuget/Microsoft.Extensions.DataIngestion.MarkItDown
  6. Using IngestionPipeline for content not originating from the file system · Issue #7082 · dotnet/extensions https://github.com/dotnet/extensions/issues/7082
  7. Luis Quintanilla, Author at .NET Blog - Microsoft Developer Blogs, https://devblogs.microsoft.com/dotnet/author/luquinta/feed/
  8. IngestionChunkerOptions.OverlapTokens Property https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dataingestion.ingestionchunkeroptions.overlaptokens?view=net-10.0-pp
  9. SummaryEnricher Class (Microsoft.Extensions.DataIngestion) https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dataingestion.summaryenricher?view=net-10.0-pp
  10. KeywordEnricher Class (Microsoft.Extensions.DataIngestion) https://learn.microsoft.com/dotnet/api/microsoft.extensions.dataingestion.keywordenricher
  11. KeywordEnricher Class (Microsoft.Extensions.DataIngestion) https://learn.microsoft.com/ko-kr/dotnet/api/microsoft.extensions.dataingestion.keywordenricher?view=net-10.0-pp
  12. Introducing Microsoft.Extensions.VectorData Preview - .NET Blog https://devblogs.microsoft.com/dotnet/introducing-microsoft-extensions-vector-data/
  13. Microsoft.Extensions.VectorData.Abstractions: Now Available | Semantic Kernel https://devblogs.microsoft.com/semantic-kernel/microsoft-extensions-vectordata-abstractions-now-available/
  14. Microsoft.Extensions.VectorData.Abstractions 9.7.0 - NuGet,https://www.nuget.org/packages/Microsoft.Extensions.VectorData.Abstractions/
  15. Vector Store changes ， https://learn.microsoft.com/en-us/semantic-kernel/support/migration/vectorstore-april-2025
  16. Vector Data Extensions are now Generally Available (GA) | Semantic Kernel https://devblogs.microsoft.com/semantic-kernel/vector-data-extensions-are-now-generally-available-ga/
  17. NET AI Template Now Available in Preview - Microsoft Dev Blogs,https://devblogs.microsoft.com/dotnet/announcing-dotnet-ai-template-preview1/
  18. Preview 2 of the .NET AI Template Now Available - Microsoft Dev Blogs, 访问时间为 十二月 25, 2025， https://devblogs.microsoft.com/dotnet/announcing-dotnet-ai-template-preview2/
  19. Quickstart - Create a .NET AI app using the AI app template https://learn.microsoft.com/en-us/dotnet/ai/quickstarts/ai-templates
  20. Secure a .NET RAG System with Auth0 FGA, https://auth0.com/blog/secure-dotnet-rag-system-with-auth0-fga/
  21. Build a .NET AI vector search app - Microsoft Learn https://learn.microsoft.com/en-us/dotnet/ai/quickstarts/build-vector-search-app
posted @ 2025-12-27 10:52  张善友  阅读(25)  评论(1)    收藏  举报