「非口语化名称」原子化解决方案
场景说明
问数系统对词汇的原子化有一定的依赖。建模中经常会遇到这种情况：数据库里存的是一长串结构化名称，但用户只会用口语化关键词提问。
先看两个真实场景。
店铺名称
数据库中存的是：
用户提问时只会说：
产品名称
数据库中存的是：
用户提问时完全不会按原名来：
留意用户的行为：自行重组词序（"猪肉水饺"而非"鲜猪肉速冻水饺"）、省略修饰词（"速冻"）、跳过品牌名（乐味、谷香）。
问题原因
长名称被当做一个整体做向量化存储后，系统把它视为一个完整的语义单元。用户只输入其中两三个关键词时，向量相似度匹配不到这条记录，要么查不出，要么匹配到错误数据。
一句话：长名称藏住了内部结构，系统看不见里面的元素。
解决方案
门店名称在表中保持不变：
解决思路不复杂：只需要为门店引入地理位置信息。可以是直接在门店表中加上城市、街道列，也可以关联到一个地理位置实体表。
引入后，用户问「新街口店过去一年表现如何」，系统会直接命中 街道 = 新街口，而不是去全文匹配那串公司全称。
案例二：产品名称
产品名称照常保留，在同一张表中多维护几列：
无论用户怎么问，都能精确命中：
从「看单个产品」升级为「看品类趋势」「看规格偏好」「看品牌份额」，分析维度也随之提升。
为什么值得多维护这几列
额外维护几列需要少量数据工作，但它带来的回报是长期且叠加的。
匹配精准度
不维护配套列时，系统只能用向量相似度去模糊匹配长字符串，"新街口"和"南京百汇星城新街口有限公司（门店）"之间的语义距离并不近。有配套列后，街道 = 新街口 是精确匹配，不会有歧义，也不会漏数据。
查询可解释性
不维护时，用户看到的结果背后是黑盒——不知道系统到底匹配了名称里的哪个部分。有配套列后，筛选条件就是 街道 = 新街口，任何人都能理解这个查询逻辑，业务方也更信任结果。
分析深度
这是最有价值的差距。一个扁平的名称字段只能回答「某家店 / 某个产品卖了多少」。有配套列后，你可以：
- 按城市对比各街道的门店表现
- 看某个品牌下不同馅料、不同克重的销售结构
- 发现「500g 汤圆在华东卖得好，280g 水饺在华南卖得好」这样的规律
这些洞察在没有配套列的情况下根本无法获得。
持续扩展性
原子列一旦建立，后续新增的数据按同样的规则补充即可无缝接入。反过来，如果一直用长名称做匹配，每加一批新数据就要重新处理向量索引，且规则难以复用。
总结
实操步骤
门店类（引入地理位置信息）：
- 在门店表中新增城市、街道字段，或新建一张地理位置实体表关联门店
- 为每家门店填上对应的地理信息（通常是一次性工作）
- 语义建模时设为对应的语义类型（城市 → 分类、街道 → 分类等）
产品类（维护配套原子列）：
- 在产品表中，新增品牌、馅料、品类、克重字段
- 从已有的产品名称中提取对应值填充（SQL 正则或 Excel 分列均可，一次性操作）
- 语义建模时将各字段设为对应语义类型（品牌 → 分类、品类 → 分类、克重 → 整数等）
- 产品名称本身保留用于展示，匹配交给配套的原子列
通用原则
任何嵌入了多类信息的字段，都可以用这个思路来配套维护：
核心只问一句：用户有没有可能单独拿其中某部分来提问？ 有，就值得多维护一列。