<p>作者：来自Elastic<span>spinscale</span></p> 
分析链中的数字标准化
在全文搜索中，一个常见问题是如何处理数字。最基本的方法是将它们完全提取出来，并在范围内作为真实数字进行查询，但在很多情况下，这需要大量分析，而且数字往往只是全文搜索的一部分，比如 iphone 17 或 bed 1.4 m。
问题是，当用户输入搜索时，他们对数字的理解可能与你不同。
1.4 m 和 1,4 m 是相同的吗？事实是，美国和欧洲在大数和分数的分隔符上使用不同的字符。除此之外，用户在搜索引擎中输入数字时，点和逗号常常可以互换使用，尤其是数字较小时。
- 007 和 7 是相同的吗？取决于你的使用场景。
- 1.4 m 和 1.40 m 是相同的吗？这取决……你明白我的意思。
那么我们能做些什么来稍微标准化数字呢？
为了这个示例，让我们使用keep_types token filter，仅保留数字，丢弃分析链中的其他内容：
POST _analyze
{
"text": "makita führungsschiene 1.4 m, 1,4 m 1,40 1.40",
"tokenizer": "standard",
"filter": [
{
"type": "keep_types",
"types": [
""
]
}
]
}
这只会返回看起来像数字的 token，无论它们是否包含点或逗号，但会排除其他内容，例如普通单词，比如 makita。
接下来，我们先统一所有带点或逗号的数字。
POST _analyze
{
"text": "makita führungsschiene 1.4 m, 1,4 m 1,40 1.40",
"tokenizer": "standard",
"filter": [
{
"type": "keep_types",
"types": [
""
]
},
{
"type": "pattern_replace",
"pattern": "(\\d+)\\,(\\d+)",
"replacement" : "$1.$2"
}
]
}
这只返回 1.4 或 1.40 —— 很好！所以无论索引了什么，或者用户搜索什么，现在我们总是假设数字使用点，借助pattern_replace token filter实现。
如果不关心位置，可以在最后使用 unique token filter —— 当然也可以省略 norms 以减少索引大小。
你也可以去掉点，只保留数字本身，但这可能导致搜索 1.7 时返回 iphone 17 —— 同样，这取决于是否希望这样。
接下来，我们去掉前导零：
POST _analyze
{
"text": "test 007 7 700 000 0",
"tokenizer": "standard",
"filter": [
{
"type": "keep_types",
"types": [
""
]
},
{
"type": "pattern_replace",
"pattern": "^0+(\\d+)",
"replacement" : "$1"
}
]
}
现在，007 或 000 会被简化为单个数字字符。虽然这可能有用，但请注意，当用户搜索 007 作为零件编号时，可能会返回包含 7 的所有结果，从而增加歧义。
接下来，真正有趣的部分来了：去掉尾随零，但不要弄得太复杂。像往常一样，如果你手头只有正则表达式，你可能会想出一个复杂的正则，但也许预处理可能已经是个好主意。
POST _analyze
{
"text": "0.100 0.1000 0.101 100 100.0 100.00 100.001",
"tokenizer": "standard",
"filter": [
{
"type": "keep_types",
"types": [
""
]
},
{
"type": "pattern_replace",
"pattern": "^(\\d+)\\.([0-9])(0+)$",
"replacement" : "$1.$2"
}
]
}
这会返回（至少如果你在请求中添加 filter_path=**.token）：
{
"tokens": [
{
"token": "0.1"
},
{
"token": "0.1"
},
{
"token": "0.101"
},
{
"token": "100"
},
{
"token": "100.0"
},
{
"token": "100.0"
},
{
"token": "100.001"
}
]
}
你已经可以看到这里还有一些可以改进的地方。100 和 100.0 之间真的有区别吗？也许在这种情况下可以完全去掉尾随的 .0。我相信你会为此想出一个很棒的正则表达式。
让我们把所有步骤整合起来：
POST _analyze
{
"text": "makita führungsschiene 1.4 m, 1,4 m 1,40 1.40 1.0 1.00 0.100 0.1000 0.101 0.1010 100 100.0 100.00 100.001 0.100 007 700",
"tokenizer": "standard",
"filter": [
{
"type": "keep_types",
"types": [
""
]
},
{
"type": "pattern_replace",
"pattern": "(\\d+)\\,(\\d+)",
"replacement" : "$1.$2"
},
{
"type": "pattern_replace",
"pattern": "^0+(\\d+)",
"replacement" : "$1"
},
{
"type": "pattern_replace",
"pattern": "^(\\d+)\\.([0-9])(0+)$",
"replacement" : "$1.$2"
}
]
}
在真实的分析链中，你可能会去掉 keep_types filter，并且在适用时尝试将正则表达式组合以提高速度，但这大概是一个不错的起点。
仔细看上面的输出，你会注意到还有一个小问题：0.1010 没有被简化为 0.101。因此，你可能需要对正则表达式做进一步修正 —— 记住，如果增加一个 token filter 有助于可读性，也是可以的 😊
还有一个实现提示。如果你想确保 pattern replace filter 只针对数字运行，可以使用condition token filter。
原文：https://discuss.elastic.co/t/dec-2nd-2025-en-normalizing-numbers-during-analysis/383512
</div>
