用 dlt Qdrant 构建 FAQ 向量检索流水线从数据加载到嵌入落库全解析【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp本文围绕 LLM Zoomcamp 2025 workshop 中「dlt Qdrant 数据加载」这一主题展开以 FAQ 文档为数据源使用dlt.resource声明数据资源、用qdrant目标destination将数据连同自动生成的嵌入向量写入本地 Qdrant 存储并通过pipeline.last_trace与meta.json完成加载结果与嵌入模型的核验。读完本文你将掌握如何把任意生成器函数改造成 dlt 资源、如何搭建一个本地持久化的 Qdrant 向量库、如何从 pipeline 追踪信息与目标目录的元数据中反查插入行数与所用嵌入模型——这也是该 workshop 课后作业homework的核心考核点。在 LLM Zoomcamp 2025 的 workshop「From REST to reasoning: ingest, index, and query with dlt and Cognee」中讲师演示了如何用 dltdata load tool打通「抓取 FAQ → 清洗/标注 → 向量化 → 落库 Qdrant」的完整链路。本篇以 cohorts/2025/workshops/dlt.md 文档为骨架结合仓库中 cohorts/2025/workshops/dlt/ 目录下的配套源码filesystem_pipeline.py、mount_cognee.py、search_knowledge_graph.ipynb、api_spec_ontology.owl等逐段还原 dlt 管线的搭建与验证过程并深入源码解释其背后的机制。一、技术背景为什么用 dlt 做 RAG 数据接入RAG 系统上线前最耗时的一步往往不是检索或生成而是把散落各处的数据源稳定地变成可检索的向量库。FAQ 页面、API 文档、本地 JSONL 日志、第三方 REST 接口……它们的格式、嵌套层级、更新频率各不相同而向量库要求数据是「干净、扁平、带嵌入」的结构化记录。dltdata load tool正是一个面向这类场景的 Python 数据加载框架它把「声明数据源 → 定义目标 → 增量加载 → schema 规范化」封装成一套统一 API。在本仓库配套的 2026 版 workshop 文档见 cohorts/2026/workshops/dlt.md中dlt 还被用于把 Claude Code / Codex 的本地 JSONL 会话日志管道化进 DuckDB 并做 marimo 可视化可见其定位就是通用的「任意来源 → 任意目标」数据管道层。本次 2025 workshop 的应用场景非常具体数据源DataTalks.Club 各课程的 FAQdocuments.json结构为course → documents[]数据处理给每条 FAQ 记录打上所属课程标签doc[course] course_name目标Qdrant 本地持久化目录db.qdrant并在写入时自动为每条记录生成嵌入向量。二、环境准备安装带 Qdrant 支持的 dltworkshop 文档给出了安装命令pip install -q dlt[qdrant] qdrant-client[fastembed]这里包含两部分包作用dlt[qdrant]dlt 主框架 Qdrant destination 所需依赖与 Qdrant 服务端/本地存储通信的客户端等qdrant-client[fastembed]Qdrant 官方 Python 客户端[fastembed]附加项引入 fastembed 嵌入库用于在数据加载阶段自动计算文本向量安装后第一步作业Question 1就是让学员执行pip show dlt或pip list确认安装到的 dlt 版本号——版本号会随发布节奏变化因此作业要求以你实际安装到的版本为准。三、用 dlt.resource 声明 FAQ 数据资源3.1 原始数据抓取函数文档给出了一个从远程 JSON 读取 FAQ 数据的辅助函数def zoomcamp_data(): docs_url https://github.com/alexeygrigorev/llm-rag-workshop/raw/main/notebooks/documents.json docs_response requests.get(docs_url) documents_raw docs_response.json() for course in documents_raw: course_name course[course] for doc in course[documents]: doc[course] course_name yield doc要点documents_raw是课程列表每个元素形如{course: data-engineering-zoomcamp, documents: [...]}内层循环把课程名写入每条 FAQ 记录的course字段实现扁平化 标签化函数是生成器逐条yield适合 dlt 的分批加载与断点续传。仓库中 cohorts/2025/01-intro/documents.json 展示了同类 FAQ 数据的真实形态每条记录含text正文、section章节、question问题标题等字段加载时这些字段会作为列进入目标表。3.2 用装饰器升级为 dlt 资源文档要求给这个函数加上dlt.resource装饰器之后它才能直接作为pipeline.run(...)的数据来源import dlt dlt.resource def zoomcamp_data(): # ... 上述生成器逻辑 ... yield docdlt.resource是 dlt 声明式 API 的核心入口。从仓库配套代码可以印证它的常见用法在 filesystem_pipeline.py 中get_data同样被dlt.resource(table_nameapi_source_docs, max_table_nesting0)装饰通过参数指定目标表名、关闭深层嵌套展开在 2026 版 workshop 的 code/filesystem_pipeline.py 中则用dlt.transformer把文件读取器与filesystem()资源通过|管道符组合。也就是说dlt.resource装饰一个可迭代对象即可成为资源资源之间还能用|组合成更复杂的转换链——本次作业只需单个资源故直接装饰即可。四、创建 pipeline 并加载到 Qdrant4.1 声明 Qdrant destination文档给出了目标定义方式from dlt.destinations import qdrant qdrant_destination qdrant( qd_pathdb.qdrant, )关键参数说明qd_pathdb.qdrant指定 Qdrant 数据的本地存储路径。dlt 会告知 Qdrant「以本地目录模式启动」所有向量数据落在名为db.qdrant的文件夹内无需额外启动 Qdrant 服务端进程对本地开发/作业场景最友好若你的环境已有独立的 Qdrant 服务端也可以改为连接地址形式如qdrant(url..., api_key...)但本次作业以本地目录为准。4.2 定义并运行 pipelinepipeline dlt.pipeline( pipeline_namezoomcamp_pipeline, destinationqdrant_destination, dataset_namezoomcamp_tagged_data ) load_info pipeline.run(zoomcamp_data()) print(pipeline.last_trace)三个关键字段逐一说明字段含义备注pipeline_name管道名dlt 用它管理状态、schema 与增量信息同一管道重复运行会复用状态配合write_disposition决定追加/替换destination目标即上一步的qdrant_destination本地目录模式写入db.qdrantdataset_name数据集名dlt 在目标中按数据集组织表文档中为zoomcamp_tagged_data作业答案关注的是资源对应的 collectionpipeline.run()会依次完成normalize规范化 schema→ load加载到目标并返回LoadInfo。此时输出pipeline.last_trace其last_normalize_info中会包含一行Normalized data for the following tables:并在下方列出每个表插入的行数——这正是作业 Question 2 要求「在 trace 输出中查找该行」的原因。4.3 从源码看 dlt 管道的真实运行轨迹仓库中 filesystem_pipeline.py 展示了同一套 API 的另一种落地方式本地文件系统 destinationpipeline dlt.pipeline( pipeline_nameapi_doc_sources_pipeline, dataset_nameapi_sources, destinationfilesystem ) info pipeline.run(get_data(source_locations), loader_file_formatcsv)对照可见 dlt 的一致抽象无论目标是 Qdrant、DuckDB 还是本地文件系统dlt.pipeline(...)pipeline.run(resource)的调用形态完全相同区别只在于 destination 的参数与加载选项如loader_file_formatcsv、table_name、write_disposition。在 2026 版 code/filesystem_pipeline.py 中还能看到更完整的选项组合pipeline dlt.pipeline( pipeline_nameagent_logs, destinationduckdb, dataset_nameagent_logs, dev_modesample, ) info pipeline.run( build_resources(samplesample), table_nameTABLE_NAME, write_dispositionreplace, ) print(info) print(pipeline.last_trace.last_normalize_info)其中write_disposition控制写入策略replace覆盖 /append追加 /merge按主键合并pipeline.last_trace.last_normalize_info则直接暴露规范化统计——作业中要求打印pipeline.last_trace并检索Normalized data for the following tables:正是基于这一结构。五、验证加载结果与嵌入模型5.1 行数验证Question 2运行 pipeline 后观察控制台print(pipeline.last_trace)的输出找到Normalized data for the following tables:段落读取zoomcamp_datacollection即资源对应的表下方标注的数字即为插入行数。注意文档强调这个数字取决于documents.json中 FAQ 记录的总条数如果数据源更新答案会随之变化因此要以你实际运行输出的 trace 为准。5.2 嵌入模型验证Question 3写入过程中 dlt 的 Qdrant destination 会自动调用嵌入模型生成向量。要确认用的是哪个模型运行后在工作目录下会生成db.qdrant文件夹进入该文件夹找到meta.json打开meta.json其中的嵌入模型字段如embedding_model/ model 名称相关配置会写明实际使用的模型名。原理说明qdrant-client[fastembed]安装时引入了 fastembed 库dlt 的 Qdrant destination 在加载数据时使用 fastembed 默认嵌入模型完成文本→向量转换meta.json由 Qdrant 在创建本地集合时写入用于记录集合的元数据向量维度、距离函数、嵌入模型等。仓库中 search_knowledge_graph.ipynb 的运行日志印证了同类链路其中可见openai/text-embedding-3-large被用于文本嵌入POST https://api.openai.com/v1/embeddings——不同 workshop 环节因配置不同会使用不同嵌入模型所以作业要求以你自己目录中meta.json的记载为准而不是照抄某个固定答案。六、workshop 完整脉络从「数据管道」到「知识图谱检索」为帮助理解本作业在整个 workshop 中的位置这里补充 2025 workshop 目录 cohorts/2025/workshops/dlt/ 提供的配套代码所对应的完整链路阶段一dlt 加载原始文档本次作业主题——filesystem_pipeline.py演示如何把data_samples/下的 API 文档站点页面api.slack.com、developer.monday.com、developer.paypal.com、developer.ticketmaster.com等逐个读入并导出为 CSV与作业中「FAQ → Qdrant」是同一套 dlt 声明式 API 的两种目标形态阶段二挂载知识图谱引擎——mount_cognee.py把加载好的数据cognee.add(...)进 Cognee再cognee.cognify()生成知识图谱若提供 api_spec_ontology.owl还会按该本体含Resource类、hasResource对象属性、auth_type/cursor_param/default_page_size等 API 描述属性进行语义化认知阶段三图谱检索——search_knowledge_graph.ipynb用cognee.search(query_text..., query_typeSearchType.GRAPH_COMPLETION, node_typeNodeSet, node_name[...])在指定节点集内做图补全式检索例如询问「Ticketmaster API 有哪些具体 endpoint」。可以看到dlt 承担的是**最上游的「把非结构化/半结构化原始数据变成结构化数据」**这一职责向量库Qdrant与知识图谱Cognee只是它的下游消费者。本次作业聚焦阶段一的 Qdrant 落库正是为了让你先掌握 dlt 这条「数据入场通道」。七、作业自查清单与常见问题检查项操作方法判定依据dlt 版本pip show dlt记录实际安装版本号插入行数print(pipeline.last_trace)看Normalized data for the following tables:下zoomcamp_data的行数嵌入模型打开db.qdrant/meta.json看其中 embedding/model 字段常见坑位提示db.qdrant目录找不到确认当前工作目录与运行脚本的目录一致且 pipeline 的qd_path用的是相对路径trace 里没有Normalized data for the following tables:确认pipeline.run(zoomcamp_data())传入的是被dlt.resource装饰后的资源而非原始生成器函数数据源变化导致答案不同documents.json由远端 URL 提供若源数据更新行数与嵌入结果会变化请以本次运行输出为准。八、总结通过本 workshop你完成了一条最小可用的「FAQ → 向量库」数据管线用dlt.resource把抓取函数声明为可加载资源用qdrant(qd_pathdb.qdrant)声明本地持久化目标用dlt.pipeline(...).run(...)一键完成规范化与加载并借助pipeline.last_trace与db.qdrant/meta.json两个证据点核验「插入了多少行、用了什么嵌入模型」。这套模式与仓库配套的filesystem_pipeline.py文件系统 destination、2026 版 workshop 的filesystem_pipeline.pyDuckDB destination一脉相承——理解 dlt 的 resource / pipeline / destination 三元组你就拥有了把任意数据源接入任意向量库的通用能力后续无论是切换成 Postgres、DuckDB还是接上 Cognee 知识图谱都只是更换 destination 与下游消费端的组合。进一步实践把本作业的zoomcamp_data换成你自己的知识库文档本地 Markdown、JSONL 日志或 REST 接口并将qd_path指向新目录即可复现完整流程若希望向量检索更贴近生产可在加载完成后用 Qdrant 的search接口对 FAQ 问题做相似度召回并与 LLM Zoomcamp 主课中的 RAG 问答如 cohorts/2025/02-vector-search/ 模块衔接形成完整的问答系统。【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 dlt + Qdrant 构建 FAQ 向量检索流水线：从数据加载到嵌入落库全解析
用 dlt Qdrant 构建 FAQ 向量检索流水线从数据加载到嵌入落库全解析【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp本文围绕 LLM Zoomcamp 2025 workshop 中「dlt Qdrant 数据加载」这一主题展开以 FAQ 文档为数据源使用dlt.resource声明数据资源、用qdrant目标destination将数据连同自动生成的嵌入向量写入本地 Qdrant 存储并通过pipeline.last_trace与meta.json完成加载结果与嵌入模型的核验。读完本文你将掌握如何把任意生成器函数改造成 dlt 资源、如何搭建一个本地持久化的 Qdrant 向量库、如何从 pipeline 追踪信息与目标目录的元数据中反查插入行数与所用嵌入模型——这也是该 workshop 课后作业homework的核心考核点。在 LLM Zoomcamp 2025 的 workshop「From REST to reasoning: ingest, index, and query with dlt and Cognee」中讲师演示了如何用 dltdata load tool打通「抓取 FAQ → 清洗/标注 → 向量化 → 落库 Qdrant」的完整链路。本篇以 cohorts/2025/workshops/dlt.md 文档为骨架结合仓库中 cohorts/2025/workshops/dlt/ 目录下的配套源码filesystem_pipeline.py、mount_cognee.py、search_knowledge_graph.ipynb、api_spec_ontology.owl等逐段还原 dlt 管线的搭建与验证过程并深入源码解释其背后的机制。一、技术背景为什么用 dlt 做 RAG 数据接入RAG 系统上线前最耗时的一步往往不是检索或生成而是把散落各处的数据源稳定地变成可检索的向量库。FAQ 页面、API 文档、本地 JSONL 日志、第三方 REST 接口……它们的格式、嵌套层级、更新频率各不相同而向量库要求数据是「干净、扁平、带嵌入」的结构化记录。dltdata load tool正是一个面向这类场景的 Python 数据加载框架它把「声明数据源 → 定义目标 → 增量加载 → schema 规范化」封装成一套统一 API。在本仓库配套的 2026 版 workshop 文档见 cohorts/2026/workshops/dlt.md中dlt 还被用于把 Claude Code / Codex 的本地 JSONL 会话日志管道化进 DuckDB 并做 marimo 可视化可见其定位就是通用的「任意来源 → 任意目标」数据管道层。本次 2025 workshop 的应用场景非常具体数据源DataTalks.Club 各课程的 FAQdocuments.json结构为course → documents[]数据处理给每条 FAQ 记录打上所属课程标签doc[course] course_name目标Qdrant 本地持久化目录db.qdrant并在写入时自动为每条记录生成嵌入向量。二、环境准备安装带 Qdrant 支持的 dltworkshop 文档给出了安装命令pip install -q dlt[qdrant] qdrant-client[fastembed]这里包含两部分包作用dlt[qdrant]dlt 主框架 Qdrant destination 所需依赖与 Qdrant 服务端/本地存储通信的客户端等qdrant-client[fastembed]Qdrant 官方 Python 客户端[fastembed]附加项引入 fastembed 嵌入库用于在数据加载阶段自动计算文本向量安装后第一步作业Question 1就是让学员执行pip show dlt或pip list确认安装到的 dlt 版本号——版本号会随发布节奏变化因此作业要求以你实际安装到的版本为准。三、用 dlt.resource 声明 FAQ 数据资源3.1 原始数据抓取函数文档给出了一个从远程 JSON 读取 FAQ 数据的辅助函数def zoomcamp_data(): docs_url https://github.com/alexeygrigorev/llm-rag-workshop/raw/main/notebooks/documents.json docs_response requests.get(docs_url) documents_raw docs_response.json() for course in documents_raw: course_name course[course] for doc in course[documents]: doc[course] course_name yield doc要点documents_raw是课程列表每个元素形如{course: data-engineering-zoomcamp, documents: [...]}内层循环把课程名写入每条 FAQ 记录的course字段实现扁平化 标签化函数是生成器逐条yield适合 dlt 的分批加载与断点续传。仓库中 cohorts/2025/01-intro/documents.json 展示了同类 FAQ 数据的真实形态每条记录含text正文、section章节、question问题标题等字段加载时这些字段会作为列进入目标表。3.2 用装饰器升级为 dlt 资源文档要求给这个函数加上dlt.resource装饰器之后它才能直接作为pipeline.run(...)的数据来源import dlt dlt.resource def zoomcamp_data(): # ... 上述生成器逻辑 ... yield docdlt.resource是 dlt 声明式 API 的核心入口。从仓库配套代码可以印证它的常见用法在 filesystem_pipeline.py 中get_data同样被dlt.resource(table_nameapi_source_docs, max_table_nesting0)装饰通过参数指定目标表名、关闭深层嵌套展开在 2026 版 workshop 的 code/filesystem_pipeline.py 中则用dlt.transformer把文件读取器与filesystem()资源通过|管道符组合。也就是说dlt.resource装饰一个可迭代对象即可成为资源资源之间还能用|组合成更复杂的转换链——本次作业只需单个资源故直接装饰即可。四、创建 pipeline 并加载到 Qdrant4.1 声明 Qdrant destination文档给出了目标定义方式from dlt.destinations import qdrant qdrant_destination qdrant( qd_pathdb.qdrant, )关键参数说明qd_pathdb.qdrant指定 Qdrant 数据的本地存储路径。dlt 会告知 Qdrant「以本地目录模式启动」所有向量数据落在名为db.qdrant的文件夹内无需额外启动 Qdrant 服务端进程对本地开发/作业场景最友好若你的环境已有独立的 Qdrant 服务端也可以改为连接地址形式如qdrant(url..., api_key...)但本次作业以本地目录为准。4.2 定义并运行 pipelinepipeline dlt.pipeline( pipeline_namezoomcamp_pipeline, destinationqdrant_destination, dataset_namezoomcamp_tagged_data ) load_info pipeline.run(zoomcamp_data()) print(pipeline.last_trace)三个关键字段逐一说明字段含义备注pipeline_name管道名dlt 用它管理状态、schema 与增量信息同一管道重复运行会复用状态配合write_disposition决定追加/替换destination目标即上一步的qdrant_destination本地目录模式写入db.qdrantdataset_name数据集名dlt 在目标中按数据集组织表文档中为zoomcamp_tagged_data作业答案关注的是资源对应的 collectionpipeline.run()会依次完成normalize规范化 schema→ load加载到目标并返回LoadInfo。此时输出pipeline.last_trace其last_normalize_info中会包含一行Normalized data for the following tables:并在下方列出每个表插入的行数——这正是作业 Question 2 要求「在 trace 输出中查找该行」的原因。4.3 从源码看 dlt 管道的真实运行轨迹仓库中 filesystem_pipeline.py 展示了同一套 API 的另一种落地方式本地文件系统 destinationpipeline dlt.pipeline( pipeline_nameapi_doc_sources_pipeline, dataset_nameapi_sources, destinationfilesystem ) info pipeline.run(get_data(source_locations), loader_file_formatcsv)对照可见 dlt 的一致抽象无论目标是 Qdrant、DuckDB 还是本地文件系统dlt.pipeline(...)pipeline.run(resource)的调用形态完全相同区别只在于 destination 的参数与加载选项如loader_file_formatcsv、table_name、write_disposition。在 2026 版 code/filesystem_pipeline.py 中还能看到更完整的选项组合pipeline dlt.pipeline( pipeline_nameagent_logs, destinationduckdb, dataset_nameagent_logs, dev_modesample, ) info pipeline.run( build_resources(samplesample), table_nameTABLE_NAME, write_dispositionreplace, ) print(info) print(pipeline.last_trace.last_normalize_info)其中write_disposition控制写入策略replace覆盖 /append追加 /merge按主键合并pipeline.last_trace.last_normalize_info则直接暴露规范化统计——作业中要求打印pipeline.last_trace并检索Normalized data for the following tables:正是基于这一结构。五、验证加载结果与嵌入模型5.1 行数验证Question 2运行 pipeline 后观察控制台print(pipeline.last_trace)的输出找到Normalized data for the following tables:段落读取zoomcamp_datacollection即资源对应的表下方标注的数字即为插入行数。注意文档强调这个数字取决于documents.json中 FAQ 记录的总条数如果数据源更新答案会随之变化因此要以你实际运行输出的 trace 为准。5.2 嵌入模型验证Question 3写入过程中 dlt 的 Qdrant destination 会自动调用嵌入模型生成向量。要确认用的是哪个模型运行后在工作目录下会生成db.qdrant文件夹进入该文件夹找到meta.json打开meta.json其中的嵌入模型字段如embedding_model/ model 名称相关配置会写明实际使用的模型名。原理说明qdrant-client[fastembed]安装时引入了 fastembed 库dlt 的 Qdrant destination 在加载数据时使用 fastembed 默认嵌入模型完成文本→向量转换meta.json由 Qdrant 在创建本地集合时写入用于记录集合的元数据向量维度、距离函数、嵌入模型等。仓库中 search_knowledge_graph.ipynb 的运行日志印证了同类链路其中可见openai/text-embedding-3-large被用于文本嵌入POST https://api.openai.com/v1/embeddings——不同 workshop 环节因配置不同会使用不同嵌入模型所以作业要求以你自己目录中meta.json的记载为准而不是照抄某个固定答案。六、workshop 完整脉络从「数据管道」到「知识图谱检索」为帮助理解本作业在整个 workshop 中的位置这里补充 2025 workshop 目录 cohorts/2025/workshops/dlt/ 提供的配套代码所对应的完整链路阶段一dlt 加载原始文档本次作业主题——filesystem_pipeline.py演示如何把data_samples/下的 API 文档站点页面api.slack.com、developer.monday.com、developer.paypal.com、developer.ticketmaster.com等逐个读入并导出为 CSV与作业中「FAQ → Qdrant」是同一套 dlt 声明式 API 的两种目标形态阶段二挂载知识图谱引擎——mount_cognee.py把加载好的数据cognee.add(...)进 Cognee再cognee.cognify()生成知识图谱若提供 api_spec_ontology.owl还会按该本体含Resource类、hasResource对象属性、auth_type/cursor_param/default_page_size等 API 描述属性进行语义化认知阶段三图谱检索——search_knowledge_graph.ipynb用cognee.search(query_text..., query_typeSearchType.GRAPH_COMPLETION, node_typeNodeSet, node_name[...])在指定节点集内做图补全式检索例如询问「Ticketmaster API 有哪些具体 endpoint」。可以看到dlt 承担的是**最上游的「把非结构化/半结构化原始数据变成结构化数据」**这一职责向量库Qdrant与知识图谱Cognee只是它的下游消费者。本次作业聚焦阶段一的 Qdrant 落库正是为了让你先掌握 dlt 这条「数据入场通道」。七、作业自查清单与常见问题检查项操作方法判定依据dlt 版本pip show dlt记录实际安装版本号插入行数print(pipeline.last_trace)看Normalized data for the following tables:下zoomcamp_data的行数嵌入模型打开db.qdrant/meta.json看其中 embedding/model 字段常见坑位提示db.qdrant目录找不到确认当前工作目录与运行脚本的目录一致且 pipeline 的qd_path用的是相对路径trace 里没有Normalized data for the following tables:确认pipeline.run(zoomcamp_data())传入的是被dlt.resource装饰后的资源而非原始生成器函数数据源变化导致答案不同documents.json由远端 URL 提供若源数据更新行数与嵌入结果会变化请以本次运行输出为准。八、总结通过本 workshop你完成了一条最小可用的「FAQ → 向量库」数据管线用dlt.resource把抓取函数声明为可加载资源用qdrant(qd_pathdb.qdrant)声明本地持久化目标用dlt.pipeline(...).run(...)一键完成规范化与加载并借助pipeline.last_trace与db.qdrant/meta.json两个证据点核验「插入了多少行、用了什么嵌入模型」。这套模式与仓库配套的filesystem_pipeline.py文件系统 destination、2026 版 workshop 的filesystem_pipeline.pyDuckDB destination一脉相承——理解 dlt 的 resource / pipeline / destination 三元组你就拥有了把任意数据源接入任意向量库的通用能力后续无论是切换成 Postgres、DuckDB还是接上 Cognee 知识图谱都只是更换 destination 与下游消费端的组合。进一步实践把本作业的zoomcamp_data换成你自己的知识库文档本地 Markdown、JSONL 日志或 REST 接口并将qd_path指向新目录即可复现完整流程若希望向量检索更贴近生产可在加载完成后用 Qdrant 的search接口对 FAQ 问题做相似度召回并与 LLM Zoomcamp 主课中的 RAG 问答如 cohorts/2025/02-vector-search/ 模块衔接形成完整的问答系统。【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考