最近调研了一下国密，我被这东西震撼到了。国密 TLS 和国际 TLS 不兼容，国密和国密互相间也不兼容🤮。大量的属性字段各个库各自拍脑袋决定，A 库加密的东西只有 A 库能解密。

似乎也正是因为兼容性问题，各家的实现最终都收敛到 gmssl 这个 C 库上来了。

补充：同为 C 库，还有一个项目是阿里的铜锁。然而，铜锁和 gmssl 互相不兼容…

2023/12/22 补充：最终我选用了铜锁，因为它是基于 openssl 的，支持非常细粒度的操作。顺带一提，不兼容性主要围绕 X.509 的各项属性定义，国密没有加入到国际体系，所以各个实现各自定义了一套，这也就导致了互不兼容。但如果你只用到了对称加密、哈希，是不会有不兼容的。

* Atomic energy, climate, and Russia https://youtu.be/2Ws6qbf_hcA?si=MpkfnPPV2JyewdSS
* Nuclear Aftershocks https://youtu.be/lRmaugZUIGU?si=AOtfQgl_7NpQFogF
* Can hydrongen help the world reach net zero https://youtu.be/v7UwbJ8n9L0?si=IT3gWjD1JnoFNi_t

最近看了好几部关于核能和新能源的纪录片，记一个笔记：

* 因为气候危机迫在眉睫，人类必须立刻大幅削减碳排放。
* 但是可再生能源存在一个重大缺陷，就是供能不稳定，一整个风能园区或太阳能园区可能会在短时间内失去发电能力。
* 所以可再生能源必须搭配一个稳定的功能单元一起运行，而核电站就是一个非常理想的稳定发电单元。
* 福岛核危机敲响了警钟，让欧洲尤其是德国走向了弃核之路。德国人的观点也很正确，我们不能寄希望于这种危险且无法控制的东西。
* 核能还有个问题是，俄国垄断了全球商业核能的核原料供应，即使在俄乌战争期间，欧美也没敢制裁俄国核工业企业，因为他们都依赖于俄罗斯的核燃料。
* 新能源也有类似的问题，中国垄断了新能源材料的生产，比如稀土和太阳能板。
* 美国发起了千亿美元的 IRA 法案，希望将制造业带回美国，并且全面转型新能源。但是该法案遭到了欧洲的批评和抵制
* 欧洲正在大力发展氢能源，希望让由可再生能源制造的氢能扮演起稳定供能的角色。

next: https://t.me/laiskynotes/90

顺带简单提一句，很多人以为气候变暖是温水煮青蛙，拖一拖忍一忍就行了。但其实不是的，气候变暖是一个正反馈系统，做一个形象的比喻就是，气候灾难就是卡在半山腰上的一块巨岩，而人们正在试图撬动它。一旦它被撬动了，它就会加速地滚下山将人类文明砸个粉碎。而且一旦这块巨石开始滚动了，人类即使立刻停止一切碳排放，也丝毫不会影响到这块巨石的加速滚落过程。所以人类的全部机会，就是阻止撬动这块巨石，而我们并没有很多时间和空间了。

Ps. 很多人以为气候变暖就是热一点而已，但其实最大的威胁来自于湿度而不是温度。
人的散热依赖于汗液蒸腾作用，如果环境湿度过高，人体就只能靠辐射散热。当环境湿度为 100% 时，35 摄氏度的气温就能让在阴凉室内静卧的人热死。

各位使用 azure openai 的建议去查查自己的账单。我的上一期账单，azure 的实际扣费单价比公示价格高了 30 倍。我去开了 ticket 后同意给我退款。
而且这个多出来的费用不会显示在 cost management 里，而是仅仅存在于 invoice 里（很鸡贼！）。

后续：钱已经退我了，但是我对 azure 的处理是不满意的，有两个我认为很严重的问题没有给出任何解释：

1. 只承认计价错误，没解释这个模型根本不存在，何来的单价？

2. 没解释这个费用为什么完全绕过了 cost management 和 budget？

next: https://t.me/laiskynotes/98

https://laisky.notion.site/How-it-works-The-novel-HTTP-2-Rapid-Reset-DDoS-attack-Google-Cloud-Blog-6e0b3c1840824c51a55f5ec0c65dcfe5?pvs=4

CVE-2023-39325 利用 HTTP/2 单 tcp conn 上可以承载任意数量 stream 的特性，结合 stream rapid reset 的特性，实现超高强度的 DDoS 攻击。攻击者可以忽略 RTT，直接把己方的带宽跑满。
相当于在 HTTP/2 上打出了 UDP flood attack 的效果。前几个月各个被打趴的站盛传的“来自应用层”的攻击，基本都是这个。HTTP/3 也得考虑做相应的预防措施。

Go 的修复方式是将每个连接的 MaxConcurrentStreams 数设置为 250，起到一些缓解的作用。 https://github.com/golang/go/issues/63417

关于和 Azure 沟通的一些后续，先记下来，日后也许可以写篇博客（根本没时间😭）。

1. cost management 确实不准，在 billing period 结束后的 5 天内都可能大幅调整
2. invoice 页面可以下载详单，里面会记录所有的计费细节

我是不太理解啊，如果 budget 可能比账单晚 5 天，那这个 budget 的意义是什么？

最后是一个我忍不住一定要吐槽的，Azure 理解的 Model Version 跟我的直觉完全不一样。同一个 Model 的不同 Version 其实可能是完全不同的 Model，费用也完全不一样。

比如我图片上这个 gpt-35-turbo，如果你选了 1106 这个版本，它其实就变成了 gpt-35-turbo-16k，价格会贵一倍。具体什么 version 是什么模型和费用，没有一个统一的文档，你只能去 azure 零星的发布稿对着目录一项项地仔细确认。千万别像我一样无脑选最新版，到时候怎么破产的都不知道，毕竟费用根本不会在 cost management 和 budget 上显示，突然月底就扣你信用卡了，哈哈哈哈。

next: https://t.me/laiskynotes/121

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 的自动答复。