北京
一段Python代码，三行SQL，向量检索就跑起来了。没有独立的向量数据库服务，没有额外的索引构建流程，数据存在哪，向量就存在哪。
这是libSQL给出的路径：把向量当成表里的一列，用SQL直接查。
先建表。字段结构很直白：一个自增主键，一个文本字段，再加一个F32_BLOB(1536)类型的向量列。1536这个数字对应的是嵌入向量的维度，写进类型声明里，等于告诉数据库这一列存的是什么形状的数据。
写入也走标准SQL。插入语句里，文本参数正常传，向量参数外面套一层vector()函数，把序列化后的嵌入数据转成数据库认识的向量格式。整个插入过程没有引入任何新的客户端API，还是那个execute。
查询是这套方案里最关键的一步。一条SELECT语句，调用vector_distance_cos(embedding, vector(?))算出查询向量与表内每条记录之间的余弦距离，把结果起个别名dist，然后按dist排序，取前5条。
相似度检索在这里被压缩成了一次ORDER BY加LIMIT。没有专门的近邻搜索接口，没有需要单独维护的索引服务，距离计算和排序都发生在SQL执行过程中。
连接方式同样没有特殊之处。用环境变量里的URL和token创建同步客户端，之后所有操作都通过这个客户端执行。向量能力被嵌进了原有的数据库访问链路，而不是另起一套。
对已经在用libSQL的项目来说，这意味着加一个向量列、写几条带vector()的语句，就能把语义检索接进现有数据表。文本和向量放在同一张表里，查询时不需要跨系统拼数据。
这套写法的取舍也很清楚：向量检索的复杂度被交给了SQL层，开发者面对的是建表、插入、排序这些熟悉的概念，而不是一套新的向量数据库运维体系。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
