24小时热榜

“我想洗我的车。洗车场在50米外。我应该走路还是开车？”这个问题作为一个简单的人工智能逻辑测试在网络上广泛传播，因此我想看看它在不同模型中的表现如何。我测试了53个模型（包括领先的开源、开放权重和专有模型），没有系统提示，强制选择开车或走路，并提供了推理字段。 在一次测试中，只有53个模型中的11个答对了（42个选择了走路）。但一次测试并不能证明太多，所以我对每个模型进行了10次重复测试。使用相同的提示，没有缓存，干净的状态。 结果变得更糟。在11个通过第一次测试的模型中，只有5个能够持续正确回答。GPT-5的表现为7/10。GPT-5.1、GPT-5.2、Claude Sonnet 4.5，以及所有Llama和Mistral模型在10次测试中均得分为0/10。 人们一直说人类也会在这个问题上失败，因此我通过Rapidata获取了人类基线数据（10000人，使用相同的强制选择）：71.5%的人选择了开车。大多数模型的表现低于这个水平。 所有的推理轨迹（通过我的初创公司Opper进行测试）、完整的模型分析、人类基线数据和原始JSON文件都在报告中，供任何想深入研究或进行自己分析的人使用。

大家好！我们是 Lev 和 Justin，PgDog 的作者（<a href="https://pgdog.dev">https://pgdog.dev</a>），这是一个为 PostgreSQL 提供连接池、负载均衡和数据库分片的工具。如果你在构建高流量的应用程序，你会知道第一个崩溃的往往是数据库。我们通过一个网络代理来解决这个问题，它不需要对应用程序代码进行更改或数据库迁移。 去年的帖子：<a href="https://news.ycombinator.com/item?id=44099187">https://news.ycombinator.com/item?id=44099187</a> 最重要的更新：我们已经投入生产。分片使用频繁，直接到分片的查询（每个查询一个分片）几乎总是有效。跨分片（或多数据库）查询仍在持续改进中，但我们正在取得进展。 聚合函数如 count()、min()、max()、avg()、stddev() 和 variance() 正在正常工作，无需重构应用程序。PgDog 在传输过程中计算聚合，同时透明地重写查询以获取任何缺失的信息。例如，多数据库的平均计算需要总行数来计算原始总和。如果查询中没有 count()，PgDog 会将其添加到查询中，并从发送给应用程序的行中移除。 排序和分组功能正常，包括 DISTINCT，如果结果中引用了列。支持超过 10 种数据类型，如时间戳（tz）、所有整数、varchar 等。 跨分片写入，包括模式更改（CREATE/DROP/ALTER），现在是原子性的，并且在所有分片之间通过两阶段提交进行同步。PgDog 在内部跟踪事务状态，如果第一阶段失败，将回滚事务。你无需对 ORM 进行 monkeypatch：PgDog 会拦截 COMMIT 语句，并执行 PREPARE TRANSACTION 和 COMMIT PREPARED。 全分片表，即复制或镜像（在所有分片上相同），支持原子读写。这一点很重要，因为大多数数据库无法完全分片，所有数据库上会有一些必须保持同步的公共数据。 多元组插入，例如，INSERT INTO table_x VALUES ($1, $2), ($3, $4)，会被我们的查询重写器拆分并自动分发到各自的分片。它们被 Prisma、Sequelize 等 ORM 使用，因此现在也可以在不更改代码的情况下工作。 分片键可以被修改。PgDog 会拦截并将更新语句重写为 3 个查询：SELECT、INSERT 和 DELETE，将行在分片之间移动。如果你使用 Citus（对其他人来说，Citus 是一个用于数据库分片的 Postgres 扩展），这可能值得一看。 如果你像我们一样更喜欢将整数作为主键而不是 UUID，我们在 PgDog 内部构建了一个跨分片的唯一序列。它使用系统时钟（和其他几个输入），可以像 Postgres 函数一样调用，并会自动将值注入查询中，因此像 ActiveRecord 这样的 ORM 仍然可以开箱即用。它是单调递增的，就像真正的 Postgres 序列一样，能够每秒生成多达 400 万个数字，范围达到 69.73 年，因此暂时不需要迁移到 UUIDv7。 <pre><code> INSERT INTO my_table (id, created_at) VALUES (pgdog.unique_id(), now()); </code></pre> 重新分片现在是内置的。我们可以每秒移动数GB的表，通过在副本之间并行化逻辑复制流来实现。这真的很酷！上次我们在 Instacart 尝试这个时，花了超过两周的时间在两台机器之间移动 10 TB。现在，我们可以在几个小时内完成，这在很大程度上得益于核心团队在 Postgres 16 中为流式副本添加逻辑复制槽的支持。 没有良好的负载均衡器，分片几乎无法工作。PgDog 可以监控副本，并在故障转移期间将写入流量转移到提升的主节点。这适用于托管的 Postgres，如 RDS（包括 Aurora）、Azure Pg、GCP Cloud SQL 等，因为它只需通过“SELECT pg_is_in_recovery()”轮询每个实例。主节点选举尚未支持，因此如果你使用 Patroni 自托管，暂时应保留它，但你不再需要在数据库前运行 HAProxy。 负载均衡器变得相当智能，能够处理 SELECT FOR UPDATE 和带有 INSERT/UPDATE 语句的 CTE 等边缘情况，但如果你仍然希望在代码中处理读写分离，也可以通过手动路由来实现。这通过在运行时给 PgDog 提供提示来工作：连接参数（-c pgdog.role=primary）、SET 语句或查询注释。如果你的应用程序中有多个连接池，你可以用一个连接到 PgDog 替代它们。对于多线程的 Python/Ruby/Go 应用程序，这有助于减少内存使用、I/O 和上下文切换的开销。 说到连接池，PgDog 可以自动回滚未完成的事务，并排空和重新同步部分发送的查询，努力保持与数据库的连接。如果你见过 Postgres 因应用程序崩溃引起的连接风暴而达到 100% CPU，这可能适合你。排空连接通过接收和丢弃来自被遗弃查询的行，并通过 Postgres 线协议发送 Sync 消息来工作，这会清除查询上下文并将连接恢复到正常状态。 PgDog 是开源的，欢迎以任何形式的贡献和反馈。和往常一样，所有功能都是可配置的，可以随时开启或关闭，因此如果你选择试用，可以按照自己的节奏进行。我们的文档（<a href="https://docs.pgdog.dev">https://docs.pgdog.dev</a>）也应该能提供帮助。 感谢阅读，祝你编程愉快！