Telegram Channel
记录和分享有趣的信息。

Record and share interesting information.

contact: [email protected]
今天学到一个 Go 的 time.Parse 坑。虽然 time.RFC3339 里并没有定义毫秒,但如果被解析的字符串包含毫秒,那么解析结果实际上也会包含毫秒。带毫秒的解析结果和不带毫秒的解析结果是不相等的。

如果要进行时间比较,Parse 后需要手动通过 Truncate 来修订精度
ts2 = ts2.Truncate(time.Second)

已加入到合集本:https://blog.laisky.com/p/golang-race/
学到一个前端 UX 小知识,绑定 SHIFT+ENTER 触发在 input 里是一个非常糟糕的设计。因为英文键盘里,按一次换行就会自动激活 SHIFT,此时如果再按一次换行就成了 SHIFT+ENTER。如果你绑定了这个按键组合,就会导致用户误触。
Laisky's Notes
关于和 Azure 沟通的一些后续,先记下来,日后也许可以写篇博客(根本没时间😭)。 1. cost management 确实不准,在 billing period 结束后的 5 天内都可能大幅调整 2. invoice 页面可以下载详单,里面会记录所有的计费细节 我是不太理解啊,如果 budget 可能比账单晚 5 天,那这个 budget 的意义是什么? 最后是一个我忍不住一定要吐槽的,Azure 理解的 Model Version 跟我的直觉完全不一样。同一个 Model 的不同 Version…
关于 azure openai 费用争议的最终结论:

1. cost management 会滞后 billing period 5 天,budget 同理。所以你没看到花钱,不代表不扣你钱。(和之前的结论一致)

上次我的结论中有一些需要修订的地方:

1. 目前 Azure OpenAI 的服务价格列表参见 https://azure.microsoft.com/en-us/pricing/details/cognitive-services/openai-service/
2. gpt-3.5-turbo 升级最新版本 1106 后,默认 context 就是 16K,而且价格比此前的 gpt-3.5-turbo 和 gpt-3.5-turbo-16k 都更便宜。

经过我“吹毛求疵”的争论后,Azure 反馈承认他们不但搞错了计价,还搞错了 invoice 中的模型名称,所以此前产生了很多误解。

记了一篇博文:https://blog.laisky.com/p/azure-billing/

就目前最常用的 gpt-3.5 和 gpt-4 而言,实际上只需要使用三个模型就足够了:

1. gpt-4-1106-preview: 支持 128K context,而且是最便宜的 gpt-4
2. gpt-4-vison-preview: 价格同 gpt-4-1106-preview
3. gpt-3.5-turbo-1106: 支持 16K context,而且是最便宜的 gpt-3.5

Ps. 我套皮站上也做了更新,openai 目前只支持这三个模型了。我的 oneapi 网关上还另外支持 text-embedding-ada-002、dall-e-3、gemini-pro 和 gemini-pro-vision。顺带一提,如果你使用 gpt-3.5-turbo-16k-0613 或 gpt-3.5-turbo-0301 实际上会被自动转发给 gemini-pro,这是为了可以免费使用如 gptcommit 这种仅支持 gpt 的工具。
Laisky's Notes
https://laisky.notion.site/Knowledge-Retrieval-Takes-Center-Stage-0583843afb0940cbafc4ce34805a761c?pvs=4 之前分享的那篇论文是对 RAG 的综述。而目前的一个研究方向则是更进了一步,提出了 RCG 的概念。 RAG 是利用 retrieval data 增强 LLM 的能力。而 RCG 则是摒弃 LLM 的内生知识,完全使用 retrieval data 来生成答复。 在 RAG 时代,人们认为 LLM…
https://devv.ai/

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

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

虽然 devv.ai 是一个很好用的平台,但是通过这个案例可以了解到,基于 RAG 是无法避免幻觉的。好在 RAG 提供了透明性,你还是要自己去查阅一下来源,自行判断真伪。
Laisky's Notes
Retrieval_Augmented_Generation_for_Large_Language_Models_A_Survey.pdf
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 则是试图塑造一位天资聪颖的人才。 Knowledge Retrieval Takes Center Stage | Notion
帮各位踩个雷,无意中发现了 aihubmix 这个项目,号称可以用 3.5人民币/美元 的低价购买 openai apikey。我去简单看了下,网页就是 oneapi 套皮,后端接口都没改。然后发现一个很严重的问题是这家的模型计费可能存在欺诈,tokens 计算严重偏高,你以为你买了便宜,实际上每次调用都在黑你。
https://youtu.be/dLr--F1Ubko?si=xFcT5fbEU_suzwzr

20 世纪是战争的世纪,第一次世界大战中的各大工业帝国制造了无数的化学炸弹,这些数以千万计的弹药在停战后就失去了用处,其中很大一部分都被直接扔进了海中。

加拿大东部沿海看上去是一片地广人稀的自然胜地。然而因为离欧洲大陆近,在一二战中都是重要的弹药补给线。所以结果可想而知,停战后大量的弹药被直接倾倒进了加拿大东海岸的海洋之中。

这是一个被发现的海洋生物武器抛弃点地图
* https://www.google.com/maps/d/viewer?mid=1NlZ-8xtlviMJ2teJ6hbNKP-9xeU&hl=en_US&ll=46.72459689123628%2C9.221260154931457&z=3
* https://www.google.com/maps/d/viewer?ll=4.967005034105531%2C0&z=2&mid=1ALnyOrN5JQ8H50znwJqI_Sj8IwE

冷战的核军备产生了巨量的核废料,苏联拥有世界上最大的核潜艇舰队,神奇的是这些舰队几乎不产生核废料。不难想象平均每艘船所产生的数百吨核废料都被扔进了哪里。

即使到了现代,以沉船为幌子的排污活动依然非常猖獗。曾经有一艘没能“顺利沉没”的船飘到意大利,人们发现上面竟满载着核废物。

索马里常年内乱,海盗猖獗。据当地的 NGO 救助人员表示当地人出现了很高概率的畸形和癌症,认为这是由于大国趁机往索马里海岸排放高毒性污染物导致的。
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 的自动答复。
最近几天都在读这篇论文,关于 LLM RAG 方法的综述。总结了 RAG 技术的发展脉络和应用、评估方法。此文的优点在于非常全面,从预训练、fine-tuning 到 inference 的 RAG 流程都探讨到了。

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

整理了一个 slide: https://s3.laisky.com/public/slides/LLM-RAG.slides.html#/
Retrieval_Augmented_Generation_for_Large_Language_Models_A_Survey.pdf
5.7 MB
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 里则是负责找回有用的附加信息。 Metrics for Information Retrieval and Question Answering Pipelines | Notion
Telegram Channel