高估的 NP
NP-overrated

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

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

这篇 Hacker News 讨论挑战了一个常见的误区,即认为 NP 难问题在任何情况下都无法解决。评论者指出,NP 难仅意味着在整个输入空间内求解存在困难,而在现实场景中,很少会出现导致计算成本激增的“组合爆炸”。 主要观点包括: * **效率与理论:** 在实践中,简单的 O(N) 方法(如使用连续内存或向量运算)往往优于理论上“巧妙”的对数算法。 * **启发式算法:** 实际的求解器(如 SAT 求解器)在处理典型任务时表现优异,因为现实数据中很少出现导致指数级减速的病态边缘情况。相反,密码学则是为了确保安全性,专门被设计成强制触发这些最坏情况。 * **实用设计:** 软件工程师通常通过有意简化 NP 难问题来设计系统。例如,NPM 或 Go 的依赖解析器通过放宽约束(如版本唯一性)或使用启发式方法修剪搜索空间,从而避免了 NP 难问题。 总之,共识在于:理解 NP 难问题是一种设计工具;它引导开发者去简化问题或实施有针对性的启发式算法,而不是去寻找不可能存在的、放之四海而皆准的完美算法。
相关文章

原文

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