timescale 还是太迟钝了, 起了个大早干了个晚集,相当年可是为数不多拿到融资的PG时序数据库插件,我记得没错的话可能还是第一个拿到融资的PG插件,可是后面切换赛道有点慢,AI这趟车似乎一直没动作,没neon,crunchydata甚至后面的vectorchord,mooncake,paradedb动作快。现在才放出关键词搜索插件 pg_textsearch.
我早就说过 AI 搜索需要的是全家桶, 你先别管数据在什么产品里面, 我们就说AI 搜索, AI 没外脑, 仅仅凭它那训练过时数据生成的LLM的小脑瓜子, 能顶啥用?
AI 离了搜索就是过了气的老头, 脱离时代, 脱离社会, 脱离新技术, 脱离年轻人, 没啥鸟用.
所以搜索是AI 必须的.
那问题就来了, 谁说了搜索仅限于语义搜索? 这个不用争了吧, 不同的场景需要的数据是不一样的, 所以也需要关键词搜索、精确的标量搜索.
谁说了以上就够了呢? 还是场景、场景、场景啊~~~ 不同场景对数据的需求不一样啊同志们.
跟买房一样嘛, 地段地段还是地段嘛
你今天看到进入AI 搜索赛道的数据库还只有: 向量搜索、关键词搜索、标量搜索、混合搜索的能力.
未来, 马上就会出现OLAP的搜索需求、GIS的搜索需求、图的搜索需求、甚至更多, 总结一句话: 多模搜索能力.
AI 搜索要的是全家桶 !
好在国内已经很多产品意识到这点,开始面向AI搜索陆续推出产品了,例如:有分布式的全面解耦的晨章Eloq,单机加嵌入式的Oceanbase的seekdb。还有单机版的海量v100等。
回过头来看timescale 决定开源 pg_textsearch, 是不是有点迟钝. (之前开源的pg_vectorscale负责语义搜索)
vectorchord 早早就开源了三大件: vectorchord(负责向量语义搜索)、vectorchord-bm25和pg_tokenize(负责关键词搜索).
再回到数据库领域: 又回出现几大流派, 至少2大: 解决方案派、大一统派.
解决方案派:
你别管数据存哪里, 反正需求都满足你, 你要搜啥都行. 至于后面用什么技术、数据存多少份、有没有延迟、会不会经常出现数据错乱, 你别管.
大一统派:
数据就一份, 上面有多种计算引擎, 加速引擎, 你要的都在这. 全面解耦.
反正PG肯定是大一统派的, 插件太多了. 不过好在PG是单机版, 国产分布式版的全面解耦产品机会很多.
说了这么多, 我们还是看看pg_textsearch是啥吧?
pg_textsearch 是由 Timescale 团队开发的一个 PostgreSQL 扩展,旨在为 Postgres 提供高性能、现代化的全文搜索能力,特别针对 AI 工作负载和混合搜索(Hybrid Search)进行了优化。
以下是该产品的核心要点总结:
ts_rank,BM25 在相关性评分上更精准,能够提供类似 Elasticsearch 等专业搜索引擎的搜索质量。pgvector 或 pgvectorscale 配合使用。开发者可以在同一个数据库、同一个查询中结合“语义搜索”(向量)和“关键词搜索”(BM25),从而大幅提升搜索的准确性。<@>),让用户可以通过简单的 SQL 语句执行复杂的排名搜索。例如:ORDER BY content <@> 'search terms'。pg_textsearch 可以让你直接在 Postgres 内部完成高质量的搜索。pg_textsearch 的出现让 PostgreSQL 变成了一个更强大的集成式 AI 数据库。它消除了在数据库和搜索引擎之间同步数据的痛苦,同时通过 BM25 算法显著提升了内置搜索的质量。
PG 的AI搜索插件现在也是够卷的, 对用户来说是好事.
你怎么看?欢迎留言