给个人笔记做轻量向量检索，我放弃重型向量库改用SQLite-vec的折腾过程

平时习惯用Markdown随手记技术踩坑、代码片段和零碎想法，几年下来积攒了四五千篇小文本。以前找东西靠grep或者本地编辑器的全局文本搜索，只要关键词记错一个字就搜不出来。前段时间想给这套笔记加个AI语义检索功能，把每篇笔记提取出向量存起来，敲一段大白话就能把意思相近的旧笔记翻出来。

我的个人服务都跑在一台华为云2核4G的轻量云服务器上，上面还挂着个人博客和几个定时抓取脚本，资源本来就比较紧凑。折腾了一圈，记录下在低配置机器上做个人向量检索的选型与踩坑。

最开始的念头是直接抄网上的成熟教程。
打开各类开源项目，推荐的清一色是Milvus、Qdrant或者Chroma。我用Docker Compose把其中一个向量数据库拉起来，刚启动什么数据都还没塞，后台常驻内存直接被吃掉了一点几个G，CPU占用时不时还弹一下。
看着监控我有点哭笑不得：我总共就四五千条短文本，全导出来转成JSON也就十几兆大小，为了这点数据量专门让一个重型分布式数据库24小时吃着我将近一半的内存，实在太浪费了。

后来在社区里翻到了SQLite-vec这个轻量方案。
它本质上是一个给SQLite扩展的纯C动态库，不需要常驻任何后台后台守护进程，就像普通SQLite一样以单一文件存储在磁盘上。用Python操作时，连额外的服务连接都不用起，直接在现有sqlite3连接里加载扩展，就能创建虚拟表跑向量相似度检索。对于个人单兵作战的项目来说，这种极简架构简直是救星。

但在低配的Linux云服务器上跑起来，还是遇到了几个细节坑。

第一个问题是系统自带的Python和SQLite版本太老，加载不了扩展库。
华为云服务器上装的系统镜像自带的Python标准库里，sqlite3模块编译时默认关闭了扩展加载功能（enable_load_extension），直接调load_extension会无情报错抛出Not supported。
一开始我差点想自己重新源码编译一套Python，后来发现完全没必要那么麻烦。用官方推荐的pysqlite3-binary包直接覆盖标准库的引用，几行代码把pysqlite3别名替换成内置sqlite3，就完美绕过了系统底层的限制，顺利载入.so动态库。

第二个问题是并发写入时的锁竞争。
我的笔记偶尔会在网页端随手写一篇保存，后台定时脚本也会偶尔同步一次。SQLite默认的日记模式（Rollback Journal）在发生写入时，会直接把整张表甚至整个数据库锁死。
有一次我把两百篇旧笔记批量转向量写入数据库，恰好前台网页正在发请求搜资料，前端直接卡住抛出database is locked的错误。
解决办法很简单，建库后第一时间执行一句PRAGMA journal_mode = WAL。开启WAL（预写式日志）模式后，SQLite允许多个读取操作和一个写入操作同时并行，读写互不阻塞，轻量并发场景下的锁冲突直接被化解。

第三个问题是向量维度带来的检索开销。
最开始我选了一个1024维的通用嵌入模型，算出来的向量浮点数特别长。四五千条数据存进去虽然文件不大，但在2核机器上做全局暴力扫表匹配时，单次检索耗时要两三百毫秒，CPU也会突然抽搐一下。
后来对比发现，对于个人笔记这种场景，换成512维甚至384维的小模型，语义相似度判定的准确度几乎没有任何肉眼可见的折损。
换成384维后，每个向量的体积缩小了一半还多，SQLite-vec在内存里做点积计算的吞吐量翻倍，单次检索响应时间压到了15毫秒以内，基本做到了敲完回车结果就瞬间跳出来。

改用这套方案跑了快一个月，整套检索功能用起来非常省心：
平时不需要管任何数据库进程的健康检查和内存泄漏，进程只有在执行搜索的瞬间占几兆内存，搜完即走；
所有笔记的内容和对应的向量全都打包在一个几十兆的.db单文件里，每天凌晨用一条定时命令把这个文件顺手同步备份到华为云OBS对象存储里，连备份策略都变得极其简单。

做个人开发有时候很容易被各种时髦的大架构牵着走。动辄起几个Docker容器挂重型中间件，往往超出了个人业务的实际需求。对于几万条以下级别的数据检索，善用轻量嵌入模型加上嵌入式数据库扩展，不仅省钱省内存，系统的稳定性和维护成本也比大而全的方案高得多。