Reddit daily digest / 2026.09.06

让 ChatGPT 报一万次随机数,它一次都没说过 1、50 和 100

人类挑数字比 ChatGPT 更接近真随机,而模型的偏好被评论区拆成了一个更有意思的问题

今天这份精选里有两条线。一条是关于「AI 到底像不像人」的:人类和 ChatGPT 比赛随机报数,输的是模型;荷兰报纸的评论版被查出大量 AI 代笔,而查案的工具本身也是 AI。另一条更朴素一点——一位在 1996 年做过音乐推荐网站的人,把二十多年前的数据翻出来画了张图;一个 Kubernetes 扩容时的连接池问题,被答成了一堂分布式系统的小课。最后一帖是关于人的:一群人在讲 ChatGPT 怎么改变了他们的生活,有的地方读着让人不太舒服,有的地方是真的动人。

一、让 ChatGPT 报一万次随机数,它从没说过 1、50 和 100

[OC] Humans vs ChatGPT picking random numbers (1–100). We pick 69; AI is obsessed with 47.

一个很朴素的实验:让人和 ChatGPT 各自在 1 到 100 之间「随便」报一个数,然后看谁的分布更接近真随机。结论有点反直觉——人赢了。用总变差距离(TVD)衡量,人类的分布比模型接近真随机四倍左右,哪怕人类明显偏爱 69 和 7、明显躲着以 3 结尾的数。模型这边则夸张得多:一万次里 29% 的输出以 7 结尾,选中 47 的概率是真随机的六倍,而 1、5、20、50、70、100 这几个数,一次都没出现过。

“Out of 10,000 attempts, the fact that ChatGPT didn’t pick 1, 5, 20, 50, 70 or 100 ONCE is wild.”

— u/Pristine_Ad3669(原帖作者),原帖

评论区第一件事是纠正标题。有人指出「模型痴迷 47」是个太窄的说法,真正的规律应该是「模型痴迷所有个位是 7 的两位数,唯独不包括 7 本身」——而 7 本身之所以被躲开,多半是因为它作为幸运数字太出名了,训练里的某种矫正反而让它掉下去。顺着 70 那一段的凸起看,他后来又补了一句:可能只要数字里出现 7 就行,除非撞上「避开 5 和 10 的倍数」这类更强的规则。

“Actually, looking at the 70’s. I think there is a case to be made that AI is obsessed with any number that contains a 7 anywhere, unless its programming/training is overcompensating, like avoiding multiples of 10 or 5.”

— u/Genocode,原帖评论

更值得记的是另一条解释:7 之所以「看起来随机」,是因为以 0、2、5 结尾的数身上有太明显的图案,而 7 系列没有——这一点人和模型是共通的。差别在于,模型是把整个互联网上的人类平均之后再输出,等于一个被抽掉了个体经验的「平均人」在选数;而一群真人里,每个人的偏好来源不同,凑在一起反而摊平了。还有人一句话总结得更狠:模型根本不是在选随机数,它是在按某种内部逻辑挑自己最喜欢的数。原帖引的研究也是这个方向——LLM 没有一个可用的内部采样器,需要统计保证的场合必须外接工具。

“So to put it another way, AI isn’t picking random numbers at all. It is picking its favorite numbers based off some weird internal logic.”

— u/TheForce_v_Triforce,原帖评论

这件事在工程上其实有很实际的推论:凡是需要真随机的地方——抽样、打散、A/B 分流、生成测试数据、洗牌——都不要让模型自己「想一个数」,让它去调 random 或者你自己传种子进去。模型给你的从来不是随机数,而是「一个看起来能被你接受的数」,这两件事在单次调用时无法区分,在一万次之后差别巨大。

二、荷兰主流报纸至少 49 篇评论文章是 AI 全文生成的

At least 49 opinion pieces by major Dutch newspapers fully AI-generated; 57 partly

