你有没有过这种体验 跟 AI 助手聊了半小时转头问它 “我刚才跟你说的那个需求还记得吗”它一脸 “我是谁我在哪” 逛电商搜 “小白鞋”出来的要么是标题里刚好有这三个字的老款要么是语义像但关键词不对的帆布鞋就是找不到你想要的那双 甚至做安全审核的时候要同时找长得像的头像、说法像的签名还有这些账号都在哪个群里得跑好几个系统等半天才能出结果原来这些看似不相关的场景背后都藏着同一个难题我们需要同时搞定关键词搜文本、相似度找向量、关系找图这三件事但过去这三件事得分开在三个不同的系统里做 —— 你要维护全文库、向量库、图数据库还要把三个系统的数据同步来同步去光是运维就能把人逼疯。但现在微信团队搞出了个狠活一张表把这三件事全搞定了。不用再搭建一堆系统不用再同步数据写一句 SQL 或者 Cypher就能同时拿到你要的所有结果。原来我们要同时搞定的三件事居然这么难在做这个功能之前团队跟很多业务同学聊过发现大家几乎都在遇到同样的痛点只是场景不一样而已。1. 风控审核找骗子居然要跑三个系统就拿反诈审核来说审核同学拿到一个骗子账号他要做什么先看头像有没有其他账号用了几乎一样的头像这就是向量检索找相似的再看签名有没有其他账号的签名里也有 “兼职日结”“扫码进群” 这种词这就是全文检索找关键词最后这些账号都在哪些群里有没有把它们拉到同一个群里继续骗人这就是图检索找关系过去这三步得跑三个系统向量库搜头像全文库搜签名图数据库查群关系然后把三个结果拼起来光是数据同步就得担心会不会有延迟会不会漏数据万一骗子刚改了签名同步没跟上那不就漏掉了2. 电商搜索搜个鞋怎么就这么难你逛电商搜 “小白鞋”你想要的是白色的休闲板鞋对吧 但如果只用关键词搜那标题里没写 “小白鞋”只写了 “白色板鞋” 的商品你就搜不到 如果只用向量检那可能会把语义相似的 “白色帆布鞋”“白色运动鞋” 都给你拉过来甚至漏掉你之前看过的、标题里刚好有 “小白鞋” 的那款你种草了很久的鞋。所以最好的办法就是同时跑两路向量召回语义相似的全文召回关键词命中的然后把两个结果融合起来这样既能找到你想要的语义相关的新品又不会漏掉你本来就想找的那款精准商品。3. 大模型记忆AI 怎么又忘了我刚说的话这个就更常见了你跟 AI 助手聊天你希望它能记住你之前说的所有话对吧 比如你跟它说 “我下周要去杭州出差帮我做个攻略”然后过了一会你问 “那我那边的天气怎么样”它得知道你说的是杭州而不是你所在的地方。这背后的 RAG 检索其实就是要同时做三件事向量召回你现在说的话和之前哪段聊天的语义最像全文召回你现在提到的“杭州”之前的聊天里有没有提到过图召回你之前跟我聊过的杭州的攻略和你说的天气有没有关联而且最关键的是你刚说完的话下一秒就得能被检索到不能等半天不然你刚发完消息问它它说没收到那体验就太差了。过去要做这些业务同学得自己搭一堆系统维护同步链路光是容灾、调权就能耗掉大半精力根本没时间好好做业务。全文检索不用再搭 ES 了一张表就能搞定那怎么把这些能力都塞到一张表里呢首先他们给原来的 FKVSQL 加了全文检索的能力。啥是 FKVSQL简单说就是微信团队做的一个在线表格数据库原来就已经能同时搞定 KV 点查和 SQL 查询了同一份数据你既可以像用 Redis 一样快速查某个 key也可以像用 MySQL 一样写复杂的 SQL 查询不用重复建表写入之后毫秒级就能查询现在已经在微信电商、企微安全、直播推荐这些业务里用了很久了。现在他们给它加了全文检索啥意思就是你不用再单独搭个 Elasticsearch 了也不用同步数据了直接在这张表里给你要搜的文本列加个索引就能用了。就像你去图书馆找书原来你得自己把书的关键词抄下来放到另一个小本子里找的时候先翻小本子再去找书现在图书馆直接给你做了个索引你拿着关键词直接就能找到对应的书不用自己再弄个小本子了。而且用起来特别简单你就写一句 SQL 就行-- 在我的消息里找和“红包转账”最相关的10条 null null WHERE uin 12345678;就这一句引擎内部就帮你把分词、召回、打分、排序全做了你不用自己切词不用自己算分数直接就能拿到结果。甚至你还能自己调参数比如长文本搜索的时候你可以设置最少要命中多少个关键词避免那种只命中了一个“客服”就把不相关的结果拉进来的情况而且还有专门的调试函数你要是搜不到东西直接就能看分词对不对一下子就能定位问题。性能也特别顶100 万行数据查 top10 的结果平均时延才 11 毫秒比你眨个眼还快就算是 1000 万行的全局搜索也才 60 多毫秒完全够在线场景用。向量检索不用再单独建个向量库了搞定了全文接下来就是向量检索。 过去你要做向量检索得单独建个向量库比如 Milvus、Pinecone 之类的然后还要把数据同步过去又多了一个要维护的系统写入的时候要写两次更新的时候要更两次删的时候也要删两次一不小心就数据不一致了。现在他们把向量检索的能力也接到了图数据库 WeGraphDB 里做了个向量顶点表啥意思就是你建表的时候直接把向量列也声明进去一张表里既有普通的标量列比如昵称、签名、地区也有向量列比如头像的向量。写入的时候你一条 INSERT 语句就把所有数据都写进去了不用分开写两个库引擎内部会自动把标量列存到 FKVSQL向量列存到向量检索的引擎里对用户来说完全透明你根本不用关心底层是怎么存的。检索的时候也一样你给我一个样例的头像向量我直接就能帮你找出最相似的20个账号就像你给我一张照片我帮你在一堆照片里找出长得最像的那几个一秒钟就能搞定。而且这个向量检索的能力可不是刚做的他们团队的 SimNet 向量检索已经在视频号的推荐里用了好几年了数十亿级的向量都能搞定性能杠杠的用了 GPU 加速之后成本还比原来低了一半多。最狠的一张表把图、向量、全文全搞定那现在全文有了向量有了图的能力本来 WeGraphDB 就有那能不能把它们三个合到一起 当然可以他们把 FKVSQL 作为 WeGraphDB 的存储后端这样一来一张顶点表里就能同时有图的能力查节点之间的关系比如谁和谁是好友谁在哪个群里全文的能力查文本的关键词比如签名里有没有 “兼职日结”向量的能力查向量的相似度比如头像是不是相似而且他们还做了个混合检索的接口你一键调用就能同时跑向量和全文两路检索然后把结果融合起来不用你自己拼。比如刚才的风控场景你要同时找相似头像和关键词签名你就写一句CALL search.hybrid(risk.users, $avatar_emb, signature, 兼职 日结, topK20);就这一句引擎内部会并发跑向量检索和全文检索然后用 RRF 算法把两个结果融合起来端到端的延迟几乎就是慢的那一路的时间不是两个加起来相当于你同时做两件事花的时间和做一件事差不多。这就相当于你去餐厅点单你要了可乐、汉堡、薯条原来你得分别去三个窗口买每个窗口排一次队现在你在一个窗口点单服务员同时给你把三样都拿过来你只需要排一次队花的时间和买一个东西差不多。而且最爽的是所有的数据都在一张表里你不用再维护三个系统不用同步数据不用担心中间出问题写入之后毫秒级就能查你刚加进去的新数据下一秒就能被检索到完全够在线场景用。落地案例大模型的记忆终于能用了那这个能力现在已经落地了吗当然最典型的就是微信的 WeCom Context也就是大模型的记忆服务。你用 AI 助手的时候是不是希望它能记住你所有的聊天记录不管你聊了多少它都能在你问的时候把相关的内容找出来然后回答你过去要做这个得同时跑向量召回、全文召回、图召回然后把结果融合起来用了这个新的能力之后所有的检索都在一张表里完成不用维护一堆系统而且新的聊天记录写入之后立刻就能被检索到你刚说完的话下一秒问它它就能记住。现在这个服务已经支撑了海量的大模型记忆场景不管是聊天助手还是企业的知识库都能用它来做 RAG又快又稳成本还低原来要花几个月才能搭建起来的系统现在几天就能搞定。原来我们要做图、向量、全文的检索得搭一堆系统维护一堆同步链路把自己搞得很累现在有了这个能力一张表就搞定了所有事业务人员只需要专注于自己的业务逻辑不用再操心底层的存储和检索了。这其实就是工程的魅力把复杂的东西藏在底层给用户最简单的接口让原来要花几个月才能搭起来的系统现在几天就能搞定。 最后问大家一个问题你平时用 AI 助手的时候最烦它记不住你说过的什么事或者你有没有遇到过搜东西的时候明明想要的内容就在那儿却因为只能用关键词或者只能用语义死活搜不到的情况来评论区聊聊你的经历吧