商品参数、FAQ 这类短字段和结构化数据，怎么整理后放进知识库？

简化版

短字段不能一条一条直接向量化：「重量：1.24kg」这种文本太短，语义信息几乎只有两个词，用户用自然语言提问时很难检索到它。正确做法是先把结构化数据整理成有上下文的知识文本：按主题分组合并（一组参数一条），在开头写明主体名称和主题词（「某某笔记本的基础参数如下」），不同用途的字段分成不同的知识类型；导入的资料打上来源标记，重复导入时只覆盖自动导入的那部分，不误删人工维护的内容。导入之后还要走切分和向量化，才能真正被检索到。

详细版

业务库里的结构化数据
  商品详情：介绍、包装清单、售后说明（各是一段文本）
  规格参数：几十条「分组 / 名称 / 值」
    ↓ 整理
知识资料（每条 = 标题 + 类型 + 正文）
  「某某 商品介绍」        类型：卖点说明
  「某某 包装清单」        类型：参数说明
  「某某 售后说明」        类型：售后说明
  「某某 基础参数」        类型：参数说明   正文：某某 的基础参数如下。处理器：…；内存：…
  「某某 屏幕参数」        类型：参数说明   正文：某某 的屏幕参数如下。尺寸：…；分辨率：…
    ↓ 切分 → 向量化 → 检索

问题	做法	原因
单条参数太短	按分组合并成一条	合并后有足够的上下文，语义更完整
片段里没有主体	开头写主体名称和主题词	查询和片段处在同一个语境，相似度才高
用途不同的内容混在一起	分成不同知识类型	可以按类型过滤、统计、维护
重复导入会堆叠	标来源，导入前只删同来源的旧资料	覆盖自动导入的，不动人工维护的
导入 ≠ 可检索	导入后切分、向量化	检索只认向量

完整版教学

一、为什么短文本检索不到

向量检索比较的是两段文本的整体语义。看一个对比：

用户问题：        「这台电脑适合带出门吗，重不重？」
片段 A（单条参数）：「重量：1.24kg」
片段 B（分组合并）：「MacBook Air 13 英寸 的基础参数如下。处理器：Apple M3；内存：16GB；
                   重量：1.24kg；厚度：1.13cm；续航：最长 18 小时」

片段 A 只有「重量」一个词和问题沾边，数字「1.24kg」对语义贡献很小；片段 B 里有商品名、「参数」、重量、厚度、续航，和「带出门」「重不重」这类便携性的问法在语义上更接近。信息量太少的片段，向量表达不出它在讲什么，这是短文本检索效果差的根本原因。

二、合并的粒度：按主题分组

合并也不是越多越好。把一个商品的全部参数拼成一大段，会和「超长片段稀释相关性」撞上同一个问题：一段文本同时讲处理器、屏幕、接口、电池，和任何一个具体问题的相似度都被拉平了。

比较合适的粒度是按业务上的分组合并：

粒度	片段数（以 30 条参数、5 个分组为例）	效果
一条参数一个片段	30	片段太短，语义不足，大量噪声片段
一个分组一个片段	5	每段讲一个主题，长度适中
全部参数一个片段	1	主题混杂，相似度被平均

业务数据里通常本来就有分组字段（参数分组、FAQ 分类、规则类型），直接用它就行，不需要让模型去判断哪些该合在一起。

三、给片段补上主体和主题词

结构化数据里，「这是哪个商品」「这是什么参数」往往存在别的字段或别的表里，文本本身不包含。整理时要把它们写进正文：

不好：处理器：Apple M3；内存：16GB；重量：1.24kg
好：  MacBook Air 13 英寸 的基础参数如下。处理器：Apple M3；内存：16GB；重量：1.24kg

补上之后有两个好处：一是用户问「这款电脑的参数」时，查询里的「参数」和片段里的「参数」对得上；二是引用来源展示给用户时，片段自己就能说清楚在讲哪个商品。切分时再把资料标题和类型一起拼进切片文本，进一步强化这个语境。

记忆钩子：片段要能「自我介绍」——单独拿出来看，也知道它说的是谁、讲的是哪方面。

四、按用途分类型

同一个商品的详情里，介绍、包装清单、售后说明回答的是不同问题：

内容	回答的问题	知识类型
商品介绍	这个商品是什么、有什么特点	卖点说明
包装清单	盒子里有什么、含不含配件	参数说明
售后说明	保修多久、怎么退换	售后说明
规格参数	配置、尺寸、性能	参数说明

分开成不同类型的资料，而不是拼成一大段，后续可以按类型过滤检索、按类型统计知识覆盖，也方便运营人员单独维护某一类。

