企业官网建设流程全解析

企业网站功效,自己做免费的网站,合肥集团网站建设,网站导航固定代码1. 摘要 随着生成式人工智能#xff08;Generative AI#xff09;技术的迅猛发展#xff0c;企业级应用开发正经历着一场深刻的范式转变。传统的事务处理系统正在向基于大语言模型#xff08;LLM#xff09;的智能系统演进#xff0c;其中检索增强生成#xff08;RAGGenerative 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 生态系统中过去缺乏一套统一的标准来处理这一复杂的 ETLExtract, Transform, Load流程。开发者不得不依赖零散的第三方库来解析 PDF手写逻辑来切分文本并硬编码特定向量数据库的 SDK。这种碎片化的开发模式导致了代码的高耦合、低复用以及维护困难。Microsoft.Extensions.DataIngestion 的推出正是为了填补这一空白它提供了一套标准化的原语使数据处理像 ASP.NET Core 中的依赖注入或日志记录一样成为一种基础设施能力2。2.2 模块化与解耦的设计哲学微软此次推出的构建模块遵循了高度模块化和解耦的设计哲学。与封闭的“黑盒”解决方案不同这些库被设计为一系列可组合的原子组件。读取器Readers负责屏蔽数据源的差异无论是本地文件、云存储还是内存流都被规范化为统一的格式。处理器Processors充当管道中的中间件利用 AI 能力对数据进行增强如自动生成摘要或提取关键词。分块器Chunkers基于精确的 Token 计算策略将长文档切分为适合 LLM 上下文窗口的片段。写入器Writers处理数据的持久化特别是向向量数据库的写入 1。这种设计不仅提高了代码的可测试性还赋予了开发者极大的灵活性。例如开发者可以轻松地替换底层的向量数据库而无需重写上层的数据处理逻辑或者在管道中插入自定义的隐私清洗步骤而不影响后续的嵌入生成。这种架构的弹性是构建“未来就绪”Future-readyAI 应用的基石。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 TextMarkdown 保留了文档的层级结构信息这对于后续的“语义分块”至关重要。相比于 HTML 或 XMLMarkdown 的 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. 数据摄取管道架构流式、弹性与中间件IngestionPipelineT 类是整个数据处理流程的指挥官。它不仅负责按顺序调用组件还封装了复杂的并发控制、错误处理和资源管理逻辑。4.1 管道组合与依赖注入IngestionPipeline 的构造遵循了依赖注入DI的最佳实践。它要求在实例化时注入核心组件Reader, Chunker, Writer。这种设计使得管道本身是无状态的且高度可配置。// 管道实例化代码结构示例using IngestionPipelinestring pipeline new(reader,chunker,writer,loggerFactory: loggerFactory){// 配置文档级处理器中间件DocumentProcessors { imageAlternativeTextEnricher },/* by 01022.hk - online tools website : 01022.hk/zh/jsonzip.html */ // 配置分块级处理器中间件 ChunkProcessors \ { summaryEnricher }};通过属性初始化器Object Initializer配置 DocumentProcessors 和 ChunkProcessors 的方式类似于 ASP.NET Core 中的中间件管道构建。这允许开发者在核心流程的前后插入任意数量的自定义逻辑例如在分块前进行 PII个人敏感信息清洗或者在分块后进行关键词提取。4.2 流式处理机制IAsyncEnumerable在处理大规模语料库如数百万份合同文件时内存管理是首要挑战。IngestionPipeline.ProcessAsync 方法的设计充分考虑了这一点它返回 IAsyncEnumerableIngestionResult。这种设计意味着管道是流式Streaming执行的。系统不会一次性将所有文档加载到内存中而是采用“拉取”模式处理完一个文档释放相关内存再处理下一个。这使得在有限内存的容器环境中运行大规模 ETL 任务成为可能。下游的消费端Consumer可以通过 await foreach 逐个获取处理结果实现实时的进度反馈或即时的索引更新。4.3 弹性设计部分成功模式在分布式系统和大规模批处理任务中部分故障是常态。某个特定的 PDF 文件可能损坏或者某个网络调用如调用 OpenAI API 生成摘要可能超时。IngestionPipeline 采用了“部分成功”的设计模式。单个文档的处理失败不会导致整个管道抛出异常并终止。相反管道会捕获该文档处理过程中的异常将其封装在 IngestionResult 对象中包含 Succeeded 布尔标志和 DocumentId并记录错误日志然后继续处理下一个文档 1。这种设计对于长时间运行的后台任务至关重要。它确保了 99.9% 的正常文档能够被正确索引而那 0.1% 的失败文档可以通过日志被识别并单独重试极大地提高了系统的整体可用性和鲁棒性。4.4 泛型 T 的意义值得注意的是 IngestionPipelineT 中的泛型 T。虽然最常见的场景是 T 为 string处理文本数据但这种泛型设计为未来留出了空间。理论上它可以支持 IngestionChunkImage 或其他多模态数据类型只要相应的 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};// 实例化语义分块器注入嵌入生成器IngestionChunkerstring chunker new SemanticSimilarityChunker(embeddingGenerator,chunkerOptions);适用场景会议记录、长篇叙事文章、散文、对话记录等缺乏明确标题结构的流式文本。优势生成的块具有高度的语义内聚性Cohesion检索出来的片段往往是一个完整的话题极大地提升了 RAG 的回答质量。6. 智能增强层从 ETL 到 AI-ETL单纯的文本切分只是第一步。为了让数据更容易被检索Microsoft.Extensions.DataIngestion 引入了AI 增强AI Enrichment的概念。通过在管道中插入由 LLM 驱动的处理器可以在数据入库前对其进行“智力加工”。6.1 内置丰富器Enrichers详解这些丰富器实现了 IngestionChunkProcessorT 或 IngestionDocumentProcessor 接口可以直接插入管道。SummaryEnricher摘要丰富器功能对每个分块Chunk调用 LLM 生成一段简短的摘要 1。架构价值双路检索系统可以同时索引原始文本和摘要。有时候用户的查询更匹配摘要的概括性描述而不是原文的细节。上下文压缩在生成阶段如果上下文窗口紧张可以只将摘要发送给 LLM而不是原始的长文本。KeywordEnricher关键词丰富器功能分析分块内容提取出关键实体Entities或术语 1。架构价值支持混合检索Hybrid Search。向量检索擅长语义匹配但对于专有名词如产品型号“X-2000”可能不够精确。通过提取关键词并存储在元数据中可以在查询时结合倒排索引关键词匹配和向量索引大幅提升召回率。ImageAlternativeTextEnricher图像描述丰富器功能调用多模态模型如 GPT-4 Vision分析文档中的图片生成文本描述Alt Text4。架构价值填补了传统文本 RAG 的盲区。使得图片内容变得“可搜索”。例如用户搜索“Q3 销售趋势”系统可以通过图片的 Alt Text 检索到包含趋势图的幻灯片页面。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或向量Vector15。CRUD 操作标准的增删改查 API。向量搜索支持余弦相似度、欧几里得距离等多种度量方式。混合搜索与过滤支持结合元数据过滤例如 Category Report的向量搜索 15。7.2 VectorStoreWriter智能写入器VectorStoreWriterT 是连接摄取管道与存储层的桥梁。它不仅仅是一个简单的 DAOData Access Object还包含了一些关键的业务逻辑自动嵌入生成Automatic Embedding Generation如果在管道中只传递了文本分块而没有生成向量VectorStoreWriter 可以配置一个 IEmbeddingGenerator。在写入数据库之前它会自动调用嵌入模型生成向量。这大大简化了管道配置将嵌入生成的责任委托给了写入阶段 4。增量更新与幂等性在 RAG 系统中文档经常会被修改和重新上传。VectorStoreWriter 实现了智能的更新逻辑在写入新分块之前它会根据文档 ID 删除该文档旧版本的所有分块。这确保了数据库中不会残留过期的、导致幻觉的旧数据片段Orphaned Chunks保证了知识库的时效性和一致性 8。7.3 广泛的连接器生态得益于与 Semantic Kernel 团队的紧密合作Microsoft.Extensions.VectorData 在发布之初就拥有了丰富的连接器支持。这些连接器以 Microsoft.SemanticKernel.Connectors.* 的形式发布但实现了新的 VectorData 接口 17。支持的向量存储NuGet 包名称典型应用场景QdrantMicrosoft.SemanticKernel.Connectors.Qdrant高性能、生产级开源向量数据库Azure AI SearchMicrosoft.SemanticKernel.Connectors.AzureAISearch企业级、全托管、支持混合检索RedisMicrosoft.SemanticKernel.Connectors.Redis极低延迟的实时检索场景PostgreSQLMicrosoft.SemanticKernel.Connectors.PgVector关系型数据与向量数据混合存储SQLiteMicrosoft.SemanticKernel.Connectors.SqliteVec本地开发、边缘计算、离线应用Azure Cosmos DBMicrosoft.SemanticKernel.Connectors.Cosmos*大规模分布式存储InMemoryMicrosoft.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 接口管理的。这个旧抽象存在一些设计上的局限性例如强制固定的 SchemaID, Text, Vector难以支持复杂的元数据过滤或自定义的数据结构。新的 Microsoft.Extensions.VectorData.IVectorStore 提供了更泛型、更灵活的设计支持自定义 POCO (Plain Old CLR Object) 作为记录模型。支持更复杂的查询和过滤语法。解耦了 Semantic Kernel 的核心编排逻辑使其可以独立使用 20。8.2 迁移指南微软明确建议开发者迁移到新的抽象层。迁移的主要工作包括包替换将旧的 Microsoft.SemanticKernel.Connectors.* 包升级到最新版本。代码重构将依赖 IMemoryStore 的代码改为依赖 IVectorStore。命名空间更新注意包名和类名的变化例如 Sqlite 连接器更名为 SqliteVec以明确其使用了向量扩展 。Semantic Kernel 团队已经完成了底层工作确保新版本的 SK 连接器完全实现了 VectorData 抽象因此对于使用 SK 高级功能的开发者这种底层替换是相对平滑的 14。9. 实战案例分析.NET AI Chat 模板为了展示这些构建模块的综合运用微软发布了.NET AI Chat Template(dotnet new aichatweb)。这是一个参考架构展示了如何将上述所有组件串联起来构建一个端到端的 RAG 应用 。9.1 架构流程解析该模板项目演示了一个典型的 RAG 工作流数据源层模板默认包含 PDF 示例文件位于 /wwwroot/Data 目录。使用 PDFReader (基于 MarkItDown) 将 PDF 解析为 IngestionDocument。处理管道层构建 IngestionPipeline。应用 SemanticSimilarityChunker 对文本进行智能分块。使用 Microsoft.Extensions.AI 进行嵌入生成。存储层默认配置使用 SqliteVectorStore 进行本地存储方便开发者“开箱即用”而无需配置云资源。同时也支持通过配置切换到 Azure AI Search 进行生产部署 23。应用层基于 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 开发者的核心竞争力。现在正是构建下一代智能应用的最佳时机。引用的著作Introducing Data Ingestion Building Blocks (Preview) - .NET Blog https://devblogs.microsoft.com/dotnet/introducing-data-ingestion-building-blocks-preview/Data ingestion - .NET | Microsoft Learn,https://learn.microsoft.com/en-us/dotnet/ai/conceptual/data-ingestionMicrosoft.Extensions.DataIngestion Namespace, https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dataingestion?viewnet-10.0-ppMicrosoft.Extensions.DataIngestion.MarkItDown 10.1.1-preview.1.25612.2https://libraries.io/nuget/Microsoft.Extensions.DataIngestion.MarkItDownUsing IngestionPipeline for content not originating from the file system · Issue #7082 · dotnet/extensions https://github.com/dotnet/extensions/issues/7082Luis Quintanilla, Author at .NET Blog - Microsoft Developer Blogs, https://devblogs.microsoft.com/dotnet/author/luquinta/feed/IngestionChunkerOptions.OverlapTokens Property https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dataingestion.ingestionchunkeroptions.overlaptokens?viewnet-10.0-ppSummaryEnricher Class (Microsoft.Extensions.DataIngestion) https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dataingestion.summaryenricher?viewnet-10.0-ppKeywordEnricher Class (Microsoft.Extensions.DataIngestion) https://learn.microsoft.com/dotnet/api/microsoft.extensions.dataingestion.keywordenricherKeywordEnricher Class (Microsoft.Extensions.DataIngestion) https://learn.microsoft.com/ko-kr/dotnet/api/microsoft.extensions.dataingestion.keywordenricher?viewnet-10.0-ppIntroducing Microsoft.Extensions.VectorData Preview - .NET Blog https://devblogs.microsoft.com/dotnet/introducing-microsoft-extensions-vector-data/Microsoft.Extensions.VectorData.Abstractions: Now Available | Semantic Kernel https://devblogs.microsoft.com/semantic-kernel/microsoft-extensions-vectordata-abstractions-now-available/Microsoft.Extensions.VectorData.Abstractions 9.7.0 - NuGet,https://www.nuget.org/packages/Microsoft.Extensions.VectorData.Abstractions/Vector Store changes https://learn.microsoft.com/en-us/semantic-kernel/support/migration/vectorstore-april-2025Vector Data Extensions are now Generally Available (GA) | Semantic Kernel https://devblogs.microsoft.com/semantic-kernel/vector-data-extensions-are-now-generally-available-ga/NET AI Template Now Available in Preview - Microsoft Dev Blogs,https://devblogs.microsoft.com/dotnet/announcing-dotnet-ai-template-preview1/Preview 2 of the .NET AI Template Now Available - Microsoft Dev Blogs, 访问时间为 十二月 25, 2025 https://devblogs.microsoft.com/dotnet/announcing-dotnet-ai-template-preview2/Quickstart - Create a .NET AI app using the AI app template https://learn.microsoft.com/en-us/dotnet/ai/quickstarts/ai-templatesSecure a .NET RAG System with Auth0 FGA, https://auth0.com/blog/secure-dotnet-rag-system-with-auth0-fga/Build a .NET AI vector search app - Microsoft Learn https://learn.microsoft.com/en-us/dotnet/ai/quickstarts/build-vector-search-app欢迎大家扫描下面二维码成为我的客户扶你上云