https://laisky.notion.site/The-quantum-state-of-a-TCP-port-29b94af7bedf49beb958045c3c1dbc02

很有趣的关于 linux 上 TCP 本地端口自动分配的文章。

虽然理论上，TCP 连接只要求 (src_ip, src_port, dst_ip, dst_port) 的四元组不同，但实际情况复杂得多，即使使用了 SO_REUSEPORT 也不能保证本地端口一定能被复用，而且虽然 bind(2)/connect(2) 都支持自动分配本地端口，但对应的却是不同的处理逻辑。

这其中的逻辑错综复杂，以至于作者在文章标题中将其戏称为“量子态”。
结论：推荐使用 IP_BIND_ADDRESS_NO_PORT & bind(2) 的方式绑定端口，可以最大化本地端口重用的概率。

https://x.com/qq3qiyu/status/1737728033384206710?s=20

看到有人讨论 python requests 的 timeout 问题，简而言之就是发现 requests 的总耗时会超过你设置的 timeout。

其实原理很简单，requests 支持两种 timeout：

* connect timeout: 建立连接的超时时间
* read timeout: 服务端每次响应的超时时间

默认情况下，timeout 设置的是 connect timeout + read timeout，你也可以通过 tuple 的形式分别设置。

需要注意的是，requests 并不支持 total timeout，就是实际上你没法控制这个 requests 请求总共会花多长时间。举一个极端的例子，如果这个服务端总能在每隔 read timeout 内回复点数据，那么这个请求实际上可以耗费无穷长的时间。

requests 官方的解释是，市面上已经有其他控制 total timeout 的包了，requests 没必要再做一个。这个第三方包就是 https://github.com/pnpnpn/timeout-decorator ，它通过设置 ITIMER_REAL 信号来实现对函数总耗时的控制。但是这个包仅支持主线程。

如果你使用 asyncio，那么 asyncio.wait_for 可以很轻松地为 coroutine 设置总耗时。aiohttp 的 timeout 看上去也是 total timeout。

注意：asyncio.wait_for 只是停止等待，杀 coroutine 需要另外手动处理（task.cancel()）。被杀的 coroutine 也需要经常通过 await asyncio.sleep(0) 检查自己有没有被杀。

https://youtu.be/V3BafEiqSFg?si=M0sZ9F4tLA5cSzad

最近看了部关于欧美核聚变研究的纪录片，其中一位科学家声称，预计 2035 年可以商业化，2040 年可以全球化。掐指一算，正好我小孩 20 岁步入社会的时候，世界上已经有无限的能源供给了，亦或说，无限的算力。

顺带一提核裂变，越来越多的人认为核裂变发电站是人类走的一条歧路，人总是会犯错的，而裂变站的每一次事故所造成的代价都是无法承受的，法国核能安全研究院估算每一次核事故会造成 3000～15000 亿欧元的损失。而且核裂变发电站的核废料处理也是一个难题。日本福岛核事故对欧美的冲击也是巨大的，毕竟日本人在欧美人心目中一直是“匠人精神”的代表，如果连日本人都搞不定核裂变，那么人们也就很难再相信它了。

但是在聚变等次世代技术真正成熟以前，核裂变是唯一清洁的稳定发电源（地热能、水能也是清洁的稳定能源，但是需要地理条件）。这可能就是人类能源史上的一次阵痛吧。

https://laisky.notion.site/Metrics-for-Information-Retrieval-and-Question-Answering-Pipelines-d5d4e3beb820419ca494596e319befcf

一个笔记，用于度量 LLM RAG Retriever 性能的常用指标。包括 HR, Recall, Precision, MRR, mAP, NDCG, EM, F1 Score, SAS。

Ps. Retriever 也有寻回犬的意思，负责叼回猎物，在 RAG 里则是负责找回有用的附加信息。

