Post在AI圈子待里久了，有些人会过分重视算法，而轻视工程能力。判断一件事的可行性，往往只会从算法层面出发，而不考虑工程难度。

在AI圈子待里久了，有些人会过分重视算法，而轻视工程能力。判断一件事的可行性，往往只会从算法层面出发，而不考虑工程难度。 但对调用方来说，服务的稳定性却是至关重要的。 毕竟谁也不想吃着火锅唱着歌，突然一下，自家产品因为调用的底层服务不稳定，招来大面积差评吧。 就拿我们textin的文档解析服务来说，在正式上线前，我们就定了两个指标，一是文件错误率，二是页面错误率。 前者是指，一定时间范围内，所有请求的文件处理失败的比例；后者指请求的文件中，我们解析失败的页面比例。 下图是我们某一天的请求情况，请求有小2万次，但错误率均为0。 其实这也不是一蹴而就的，早期我们的错误率足足有万分之5。那个时候，我们花了很大的力气去提升稳定性。 当时，我们的开发还不理解，和我说：刚上线就要求万分之一的错误率，是不是要求太高了？ 然后我举了个例子：要是小孩喝的奶粉里，一万桶里有一桶空的或者坏的，然后你正好是买中的那个人，心里作何想？其实，万分之一的错误率都是很高了，我们应该追求百万分之一，甚至更低。 他听了之后觉得有道理，于是又回头认认真真看代码去了。 这也是为什么我们建议有生产需求的用户，都选择一家工程实力强、资源足、并且口碑好的公司作为底层供应商。 要知道，灾备、高并发、负载均衡、自动扩容、健康检查、服务自监控，这些东西都做得好，才能对外提供稳定的服务。 大家在选择底层供应商时，也可以关注一下这方面的背景，避免自己用着用着服务全线报错的情况。