本质上是在搭建一个RAG 知识库检索系统。所谓 RAG可以简单理解为用户提问时系统先从企业知识库里找出最相关的资料再把这些资料交给大模型生成回答。在这个链路里text-embedding-v4、LanceDB、OSS分别负责三件完全不同的事情text-embedding-v4负责把文字变成向量LanceDB负责根据向量做相似度检索OSS负责存储向量、原文、元数据和索引文件下面先讲专业概念再讲销售知识库案例。一、先理解几个核心专业概念什么是 EmbeddingEmbedding中文一般叫嵌入向量。它的作用是把一段文字转换成一组数字。例如客户觉得我们太贵了怎么办经过 embedding 模型处理后会变成类似这样的向量[0.021, -0.318, 0.772, ..., -0.056]如果使用text-embedding-v4的默认配置通常可以生成1024 维向量。也就是说一句话会被转换成1024 个浮点数这些数字不是随机的而是表达了这句话的语义特征。为什么文字要变成向量因为普通数据库只能做关键词匹配。例如用户问客户嫌贵怎么接但文档里写的是当客户提出价格异议时应优先强调 ROI 和长期价值而不是直接降价。这两句话没有完全相同的关键词但语义非常接近。传统搜索可能搜不到。但是 embedding 可以识别客户嫌贵价格异议报价太高竞品更便宜预算不足这些表达在语义上是接近的。所以向量的价值是让系统不再只看“字面是否一样”而是看“意思是否接近”。什么是 text-embedding-v4text-embedding-v4是阿里云百炼里的嵌入模型属于 Qwen3-Embedding 系列。它在这个系统里的定位是语义翻译官。它不负责保存数据也不负责搜索数据。它只负责一件事中文 / 英文 / 混合文本 ↓语义向量例如客户说我们比竞品贵 30%怎么回复转换成[0.034, -0.217, ..., 0.891]这个向量后续会交给 LanceDB 检索。text-embedding-v4 常见关键参数在销售知识库场景里最重要的参数有几个。1dimensions向量维度text-embedding-v4支持多种维度例如2048、1536、1024、768、512、256、128、64维度越高表达能力通常越强但也会带来几个问题存储更大索引更大检索更慢成本更高对于销售知识库这种通用语义检索场景通常建议从1024 维开始。原因是精度够用成本可控索引体积不会过度膨胀不要一开始就直接上 2048 维。数据量一旦变大向量文件和索引文件都会明显膨胀。2batch size批量条数Embedding 接口通常支持批量输入。你提供的信息里text-embedding-v4一次最多处理10 条文本所以批量入库时应该按 10 条一批调用接口。3单行 token 上限单条文本不能无限长。你提供的信息里单行上限是8192 token但在知识库里不建议直接把一整篇 PDF 扔进去做 embedding。更合理的做法是先切片再 embedding例如每段 200 到 500 字左右。什么是向量数据库向量数据库就是专门用来做这类查询的数据库给我一个向量找出数据库里最相似的几个向量这类查询叫向量相似度检索。例如用户问题向量[0.034, -0.217, ..., 0.891]数据库中有几万、几十万、几百万条资料每条资料也都有一个向量。向量数据库要做的事情是从海量向量中找出最相似的 Top-K 条比如 Top 5第 1 条客户价格异议处理话术第 2 条竞品贵 30% 的应对方式第 3 条ROI 价值证明案例第 4 条售后服务价值说明第 5 条总拥有成本 TCO 对比LanceDB 是什么LanceDB 是一个开源向量数据库底层基于 Lance 数据格式。在这套系统里它的定位是带索引能力的向量检索引擎。它负责创建表写入向量、原文、元数据创建向量索引执行向量相似度搜索返回最相关结果需要注意一个细节LanceDB 不是 OSSOSS 也不是 LanceDB。LanceDB 负责组织数据、管理索引、执行检索。OSS 负责保存 LanceDB 产生的数据文件。也就是说LanceDB 是干活的OSS 是放东西的什么是 OSSOSS 是阿里云对象存储。你可以把它理解成云上的大硬盘。它适合存PDF图片视频日志数据文件索引文件.lance 文件但是 OSS 不擅长做计算。它不会帮你做向量相似度计算Top-K 排序语义搜索索引召回所以不要理解成把向量放进 OSS然后 OSS 帮我搜这是错误理解。正确理解是LanceDB 负责搜索OSS 负责存储LanceDB 为什么可以接 OSSLanceDB 支持使用 S3 兼容存储作为后端。阿里云 OSS 也提供 S3 兼容接口。所以可以通过类似下面的方式连接s3://your-bucket/sales-kb/lancedb但实际 endpoint 指向的是阿里云 OSShttps://oss-cn-hangzhou.aliyuncs.com这里有一个关键点LanceDB 不能直接识别oss://协议要通过 S3 兼容方式访问 OSS。所以路径写的是s3://bucket/path但 endpoint 配的是阿里云 OSS 的 S3 兼容 endpoint什么是索引如果没有索引LanceDB 每次查询都可能需要和所有向量逐个比较。假设有100 万条销售资料片段用户问一句话系统就要比较1 次问题向量 × 100 万条资料向量这会很慢。索引的作用是提前把向量组织起来让查询时不用全量扫描。可以把索引理解成图书馆目录。没有目录时你要一本一本找。有目录时你先定位到几个可能相关的书架再从这些书架中找最相关的书。IVF-PQ 是什么LanceDB 可以使用 IVF-PQ 这类向量索引。不用先被名字吓住。可以拆开理解。IVF先分区IVF 的思路是先把所有向量分成很多个区比如价格异议相关售后服务相关产品功能相关合同条款相关竞品对比相关真实系统不是按文字标签这么分而是按向量空间自动聚类。查询时系统先判断用户问题最接近哪些分区。这样就不用查所有数据。PQ压缩向量PQ 的作用是把原始高维向量压缩成更小的表示为什么要压缩因为向量太大。例如100 万条 × 1024 维数据量会很大。PQ 可以减少内存和存储压力加快粗筛速度。但是压缩会有一定精度损失所以通常检索过程会分两步先用压缩向量快速粗筛再用原始向量做精确重排什么是粗筛和精排这是向量检索里非常重要的概念。粗筛粗筛就是先快速找出一批可能相关的候选结果例如从 100 万条中先筛出 100 条。这个阶段追求的是快不是绝对精确。精排精排就是对粗筛出来的候选结果重新精确计算相似度例如从 100 条里选出最相关的 5 条。这个阶段追求的是准所以完整流程是100 万条 ↓ 粗筛100 条候选 ↓ 精排Top 5二、三者的准确分工现在把三个角色钉死。text-embedding-v4翻译官它负责把人类语言翻译成向量语言例如客户嫌贵怎么办变成[0.034, -0.217, ..., 0.891]它不负责保存数据创建索引查询数据库返回原文LanceDB检索管理员它负责保存向量表结构写入向量、原文、元数据创建索引根据 query vector 做相似度搜索返回 Top-K 结果它像一个仓库管理员。它知道哪些资料在哪些区域哪些资料和用户问题最接近应该先查哪些候选最后返回哪几条OSS数据仓库它负责保存 LanceDB 的物理数据文件例如向量数据原文片段元数据索引文件.lance 文件它不负责语义理解向量计算索引调度Top-K 排序三、销售知识库案例从 0 到 1 跑完整链路业务场景公司有 5000 份销售资料包括产品手册 PDF销售 FAQ竞品对比文档客户异议处理话术成功案例培训 Markdown现在销售员希望直接提问客户说我们比竞品贵 30%怎么接系统返回最相关的 5 段原文例如1. 当客户提出价格异议时先不要急于降价应引导客户关注 ROI。2. 如果客户认为竞品更便宜可以从售后响应、实施成功率、长期维护成本三个维度对比。3. 对于预算敏感型客户可以提供分阶段采购方案。这就是一个典型销售知识库检索系统。阶段一文档抽取原始资料可能是PDFWordMarkdownHTMLExcel第一步要做的是把这些文档里的正文抽出来例如从 PDF 中抽出当客户说价格太高时先不要急着降价而是引导客户关注 ROI。从 Markdown 中抽出Q你们比竞品贵 30% 凭什么A我们的售后响应是 2 小时内竞品通常是 24 小时内。阶段二文本切片不要把一整篇文档直接丢给 embedding 模型。应该先切片。比如chunks [ { text: 当客户说价格太高时先不要急着降价而是引导客户关注 ROI..., source: 价格异议处理手册.pdf, page: 12, category: 销售话术 }, { text: Q: 你们比竞品贵 30% 凭什么A: 我们的售后响应是 2 小时..., source: 竞品对比FAQ.md, page: 3, category: 竞品对比 }]每个 chunk 最好保存原文 text来源 source页码 page分类 category更新时间 updated_at权限信息 permission不要只存 text。否则后续返回结果时你不知道这段话来自哪里也不好做权限控制。阶段三调用 text-embedding-v4 生成向量每个切片都要转换成向量。示例代码from openai import OpenAIimport osemb_client OpenAI( api_keyos.getenv(DASHSCOPE_API_KEY), base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1)def embed(texts): texts: list[str] 建议每批最多 10 条 resp emb_client.embeddings.create( modeltext-embedding-v4, inputtexts, dimensions1024, encoding_formatfloat ) return [d.embedding for d in resp.data]然后批量处理all_data []for i in range(0, len(chunks), 10): batch chunks[i:i 10] batch_texts [c[text] for c in batch] batch_vectors embed(batch_texts) for chunk, vector in zip(batch, batch_vectors): all_data.append({ vector: vector, text: chunk[text], source: chunk[source], page: chunk[page], category: chunk[category] })此时每条数据长这样{ vector: [0.034, -0.217, ..., 0.891], text: 当客户说价格太高时先不要急着降价..., source: 价格异议处理手册.pdf, page: 12, category: 销售话术}这一步结束后销售资料已经从“普通文字”变成了“可以被语义检索的数据”。阶段四LanceDB 连接 OSS现在要把这些数据写入 LanceDB。但我们不想把数据存在本地磁盘而是存到阿里云 OSS。所以连接时要使用 S3 兼容方式。示例import lancedbdb lancedb.connect( s3://your-bucket/sales-kb/lancedb, storage_options{ region: oss-cn-hangzhou, endpoint: https://oss-cn-hangzhou.aliyuncs.com, aws_access_key_id: 你的OSS_ACCESS_KEY, aws_secret_access_key: 你的OSS_SECRET_KEY, })这里要注意s3://your-bucket/sales-kb/lancedb只是 LanceDB 使用的 S3 兼容路径。真正访问的是阿里云 OSS endpoint也就是https://oss-cn-hangzhou.aliyuncs.com阶段五创建 LanceDB 表并写入数据创建表table db.create_table( sales_knowledge, dataall_data, modeoverwrite)这一步之后OSS 中会出现 LanceDB 相关数据文件。可以理解为LanceDB 负责把向量、原文、元数据组织成表OSS 负责保存这些表对应的物理文件后续有新资料时可以增量追加table.add(more_data)阶段六创建向量索引数据写入后如果数据量较大需要创建索引。例如table.create_index( vector_column_namevector, configlancedb.Index.ivf_pq( num_partitions256, num_sub_vectors64, ))这里两个参数先简单理解。num_partitions表示把向量空间分成多少个分区。可以粗略理解为仓库分成多少个区域数据越多通常分区数可以适当增加。几万条数据不需要太大。几百万条数据就要认真调参。num_sub_vectors这是 PQ 压缩相关参数。可以粗略理解为把一个大向量拆成多少段来压缩它影响索引大小检索速度召回效果不要一开始乱调建议先用中等配置跑通再通过测试集评估效果。阶段七销售员提问销售员输入客户说我们比竞品贵 30%怎么接系统第一步不是直接查数据库而是先把这个问题也转换成向量。注意入库文档用什么 embedding 模型查询问题也要用同一个 embedding 模型。示例def search(question: str, top_k5): q_vector embed([question])[0] results ( table .search(q_vector) .limit(top_k) .to_pandas() ) return results[[text, source, page, category]]调用hits search(客户说我们比竞品贵30%怎么接, top_k5)for i, row in hits.iterrows(): print(f{i 1}. {row[text]}) print(f来源{row[source]} 第 {row[page]} 页)四、完整查询链路拆解现在把整个查询链路拆开。用户问客户说我们比竞品贵 30%怎么接第一步text-embedding-v4 把问题转成向量客户说我们比竞品贵 30%怎么接 ↓[0.034, -0.217, ..., 0.891]这一步发生在阿里云百炼 embedding API。第二步LanceDB 拿到 query vectorLanceDB 收到的不是文字而是1024 维 query vectorLanceDB 不理解“贵不贵”这个中文意思。它只知道我要找和这个向量最接近的向量第三步LanceDB 用索引粗筛LanceDB 会根据 IVF-PQ 索引快速判断这个问题最可能落在哪些向量分区例如256 个分区 ↓挑出最接近的若干个分区 ↓在这些分区里快速扫描候选这个阶段的目标是快点缩小范围不是马上得到最终答案。第四步LanceDB 从 OSS 读取候选数据粗筛后LanceDB 可能得到几十条或几百条候选。然后它会从 OSS 中读取这些候选对应的数据包括原始向量原文 text来源 source页码 page分类 category这里一定要理解不是 OSS 在做向量搜索而是 LanceDB 决定要读哪些数据然后去 OSS 取。OSS 的角色只是你要哪个文件、哪段数据我给你。第五步LanceDB 做全精度重排候选数据取回来后LanceDB 会做更精确的相似度计算。例如候选 100 条 ↓精确计算相似度 ↓排序 ↓取 Top 5最后返回最相关的 5 段销售资料五、用一张图记住完整链路销售员提问“客户说我们比竞品贵 30%怎么接” │ ▼text-embedding-v4把问题转成 1024 维向量 │ ▼LanceDB拿 query vector 查 IVF-PQ 索引 │ ▼LanceDB粗筛出几十条 / 几百条候选 │ ▼OSS按需读取候选数据 │ ▼LanceDB对候选做全精度重排 │ ▼返回 Top 5 原文片段六、入库链路和查询链路要分开理解很多小白会把这两个流程混在一起。其实知识库有两条链路。入库链路入库链路发生在准备知识库数据时流程是PDF / Markdown / Word ↓抽取正文 ↓文本切片 ↓text-embedding-v4 生成向量 ↓LanceDB 写表 ↓OSS 保存 .lance 数据文件 ↓LanceDB 创建索引入库不是每次用户提问都做。通常是新增资料修改资料定期同步才做。查询链路查询链路发生在用户每次提问时流程是用户问题 ↓text-embedding-v4 生成问题向量 ↓LanceDB 查索引 ↓OSS 读取候选 ↓LanceDB 精排 ↓返回 Top-K 原文用户每问一次就会走一次查询链路。七、为什么这套组合适合销售知识库中文语义检索能力强销售话术里经常有大量中文表达太贵了预算不够竞品便宜价格异议ROI 不明显投入产出比低这些话字面不同但业务意思接近。Embedding 模型可以把它们映射到接近的向量空间。LanceDB 适合轻量级知识库场景销售知识库一般不是每秒大量写入的交易系统。它更像文档相对稳定按天或按周更新查询频繁LanceDB 这种嵌入式向量数据库比较适合这种场景。OSS 适合存放持续增长的知识库数据销售资料会不断增加新产品资料新竞品对比新客户案例新话术模板如果全放本地磁盘后期迁移、扩容、备份都会麻烦。放到 OSS 后存储容量弹性更好成本更低多计算节点可以共享同一份数据存算分离后期更容易扩展OSS 负责存储。LanceDB 运行在应用服务或检索服务里。当查询并发上升时可以扩多个检索服务实例检索服务 A检索服务 B检索服务 C ↓共同访问同一个 OSS bucket这就是存算分离的好处。数据不用搬。计算节点可以横向扩展。八、几个容易踩坑的点不要直接用 oss://LanceDB 连接 OSS 时不是直接写oss://your-bucket/path而是使用 S3 兼容方式s3://your-bucket/path然后在storage_options里配置 OSS endpoint。入库和查询必须用同一个 embedding 模型如果入库时用text-embedding-v41024 维查询时也要用text-embedding-v41024 维不要入库用 1024 维查询用 768 维。也不要入库用一个模型查询用另一个模型。否则向量空间不一致检索效果会很差甚至直接报错。文档不要切得太碎也不要太长切得太碎上下文不完整答案容易断裂切得太长噪声太多embedding 表达不聚焦召回不精准销售知识库可以先从200 到 500 字一段开始试。元数据一定要存不要只存vectortext建议至少存source来源文件page页码category分类updated_at更新时间permission权限标识否则后期会遇到问题不知道答案来自哪个文件无法展示出处无法按部门做权限隔离无法做文档更新无法删除旧版本不要以为向量检索等于最终答案LanceDB 返回的是相关资料片段不是完整回答。如果你要让系统像智能客服一样回答还需要把 Top-K 片段交给大模型例如请根据以下资料回答用户问题不要编造。这一步才是完整 RAG 的生成环节。九、最终用一句话总结这套系统可以这样理解text-embedding-v4 是翻译官把销售问题和销售资料都翻译成向量。LanceDB 是检索管理员根据向量相似度快速找到最相关的资料。OSS 是仓库负责保存 LanceDB 的数据文件、原文、向量、元数据和索引。销售员问客户嫌贵怎么办系统实际做的是先把问题转成向量再用 LanceDB 查相似向量再从 OSS 取回候选资料最后返回最相关的销售话术真正要记住的是OSS 只负责存储LanceDB 负责检索text-embedding-v4 负责把文字变成向量。这三者合起来才构成一个可落地的销售知识库语义检索系统。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】