目前越来越多的公司都在打造属于企业私有的RAG了，这确实比传统的搜索再靠阅读理解已经更进一步了，尤其是新人到公司后可以通过会话聊天的方式迅速掌握公司的主体业务，各项产品特性，常见问题解答。
最近我也在忙着打造属于公司自己的RAG，以下是一些心得体会。
每个公司专有的数据肯定不会被公共的LLM学习到，要想让公有的LLM能回答属于公司专有业务的问题你就得精心准备很多内容素材。最后检索的资料是否准确取决于这一步的物料准备的是否足够丰富、满足日常业务需求，这也是最消耗精力的前置工作，这也是一项长期工作，物料需要不停的更新，周期性的喂到向量数据库里，这样RAG就能保持最新的知识库。
...
Serverless不是新鲜产物，大的云厂商也都有各自的Serverless方案，基本上都能满足大部分用户的需求，甚至Cloudflare还能提供免费的。
但对于用户而言，首要考虑的问题是可移植性，它不像容器化这家不行价高了我立马可以换一家。在各家的Serverless里都高度的自家预设环境，这个没有标准，你在一家Serverless上的代码不能完全就能随意迁移到另外一家，这也是一道门槛，进去了你就不容易离开。
但云厂商这么做其实没问题，既提供了Serverless方案，让你快速部署一些简单的应用，即使你深度研究稍微复杂一点也应该问题不大，价格还便宜，其实也都是有意在抢占市场。
...
假设你的cert目录是/certbot，如果你要签发的域名是qttc.net，那么成功签发后的证书位置如下
/certbot/config/live/qttc.net/fullchain.pem
/certbot/config/live/qttc.net/privkey.pem
然后我把这两证书按照以下方式挂载到容器里
docker-compose.yaml
services:
nginx:
image: nginx
ports:
- 80:80
- 443:443
volumes:
- /nginx.conf:/etc/nginx/conf.d/default.conf
- /certbot/config/live/qttc.net:/ssl
...
最近写一个Node.js的项目，使用ts-node做为运行时，在使用top-level await的时候，遇到了一些问题。
我是在VSCode里写的项目，实际上我debug模式和生产部署都是使用ts-node，感觉非常方便，一个配置都不需要就能这么Run起来。
但是我在处理Mongo/Redis链接时，为了图省事，我想直接在await connect()，结果启动程序报错:
SyntaxError: await is only valid in async functions and the top level bodies of modules
...
课程列表中有一门Java编程课程，其中有一个实验作业是模仿Windows自带的计算器做一个非常简单的计算器，但由于目前没有使用Windows，于是只能仿着MacOS自带的计算器实现了一个，初次接触Java，也初次接触swing。
我没有具体研究过计算器的各项功能，仅凭自己简单的使用经验写了一个，具体实现以下功能。
...
这是一个同事遇到的问题，他说他用kubeadm初始化一个集群后，一切看着正常，但pod网络之间不通，不知道哪里出错了。我其实是有点害怕解决这样的问题的，因为k8s的绝大部分问题都是网络问题，而且还不好定位解决，也就是说可能你花了很长时间也未必找到问题，所以我通常建议要不就重新初始化。但同事说初始化好几回了，问题依旧存在，听到这里我觉得不得不直面问题了。
一顿排查，发现IPVS没有相关的规则，为什么没有相关规则呢？顺着问题接着排查，最后看到kube-proxy有这样一段可疑的信息
...
这应该称得上他俩这个时期爱好的标签了，只要有任何机会就要坐电梯，无论是扶梯还是直梯，他还会仔细观察电梯有多宽，有什么按钮，应急按钮是干什么的，还误按了几次应急按钮（实在是防不住）
家附近有一个商场，他俩开始学会走路后，那会正直疫情封控，能去的地方非常少，于是夏天就喜欢带他俩去商场里溜达。
只要一进商场，路线就已经给你规划好了，拉着你坐各式各样的扶梯，只要他能看见的，基本都要坐。那个时期我比较痛苦，因为他俩胆子还小，走路要抱着我的腿，两个小孩一人抱一腿，他俩的头正好顶我的屁股上，我走路就跟企鹅一样，时间长了非常累。一开始我以为这是小孩有什么特殊的原因，后来也就慢慢理解了，喜欢坐电梯的小孩还挺多的。
...
大环境差，公司刚经历一波裁员，我的团队也全部解散了。工作也没有之前那么忙了，正好也可以抽时间完成之前一直在计划但没有做的事
转眼，2024年已到来，两个宝宝也迎来了4岁生日！不少人回想过去通常会觉得很艰辛，的确，非常感谢我老婆无比艰辛的怀两个宝宝最后顺利出生。
...
2023～相信看到我这篇文章的大多数IT行业的朋友都受到了2023经济低迷的影响，降薪裁员一片哀嚎～，就连家底殷实的大厂也不例外。要说这个时期有没有逆势者可能大觉都共认华为了，一机难求，它给中国制造提振了不少信心，问界汽车一把做到龙头位置，其它当然还有芯片、国产系统产业都是逆势归来。人们在经历不幸时总会展望来年，我也不例外，经历了2023团队解散、降薪、业务线停滞等种种事之后自然就在思考2024会好起来吗？
时间飞快，7月团队解散，转眼就2024的元旦了。公司也并没有消停，经过2024年的市场预期，计算了一下现有的成本，发现还得继续裁员才能做到成本持平，这让我想起了前段时间我看的一本萨希尔·拉文吉亚写的《小而美》,作者一直努力想让自己公司变成独角兽，但是至少少数公司能成为独角兽，大多数公司能盈利就不错了，之前有过相关的创业数据称平均一家创业公司的存活周期是2年，也就差不多天使轮之后要么成要么黄。
...
今天需要把一个clickhouse的实例转移到另外一个实例，本来要使用clickhouse-backup工具，但最终总是导出metadata，没有包含实际数据，没办法只能放弃，使用脚本的方式导出建表语句，再导出CSV的数据。
然而在导出建表语句的时候，非常奇怪，在clickhouse CLI下总是看起来正常
$ SHOW CREATE TABLE analysis.spm_dictionary
SHOW CREATE TABLE analysis.spm_dictionary
Query id: 0bd7cb9d-b92a-4625-9ca9-eb306ce77fd3
┌─statement───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE analysis.spm_dictionary
(
`spm_b` String,
`name` String
)
ENGINE = MergeTree
ORDER BY spm_b
SETTINGS index_granularity = 8192 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
1 row in set. Elapsed: 0.014 sec.
...