五、来源标记：重复导入要覆盖，不要堆叠

业务数据会变，导入要能反复执行。如果每次导入都新增一批资料，同一个商品会有多份内容相同或新旧不一的资料，检索时一起命中。所以导入前要先清掉上一次导入的结果——但只能清自动导入的，人工维护的资料不能动：

product_knowledge
  id=11  source_type=MANUAL          「某某 选购建议」     ← 运营手写，保留
  id=12  source_type=PRODUCT_DETAIL  「某某 商品介绍」     ← 上次导入，删除后重新生成
  id=13  source_type=PRODUCT_DETAIL  「某某 基础参数」     ← 同上

删资料时连带删掉它的切片和向量，否则会留下挂在不存在资料上的脏数据。

六、批量导入：一个商品没数据不能拖垮整批

全量导入时，总有一些商品没维护详情或参数。单个导入在「一条都生成不出来」时报错是合理的（告诉使用者原因），但全量导入时要捕获这类错误、跳过这个商品、继续下一个，最后只统计成功条数；只有一条都没导成时才整体报错。否则一个没资料的商品会让整批导入失败。

七、导入只是第一步

整理出知识资料并不等于能被检索到。完整链路是：

从业务数据导入资料 → 切分成片段 → 片段向量化 → 检索和问答

很多「知识库里明明有，AI 却说资料里没有」的问题，原因就是资料导入了、但没有重新切分和向量化。所以导入完成的提示里，最好直接告诉使用者下一步该做什么。

和文档里的表格相比，业务库里的结构化数据还有一个选择：直接查库。价格、库存这类实时变化、不能出错的字段，不应该整理进知识库，而应该交给工具实时查询；参数、介绍、售后说明这类相对稳定的描述性内容，才适合进知识库。文档里的表格怎么处理，见「RAG 如何处理表格数据？」。

八、常见误区与追问

误区：结构化数据一行一个片段最精确。 单行太短，向量表达不出语义，检索时反而很难命中。
误区：把所有字段拼成一大段最省事。 主题混杂会稀释相关性，应该按业务分组合并。
误区：主体名称存在别的字段里就够了。 向量只看文本，片段正文里没有主体，查询就很难和它对上。
误区：重复导入前把这个商品的资料全删掉。 会误删人工维护的资料，只能删同一来源的自动导入资料。
误区：导入完资料，问答就能用了。 还要切分和向量化，检索只认向量。
追问：价格、库存也整理进知识库吗？ 不，实时且不能出错的数据交给工具查询，知识库只放相对稳定的描述性内容。
追问：全量导入时有的商品没数据怎么办？ 跳过继续，只统计成功条数，一条都没成功时才报错。

九、加强记忆

短字段直接向量化会因为信息量太少而检索不到。整理时按业务分组合并，一组一条，粒度介于一行一片和全部一片之间；开头写上主体名称和主题词，让片段能自我介绍；按用途分成不同知识类型，方便过滤和维护。导入的资料打来源标记，重复导入只覆盖同来源的自动资料，删资料时连带删切片和向量。全量导入时没数据的对象跳过继续。导入之后还要切分和向量化才能检索。价格、库存这类实时数据交给工具查，不进知识库。

项目实战落地

项目里怎么做的

《AI Agent电商平台导购与运营增长系统》的商品知识库提供「从商品详情导入」，把 product_detail 和 product_param 两张表转成知识资料：

详情三字段各一条：商品介绍记为卖点说明（SELLING_POINT），包装清单记为参数说明（PARAMETER），售后说明记为 AFTER_SALE，标题都以商品名开头；
规格参数按分组合并：按 paramGroup 分组，一组一条资料，正文写成「商品名的分组名如下。」再接这一组的参数；
来源标记与覆盖：导入的资料来源统一标为 PRODUCT_DETAIL，重新导入前只删这一来源的旧资料，连同它们的切片和向量；人工维护的 MANUAL 资料不受影响；
切片时再补一次语境：切片输入由资料标题、知识类型和正文拼成，再按 180 字、30 字重叠切分。

为什么这样取舍

分组合并而不是一条参数一条资料：商品维护了十几条规格参数，用户问「这个商品的规格参数是怎样的」，单条参数的片段很难被检索到，AI 会回答资料里没有。
价格和库存不进知识库：它们由商品工具实时查询，知识库只放参数、介绍、售后说明这类描述性内容。

面试官还会追问

一键导入全部商品时，某个商品没有维护详情和参数，整批导入会失败吗？
导入商品详情后，前台 AI 问答还是答不出规格参数，还差哪两步？

学完《AI Agent电商平台导购与运营增长系统》，上面这些追问你都会迎刃而解。

简化版

详细版