永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
“置信度评分”营销做错了什么
一个返回置信度分数 0.87 的地理编码响应，看起来比只返回匹配或不匹配的响应更严谨。它带有小数点。它暗示背后有一个经过可测量标准校准的模型。有时情况确实如此。但很多时候，这个数字更接近于一种经验估算，只是包装成了看起来很科学的格式，而从外部很难区分这两者。
单纯的置信度分数的问题在于，它回答的是一个没有人以这种方式提出的问题。构建地址表单的开发者并不需要一个介于零和一之间的概率。他们需要知道更具体的信息：匹配到的是门牌号，还是只匹配到街道。找到的是邮政编码，还是只找到城市。这是屋顶级别的匹配，还是退回到更大区域的中心点。一个浮点数把所有这些有用、可据以行动的细节压缩成一个数字，看起来很精确，告诉您的却比一段简单的描述还少。
我们认为，诚实的做法是用简单明了的语言描述实际匹配到了什么，而不是把它压缩成一个分数，暗示出超出底层方法所能支撑的确定性。这一点更加重要，因为正向和逆地理编码恰恰是那种夸大准确度会在下游造成实际损害的功能。一个地址因为某个高于阈值的置信度分数悄悄放过了错误匹配，而被解析到城市的另一侧，这不是舍入误差。这是一批货物被发往错误的地点，或者一次服务区域检查把实际上位于区域外的客户也包括了进来。
我们不会声称我们的正向地理编码、逆地理编码或自动补全已经能以经过验证的准确度处理所有情况下的每一种地址模式，因为这种说法正是我们在此描述的夸大宣传。我们能明确说明的，是这些端点做什么以及它们是如何构建的，而不是把描述包装在一个旨在让置信度听起来比实际情况更高的数字里。
置信度分数本身并不是不诚实的。用得好的话，它确实能概括关于某个匹配的真实信息，尤其是当它有足够清晰的文档，让开发者能看出这个数字实际上是根据什么计算出来的时候。问题在于分数成了全部答案，被当作准确度的证明来营销，而不是作为多个信号之一来披露，底层方法却只字不提。一个没有解释的数字并不比文字更准确。它只是更难被反驳，而这完全是另一回事。
解决办法并不复杂，尽管放在营销页面上没那么好看。用简单明了的语言描述匹配到了什么，让开发者自己决定这种详细程度对他们正在构建的东西是否足够。一个被清楚描述的街道级匹配，比一个背后毫无解释的 0.91 分更有用，因为简单明了的语言会告诉您下一步该检查什么，而一个单纯的数字不会。