优化了一下 github action
设置 commit 的 7 位短 hash 作为 docker image tag：
将 docker layers 在 github action cache 里缓存：
设置 commit 的 7 位短 hash 作为 docker image tag：
- name: Add SHORT_SHA env property with commit short sha
run: echo "SHORT_SHA=`echo ${GITHUB_SHA} | cut -c1-7`" >> $GITHUB_ENV将 docker layers 在 github action cache 里缓存：
-
name: Build and push hash label
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: YOUR_IMAGE_NAME:${{ env.SHORT_SHA }}
cache-from: type=gha
cache-to: type=gha,mode=max
又学到一个 python 的 trick，finally 始终会执行，甚至能重写 return。
今天学到一个 Go 的
如果要进行时间比较，
已加入到合集本：https://blog.laisky.com/p/golang-race/
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。如果你绑定了这个按键组合，就会导致用户误触。
关于 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.
2.
3.
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 的工具。
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-42.
gpt-4-vison-preview: 价格同 gpt-4-1106-preview3.
gpt-3.5-turbo-1106: 支持 16K context，而且是最便宜的 gpt-3.5Ps. 我套皮站上也做了更新，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 的工具。
https://devv.ai/
正好这篇文章在 devv.ai 上遇到了很经典的 RAG 幻觉。
devv.ai 是基于网页抓取的 RAG 应用。我问他“什么是 ROG”，它很正确地抓取到了这个网页。但是这个网页中大篇幅都是描写 RAG 和 RCG 的内容，仅有两句话提到了 ROG。而 devv.ai 显然被误导了，它使用 RCG 的内容来描述 ROG，生成了完全错误的答复。
虽然 devv.ai 是一个很好用的平台，但是通过这个案例可以了解到，基于 RAG 是无法避免幻觉的。好在 RAG 提供了透明性，你还是要自己去查阅一下来源，自行判断真伪。
正好这篇文章在 devv.ai 上遇到了很经典的 RAG 幻觉。
devv.ai 是基于网页抓取的 RAG 应用。我问他“什么是 ROG”，它很正确地抓取到了这个网页。但是这个网页中大篇幅都是描写 RAG 和 RCG 的内容，仅有两句话提到了 ROG。而 devv.ai 显然被误导了，它使用 RCG 的内容来描述 ROG，生成了完全错误的答复。
虽然 devv.ai 是一个很好用的平台，但是通过这个案例可以了解到，基于 RAG 是无法避免幻觉的。好在 RAG 提供了透明性，你还是要自己去查阅一下来源，自行判断真伪。
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 则是试图塑造一位天资聪颖的人才。
之前分享的那篇论文是对 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 则是试图塑造一位天资聪颖的人才。
Laisky on Notion
Knowledge Retrieval Takes Center Stage | Notion
TL;DR;
https://laisky.notion.site/Advanced-RAG-Techniques-an-Illustrated-Overview-b3cc58c3f493403db31135f39f136b6b?pvs=4
最近流传比较广的一篇关于 LLM RAG 的综述性文章，看了一遍，内容其实都全部被我之前分享的这篇论文涵盖到了，论文的内容要更全更深。
不过配图不错，我抄了一些配图更新到我的 slide 里了。
最近流传比较广的一篇关于 LLM RAG 的综述性文章，看了一遍，内容其实都全部被我之前分享的这篇论文涵盖到了，论文的内容要更全更深。
不过配图不错，我抄了一些配图更新到我的 slide 里了。
Laisky on Notion
Advanced RAG Techniques: an Illustrated Overview | Notion
A comprehensive study of the advanced retrieval augmented generation techniques and algorithms, systemising various approaches. The article comes with a collection of links in my knowledge base referencing various implementations and studies mentioned.