高估的 NP
NP-overrated

原始链接: https://gruhn.me/blog/2026-08-13/

学术界普遍认为 NP-hard 问题是“难以处理”且在实践中无法解决的,这其实是一个广泛存在的误区。尽管这些问题在最坏情况下确实很棘手,但在现实世界的应用中,它们经常能被高效地解决。 作者指出,“NP-hard”并不意味着“不可能”。对于许多实际任务(如依赖解析或类型检查),最坏情况很少发生。而对于优化问题或布尔可满足性(SAT)等其他任务,算法效率的提升极为显著,其进步幅度远超硬件性能的增长,使得我们现在能够大规模、最优地解决海量复杂的实例。例如,亚马逊每天就能成功处理数十亿个基于 SAT 的问题。 归根结底,理论上可能存在的计算缓慢不应成为实际实现的阻碍。正如工程师会设计系统来处理网络超时或错误一样,开发者也可以通过超时设置或启发式方法来应对最坏的计算场景。理论复杂度并不等同于实践失败;通过“深入思考”并不断改进算法,许多看似不可能解决的问题已经成为了标准的高性能工具。

关于“NP-Hard 问题被高估了”这一观点的 Hacker News 讨论,揭示了计算理论视角与实践视角之间的根本分歧。 争论的核心集中在以下三个关键认识上: * **理论与现实:** 尽管 NP-Hard 问题在最坏情况下是不可解的,但大多数现实场景并不会遇到那些极端的最坏情况。工程师们经常通过使用启发式算法、增加约束条件或对结果进行后处理来解决 NP-Hard 问题(如任务调度、依赖解析或类型检查)。这种“难度”通常通过设计系统来避开病态情况从而得到管控。 * **复杂性理论的效用:** 讨论参与者指出,将一个问题标记为 NP-Hard 并非项目的“死刑判决”,而是一个至关重要的路标。它提醒设计者,寻找一个完美的通用精确算法很可能是徒劳的,从而鼓励他们转而关注近似算法、固定参数易解性或针对特定问题的优化。 * **被“娇惯”的世界:** 一些评论者注意到,软件系统被刻意地“打磨”以确保稳定性,从而掩盖了潜在的复杂性。当开发者避开那些“困难”的边界情况时,实际上是将问题强制转化为了更简单的复杂性类别,使标准工具能够高效运行。 归根结底,复杂性理论提供了一个必要的框架,指导我们在何处必须为了实用性而牺牲最优性。
相关文章

原文

If you learned about NP-hard problems in university, your takeaway was probably this:

NP-hard problems are solvable in theory but it's hopelessly expensive in practice. It's basically proven that no good algorithms exist.

At least that's what I took away. And almost everyone I've talked to. And many people online. I keep seeing "No you can't do it. It's NP-hard. Blah blah" discussions. The myth is pervasive but these problems are not intractable.

At the time, my professor closed the final lecture with dramatic words (I'm paraphrasing slightly):

And now you've learned that almost all interesting problems are undecidable and of the remaining ones, almost all are NP-hard. For the project of computer science, that puts the final nail in the coffin.

Sheesh. Not sure if everyone got such a dire framing but that would explain.

The theory is not wrong, but in practice it's often irrelevant. Sure, any algorithm you can come up with will blow up on some inputs. But you might get a fast solution on 99.9% of inputs. Or 100% of the remotely relevant inputs. The theory does not rule that out.

In theory, there is no difference between theory and practice. But in practice, there is.

-- Benjamin Brewster

A few prominent NP-hard problems:

  1. Dependency resolution (in package managers)
  2. Type checking (not all type systems)
  3. Scheduling
  4. Traveling Salesman
  5. Boolean Satisfiability (SAT)

For (1) and (2), the worst-case just doesn't occur. I mean, installing packages and type checking can surely be slow. But, at least in my career, I've never seen a galactic blow-up.

(3) and (4) are technically optimization problems. Everyone knows you can tackle those with heuristics, but you don't have to sacrifice optimality. We absolutely have tools that can find provably optimal solutions in reasonable time. There's no magic. No quantum computers. Just thinking harder and coming up with better algorithms. And that's what people have done. In fact, algorithmic speedup has outpaced hardware gains in the last decades. Taken together, this paper cites a 450-billion-fold speedup between 1991 and 2015.

Last but not least: even (5), the archetype of NP-hard problems, is routinely solved at scale. Amazon is solving a billion SMT problems a day. SMT is an even harder version of SAT. The SAT algorithms have gotten so good, it's now considered the easy part.

But what if you run into the worst-case? You don't have to wait for the heat-death of the universe. An HTTP request also doesn't come back sometimes. Add a timeout, show an error message, ... you know the drill.

联系我们 contact @ memedata.com