最近几天都在读这篇论文，关于 LLM RAG 方法的综述。总结了 RAG 技术的发展脉络和应用、评估方法。此文的优点在于非常全面，从预训练、fine-tuning 到 inference 的 RAG 流程都探讨到了。

附件的 pdf 里我对比较重要的信息做了标注和笔记，改天有空水篇博客整理一下🐦。

整理了一个 slide: https://s3.laisky.com/public/slides/LLM-RAG.slides.html#/

套皮站 https://chat.laisky.com/ 上支持 gemini-pro 和 gemini-pro-vision 了，免费使用。google 的限流很小，遇到限流就等等吧。

one-api 对 gemini-pro-vision 的支持有 bug，我提了 PR，或者考虑用我的 fork 版 ppcelery/one-api:latest。

顺带分享个数据，上个月这站上去掉我以外的 12 个充值用户总共只花了 1 美元。gpt-plus 一个月的会员费足够我们用一年…

https://laisky.notion.site/Prompt-injection-What-s-the-worst-that-can-happen-f149c87d948b449fa3d62fd7e99217c6?pvs=4

很有趣的文章，介绍了常见的 LLM prompt injection 攻击案例。任何会接受外部信息的 LLM 都可以被外部攻击者操作。尤其当这个 LLM 具有 function calling/tools/agents 能力时，相当于也为外部攻击者赋予了这些强大的能力。首当其冲的就是各种基于 RAG 的应用，retriever 获取的内容都可以成为攻击者手中的利刃。

作者在此文以及他的其他文章中屡次表达出悲观的态度，认为 LLM 的 prompt injection 不可避免，我们只能接受这个前提，然后小心谨慎地设计我们的应用。

配图是一个经典的 indirect prompt injection 例子，在网页中插入肉眼不可见的内容，来误导 bing chat 的自动答复。

https://laisky.notion.site/Advanced-RAG-Techniques-an-Illustrated-Overview-b3cc58c3f493403db31135f39f136b6b?pvs=4

最近流传比较广的一篇关于 LLM RAG 的综述性文章，看了一遍，内容其实都全部被我之前分享的这篇论文涵盖到了，论文的内容要更全更深。

不过配图不错，我抄了一些配图更新到我的 slide 里了。

https://laisky.notion.site/Knowledge-Retrieval-Takes-Center-Stage-0583843afb0940cbafc4ce34805a761c?pvs=4

之前分享的那篇论文是对 RAG 的综述。而目前的一个研究方向则是更进了一步，提出了 RCG 的概念。

RAG 是利用 retrieval data 增强 LLM 的能力。而 RCG 则是摒弃 LLM 的内生知识，完全使用 retrieval data 来生成答复。

在 RAG 时代，人们认为 LLM 越大越好，内嵌的知识越全面，对 retrieval data 的利用也就越充分。
但是在 RCG 时代，小型 LLM 也能够取得和大模型相媲美的性能，甚至更好。小模型不再专注于大而全的信息原文，而是专注于对信息抽象认知模式的学习和推理。对于 retrieval data，RAG 的理解能力依赖于 pre-training 数据集和外部数据的重叠。而 RCG 更强调于对未知数据（unseen data）的抽象认知能力。

用人来打比喻，RAG 时代就是一个能力平平但是善用网络的懂王，而 RCG 则是试图塑造一位天资聪颖的人才。

https://devv.ai/

正好这篇文章在 devv.ai 上遇到了很经典的 RAG 幻觉。

devv.ai 是基于网页抓取的 RAG 应用。我问他“什么是 ROG”，它很正确地抓取到了这个网页。但是这个网页中大篇幅都是描写 RAG 和 RCG 的内容，仅有两句话提到了 ROG。而 devv.ai 显然被误导了，它使用 RCG 的内容来描述 ROG，生成了完全错误的答复。

虽然 devv.ai 是一个很好用的平台，但是通过这个案例可以了解到，基于 RAG 是无法避免幻觉的。好在 RAG 提供了透明性，你还是要自己去查阅一下来源，自行判断真伪。