为什么大规模实时AI如此困难
内容提要
实时AI扩展面临延迟、准确率下降等问题，根源多在数据管道而非模型。尾延迟源于架构，如锁竞争；特征陈旧导致准确率下降；向量索引退化影响召回率。需分离读写路径、训练与服务，监控指标，并采用支持高并发写入和弹性扩展的数据库，避免“厄运循环”。
延伸解读
尾延迟是架构问题，不是模型问题
文章指出，当并发写入高时，锁竞争会导致P99延迟飙升，即使平均延迟正常。作者强调尾延迟是架构属性，无法通过重试或调优缓存解决。例如，Postgres在压力下成为瓶颈，但并非数据库本身慢，而是被要求承担过多。这提醒开发者，在扩展实时AI时，应优先审视数据管道和存储架构，而非一味归咎于模型。
特征陈旧与索引退化：准确率下降的隐形元凶
模型准确率下降可能源于特征陈旧，如用户画像超过SLA数小时，或向量索引因反复重嵌入而退化，导致召回率降至42%。文章强调离线评估无法反映在线性能，需监控特征新鲜度和索引健康。向量索引应像数据库索引一样维护，不能“设置后遗忘”，否则结果会逐渐被污染。
避免“厄运循环”：分离与监控是关键
延迟、陈旧、重训练和资源争用会相互加剧，形成“厄运循环”。文章建议分离读写路径、训练与服务，并采用支持高并发写入和弹性扩展的数据库。同时，要痴迷于监控，特别是积压和索引健康，并做超越稳态的负载测试。这些措施能打破循环，确保实时AI的稳定运行。
Q&A
为什么大规模实时AI系统会出现延迟飙升和准确率下降？
这些问题通常不是模型本身造成的，而是数据管道的问题。例如，高并发写入导致锁竞争，引发尾延迟；特征数据陈旧导致模型基于过时信息做决策，准确率下降；向量索引退化也会影响召回率。
什么是尾延迟？为什么它难以通过常规手段解决？
尾延迟是指高百分位（如P99）的响应时间，它反映了系统在最坏情况下的性能。尾延迟不是简单的bug，而是架构属性的体现，例如存储引擎的GC暂停或锁竞争都会导致尾延迟。常规手段如重试、扩大缓存、调整连接池无法从根本上解决，需要从架构层面优化。
如何判断模型准确率下降是否由特征陈旧引起？
如果离线评估指标正常，但线上性能不佳，且模型本身没有问题，那么很可能是特征陈旧。例如，用户画像数据超过SLA时间未更新，或向量嵌入过期，导致模型基于旧数据做出错误决策。
向量索引为什么会退化？如何避免？
向量索引（如HNSW图）在反复更新（如重新嵌入）后会逐渐退化，导致召回率下降和查询延迟增加。避免方法包括：将索引视为数据库索引一样维护，定期重建或优化，并监控索引健康指标。
训练和服务共用基础设施会带来什么问题？如何解决？
训练和服务共用同一台机器会导致资源竞争，如GPU、内存和CPU争抢，影响性能。解决方法是分离读写路径、训练和服务，使用独立资源或通过工作负载优先级控制资源分配。
什么是“厄运循环”？如何避免？
“厄运循环”是指延迟导致数据陈旧，陈旧降低准确率，准确率下降触发重训练，重训练引发资源竞争，竞争又加剧延迟的恶性循环。避免方法包括：监控关键指标（如数据新鲜度、索引健康）、进行压力测试、使用支持高并发写入和弹性扩展的数据库，以及分离索引服务。
为什么说实时AI本质上是分布式系统问题？
因为实时AI面临的高写入吞吐、低延迟、资源隔离等问题，与分布式系统经典问题相同。例如，特征存储就是高写入低延迟的典型场景。因此，可以用分布式系统的成熟方案来解决实时AI的挑战。