荷兰有人系统性地检测了主流报纸的评论版文章,结论是至少 49 篇属于完全由 AI 生成,另有 57 篇部分由 AI 生成。评论版本来是报纸里最讲究「谁在说话」的板块,所以这个数字比同样比例出现在别的栏目更刺眼。

串里最实在的一条是关于规则怎么落地的:如果一家媒体允许用 AI 做文字润色、但禁止用它写作,那么光看成品是没法执行这条规矩的——你需要的是写作过程,否则你抓到的永远只是那些主动承认的人。这句话对任何写「AI 使用规范」的团队都适用。

“If you’re allowing AI for copy-editing but banning it for writing, you kinda need more than the finished article to enforce that. Otherwise you’re mostly catching the people who admit to it.”

— u/escalicha,原帖评论

更有意思的是一场关于方法论的正反交锋。有荷兰本地读者提出质疑:这项调查本身是用 AI 做的、报告也是 AI 写的,两家最大的报纸还没被纳入,没有人能复现这份「研究」,也没有人类复核过,所以应该保留态度。这是很到位的怀疑——用一个概率性的检测器去指控别人用了概率性的生成器,举证责任并不轻。

“The investigation was done with AI, the report was written with AI. Two largest newspapers were not included. No one can reproduce the “research”, no human has reviewed it. Please take this with a grain of salt.”

— u/JetzeMellema,原帖评论

但紧接着有人把细节补上了:调查用的是 Pangram,完整流程写在原始报道里(被转的那篇只是摘要);发起人 Klöpping 拿到了所有被检测刊物总编的回应,双方就方法论来回讨论过,最后对方认可了结论;为了验证这个检测器在荷兰语上的表现,他们还额外测了一批 2021 年的旧文章和一批自己生成的文章作对照。这个回合的价值不在于谁赢了,而在于它演示了一份 AI 检测报告要站得住脚,需要补齐哪些东西:公开工具、时间上的负样本、语言适配性验证、以及被指控方的回应。

我的延伸想法是,AI 检测器的报告以后大概率会越来越多,而围绕它的争论会稳定地落在同一个位置:不是「这篇是不是 AI 写的」,而是「你凭什么这么说」。所以真正该被讨论的规范,可能不是禁止使用,而是留痕——谁在什么环节用了什么工具,能不能被复核。作者署名这件事的分量,本来就在于有个具体的人为文字负责。

三、一个 1996 年的音乐推荐网站,二十多年后画出了一张流派地图

[OC] 953 music albums, positioned only by how often people put them together on the same “five-favorites” list, 1996-1998.

发帖人在 1996 到 1998 年间运营过一个网站,只问一个问题:说出五张你喜欢的专辑。网站会回信告诉你,那些同样喜欢这几张的人还提到了哪些。一万七千八百多人收到过结果,最终留下约 13,500 组「五选」。这些数据从 1998 年起就躺在 DBF 文件里,所以地图也停在那一年。他现在把它翻出来,用 Python 加 NumPy 直接输出 SVG,Fruchterman-Reingold 力导向布局,加权标签传播做聚类。

方法上有两个细节很讲究。一是边的定义极简:两张专辑出现在同一份名单上就连一条边,权重是出现次数;他只保留权重 ≥3 的边,因为 91% 的原始配对权重都是 1——「一个人一次」,留着会淹没一切;再取最大连通分量,剩下 953 张专辑、3,601 条连接。二是他明确说了图里没有什么:没有流派、风格、年份、榜单名次,没有音频分析,没有标签,没有模型。位置只由共现关系决定。最有说服力的一句是关于原始流派标签的——目录里其实带着流派代码,但它把 953 张里的 737 张统统归为「ROCK」,毫无用处;而九个自己浮出来的簇,每个簇 52% 到 83% 的连接权重都落在自己内部,这才让他相信这些簇是数据里真实存在的结构,不是聚类算法的产物。

