1.任务要求任务信息截止时间任务明细Task 4- 开发者篇 D2统一 AI Native 数据层实战- 产业应用篇 I3SQL × AI —— AI Functions 的设计与执行截止时间 09 月 26 日 03:00任务1. 通过阅读并跑通code/D2目录下的d2_1到d2_5示例代码体验 Data 在 AI 应用里是如何被承载向量化、存储、查询的体验 AI 系统中的混合搜索。2. 通过pyseekdb向量数据库执行 AI Function了解在数据库系统中调用 AI 的方式。2.任务笔记本节的主要要求是通过阅读并跑通code/D2目录下的d2_1到d2_5示例代码体验 Data 在 AI 应用里是如何被承载向量化、存储、查询的体验 AI 系统中的混合搜索以及通过pyseekdb向量数据库执行 AI Function了解在数据库系统中调用 AI 的方式。2.1 DATA在AI应用中如何被承载到此章有些疑问还没完全清楚。整理如下2.1.1.问题1为什么要向量化向量化之后如何查询相关回答记录整理为1. 为什么要向量化传统关键词检索的问题搜“怎么请年假”文档里写“休假申请流程”关键词对不上但意思一样。搜“苹果手机”可能命中“苹果种植”因为都有“苹果”。同义词、缩写、改写、多语言很难靠关键词覆盖。向量化后“怎么请年假”和“休假申请流程”会被映射到相近的向量位置。可以按语义检索、聚类、推荐、去重、分类。核心价值是从“字面匹配”升级为“语义匹配”。2. 一个文档如何向量化通常不是把整篇文档变成一个向量而是切成小块chunk后分别向量化。步骤① 解析文档把 PDF、Word、HTML、Markdown 等解析成纯文本去掉页眉页脚、乱码、广告等。② 切块 chunking因为 embedding 模型有输入长度限制且整篇文档一个向量会丢失细节。常见做法按标题、段落、语义切分或按固定长度切如 300800 token块之间加 10%20% 重叠避免句子被截断。例如《员工手册》切成年假制度报销流程考勤规则加班调休③ 选择 embedding 模型常见有OpenAI text-embedding-3BGE、M3E、GTE、JinaCohere EmbedSentence-BERT 类模型中文场景常用 BGE、M3E、GTE。要注意查询和文档必须用同一个模型、同一版本、同一归一化方式。④ 生成向量每个 chunk 输入模型经过 tokenizer、Transformer 编码、池化、归一化输出一个固定维度向量比如 768 维、1024 维、1536 维。例如“员工连续工作满一年可享受5天年假需在OA提交申请。”→ [0.12, -0.87, 0.33, ..., 0.05]⑤ 存入向量数据库保存三部分向量用于相似度检索原文 chunk命中后返回或喂给大模型元数据doc_id、chunk_id、标题、来源、权限、时间等。常用向量库FAISS、Milvus、Qdrant、Weaviate、Chroma、Pinecone、pgvector。向量化之后如何查询命中查询流程和文档向量化类似但对象是用户问题。① 查询向量化用户输入“年假怎么请”用同一个 embedding 模型生成查询向量。② 相似度计算在向量库中找和查询向量最接近的文档向量。常用余弦相似度越大越相似点积归一化后等价于余弦欧氏距离越小越相似。公式cos(q, d) q · d / (|q| * |d|)③ 近似最近邻检索 ANN如果文档几百万条逐条算太慢。向量库会用索引加速HNSW图索引快IVF倒排索引PQ量化压缩省内存。然后返回 top-k比如最相似的 510 个 chunk。④ 元数据过滤可以加条件只搜“人事制度”分类只搜用户有权限的文档只搜 2024 年后的版本⑤ 重排 rerank向量召回可能不够准可以用 cross-encoder 或 reranker 对 top-k 精排把最相关的排前面。⑥ 阈值与命中判断如果最高相似度低于阈值比如 0.65就认为“没有命中”避免强行回答。⑦ 返回或生成命中后直接返回原文片段或把 top chunks 拼成上下文交给大模型生成答案。例如命中“员工连续工作满一年可享受5天年假需在OA提交申请经主管审批。”虽然原文没有“怎么请”三个字但语义匹配成功。实践建议切块质量决定检索上限块太大噪声多太小语义不完整。向量检索 关键词检索混合BM25 向量 RRF 融合效果通常更好。加 rerank召回靠向量精排靠 reranker。保留元数据权限、来源、时间、标题查询时可过滤。查询和文档同模型否则向量空间不一致相似度无意义。向量化只负责“找”不负责“答”生成答案通常由 LLM 完成。总结成一条链路文档 → 解析 → 切块 → Embedding → 向量库查询 → Embedding → 相似度检索 → 过滤/重排 → 命中片段 → 返回或交给LLM2.1.2.向量化过程注意事项向量化过程可以按固定分块也可按一定策略处理进阶策略包括语义分块、动态OVERLAP、父子Chunk等原因是通过直接分块的方式对文本进行切割不准确更好的做法是可以用语义进行分割。分割的阈值可以根据文档类型进行调参。相对的入库成本更高需要调用Embedding API进行处理。语义分块适用于结构不清晰、话题跳跃的长文作为「基础分块效果不够好」时的优化手段。向量化过程可以采用不同的策略进行处理不同的输入场景可以选择不同的处理策略。实用策略表为你的情况推荐策略理由刚起步 / 文档量小固定 overlapd2_1 默认方案简单、零额外成本、足够跑通Markdown / API 文档 / 结构清晰固定 overlap 按标题预切结构信号比语义 Embedding 更可靠边界处经常丢上下文动态 overlap成本最低的有效升级话题跳跃的无结构长文语义分块按语义边界切避免硬切检索准但 LLM 答不全父子 chunk小块检索 大块生成多种文档类型混合按文档类型路由不同策略异构语料没有 one-size-fits-all2.1.3 Embedding 模型选型做 RAG 检索时重点看 Retrieval 子任务的得分不要只看总分。可以参考MTEB 排行榜Massive Text Embedding Benchmark选型。MTEB 局限它主要测纯文本、短文本不覆盖多模态检索、跨语言检索、维度压缩MRL和长文档大海捞针等生产场景。RecallK 对比是更贴近业务的验证方式。做法是准备 20–50 条真实业务查询标注每条查询应该命中的文档Ground Truth分别用不同 Embedding 模型做检索看正确答案出现在前 K 条结果里的比例。MTEB 反映的是通用能力RecallK 反映的是业务数据上的实际效果。确定评测方法后还需要从中英文能力、多模态支持、成本、延迟四个维度缩小候选范围。注意事项1. 入库和查询必须用同一个模型。换模型意味着全量 re-index2. 查询和文档的编码方式可能不同。3.bge-m3自带三种检索模式。4. Embedding 负责初筛Reranker 负责精排。工业级 RAG 的常见架构是Embedding 召回 Top-50~100 候选再用 Reranker 模型如BAAI/bge-reranker-v2-m3精排到 Top-10。Embedding 选型解决的是找得到的问题Reranker 解决的是排得准的问题。5. 缓存和批量处理能省 80% 的成本。2.2 混合搜索混合搜索Hybrid Search的核心逻辑向量搜索负责语义理解“找意思最接近的内容”全文搜索负责关键词匹配“找包含这个确切词的内容”关系过滤负责结构化条件“只在最近更新的文档中找”“只在产品 A 的文档中找”