“The original catalog does carry a genre code, and it is useless: it files 737 of these 953 albums as “ROCK.” … I named them and drew the outlines afterwards, so the names are mine and the clusters are the data’s.”

— u/Atari800(原帖作者),原帖评论

他自己也把最大的局限摆在明面上:样本是 1996 到 1998 年上网、并且愿意给陌生人写邮件报五张专辑的那批人,严重偏向九十年代摇滚——这是那群人的口味地图,不是音乐的地图。评论区里有人追问当年收集了哪些用户信息,答案是只有邮箱和城市国家,他曾经在墙上挂一张世界地图,来一个访客就点一个点。底下的回应把这段对话变成了本帖最好的一句:

“We were so innocent back then! Today I have Acxiom, Publicis, or TR cross referencing everything and then using your music purchases to decide what kind of Pringles to stock in the store closest to where you live.”

— u/irate_alien,原帖评论

抛开怀旧,这个帖子对做数据的人有很具体的启发:一个不带任何内容特征、只靠「谁和谁被一起提到」的共现矩阵,就能还原出比人工流派标签更有信息量的结构。这其实就是协同过滤最原始的样子,也提醒我们,很多时候标签体系之所以没用,不是因为标得不细,而是因为它压根没有承载区分度——737/953 都叫「摇滚」的分类,等于没分类。

四、Pod 从 3 扩到 10,已建立的数据库连接谁来重新分配?答案是:没人

When scaling application pods with SQLAlchemy pools, who redistributes existing connections?

一个问得很清楚的工程问题:应用 Pod 各自持有 SQLAlchemy 连接池连 PostgreSQL,当副本从 3 扩到 10,新 Pod 会建新连接,但老 Pod 里那些长期存活的连接还挂在原来的实例上。如果读副本前面是一个 K8s Service 或代理,新连接可能落到新副本,老连接却不会动——那到底谁负责把这些已有连接重新分配?

最高效的回答直接确认了他的判断:连接池根本不知道也不关心你从 3 扩到了 10,已有连接会一直待在原地,直到被关闭或回收;代理和负载均衡器只有在建立新连接的那一刻才有机会做分配。换句话说,扩 Pod 本身永远不会重新平衡已经建立的连接,这件事只能靠连接池自己的生命周期配置(比如 pool_recyclemax_lifetime 这类),或者靠一个具备连接管理能力的代理。

“The pool doesn’t know or care that you scaled from 3 to 10 pods. Existing connections stay where they are until they’re closed/recycled. … Scaling pods alone won’t rebalance already-open DB connections.”

— u/TraditionalTurnip630,原帖评论

另一条主线是引入 PgBouncer 这类连接池代理,让应用只连代理、代理再连数据库,两边各自伸缩。发帖人立刻反问了一句很聪明的话:这不就是把问题从 Postgres 挪到了池子上吗,PgBouncer 自己要扩容时不还是同样的问题?回答是不会——客户端连到 PgBouncer 的连接是「虚拟」的,大量客户端连接共享少量真实连接,客户端不会被钉死在某条真实连接上,甚至每次查询都可能走不同的一条。

真正把这件事讲透的是下面这条补充:在 transaction 模式下,一条真实连接同一时刻仍然只服务一个事务,然后才被复用。所以如果你开了事务、中间去做一堆无关的事、很久之后才提交,那条真实连接在整段时间里都被钉住了。PgBouncer 适合大量小而快的原子事务,它能把数据库的连接数压在上限之下、避免连接风暴打挂数据库;但它不解决扩容——事务量超过数据库容量时延迟照样上去,也不解决被超贵查询拖垮。

“if you open a transaction and then do some other unrelated stuff and only then finally commit the transaction, the real connection assigned by PgBouncer gets pinned for that whole duration. So in a nutshell, you still have to write your app code carefully.”

— u/tobsecret,原帖评论

这一串值得国内做后端的人存下来,因为它纠正了一个很常见的误解:以为加了连接池代理就等于解决了数据库扩展性。它解决的其实只是「连接数」这一个资源维度,代价是你必须把事务边界收窄——「事务里不要做无关的事」这条老规矩,在 PgBouncer 面前从代码风格问题升级成了容量问题。另外,「已有连接不会自动迁移」这个结论也适用于任何长连接场景:gRPC、消息队列消费者、WebSocket 网关,扩容之后不主动断开重连,流量就永远是旧的分布。

五、「ChatGPT 让我的生活变好了吗」——一个长得出乎意料的串

Has anyone else felt like their life has improved significantly since using ChatGPT?

发帖人说自己把 ChatGPT 当作「战略性人生顾问」在用,覆盖关系、财务、健康、学习各方面,而她认为收益最大、别人却最少这么用的一块是心理学——理解自己、理解他人的行为。帖子下面积了近两百条回复,构成了一份相当具体的用例清单。

有大量回答落在同一个位置:不是模型变强了,是网页变烂了。找个菜谱不用先读完你孩子上学的故事,就已经是巨大的改善——这条底下跟了一长串对食谱博客的模仿,是全串最好笑的部分。

“Since the world wide web is trash now, it has been so welcome. Just finding a recipe without needing to read your story about the kids and school has been a massive improvement”

— u/YueAsal,原帖评论

但真正让这个串有分量的是照护类的经历。有人写自己同时照顾两位失智的父母:该找谁、该说什么、怎么申请照护人员、怎么办委托授权、能领哪些补助,全靠它一点点问出来;她说被确诊之后医院只给一张宣传单就送你回家,后面每一份帮助都得自己去争取。这类经验在国内同样成立——真正难的不是治疗方案,而是流程、名词和申请路径构成的那堵墙。

“When you are diagnosed with dementia you’re given a leaflet all about it and sent on your way, and when things progress you have to fight for all the help you can get.”

— u/SugaryFlump,原帖评论

方法论上最值得抄的是这一条:他不让 AI 替他做事,而是用它来理解自己为什么会这样做、为什么会这样感觉。他靠这个戒掉了游戏成瘾、把饮酒降到几乎为零,并且点明了关键——问「我该怎么戒」是没用的,问「为什么这件事已经影响到工作和家庭了我还停不下来」才给出了真正有用的洞察。

“I don’t ask it to do something for me but, rather, use it to understand why I act a certain way or why I feel the way I do.”

— u/Airoveikko,原帖评论

串里也有清醒的反面声音。有位中年人说自己总觉得在 AI 这件事上掉队了,但真的想不出日常生活里该怎么用:工作上有明确场景,家里那些装修园艺的需求几个月才有一次;他极不愿意把内心的想法交给它,也不把它当新闻源——他猜测这是因为自己十几年前已经用互联网、维基和 YouTube 把生活技能学得差不多了,如果现在是二十岁,可能会更依赖它。这条回复其实解释了为什么关于 AI 有用性的争论总是谈不拢:它的价值高度取决于你还有多少东西没学会、以及你手上有多少是「不知道该问谁」的问题。

顺带一提,这个串里也混着一些我不建议照搬的用法,比如拿它做投资决策、甚至越过兽医推翻用药方案。同样一句「它救了我」,背后既可能是打破了信息壁垒,也可能只是这次运气好——差别在于你有没有能力判断它说错了。整体读下来,最有效的用法有个共同点:用它来穿过流程和术语构成的迷宫,而不是用它来替你下判断。


今天这五帖凑在一起,其实指向同一个提醒:模型给出的东西看起来越自然,你越需要知道它是怎么来的。随机数是这样,报纸署名是这样,别人转述的「AI 让我省了三千块」也是这样。反倒是那张 1998 年的音乐地图给了个反例——数据来源笨拙、样本有偏、方法极简,但作者把每一处局限都写在了旁边,于是它反而是今天最可信的一张图。