上周在做 「根据描述来找到相关的API」。
因为API太长了，有超过10W+的token（主要是出参很多且描述比较详细），导致大模型幻觉严重，具体表现为给出的答案中有很多重复的语句。
所以考虑使用embedding来实现rag相关功能，然后就发现了embedding存在以下问题
一、切分不当导致语义匹配不上
一开始我的设计是，把整个API信息（名字、描述、入参、出参）进行embedding，然后与用户的query进行余弦相似度计算，找出相似度最高的30个API（后来调到80个）。
但有一个case始终匹配不到，我想要查询的「广告投放出价」，预期找到的接口为「获取广告列表」
但即使我把查找范围从30调整到80，也始终没法找到这个接口
原因就是这个接口太长了，他的语义和我输入的「广告投放出价」很难匹配
最后的解决办法就是：我不再对整个API信息进行embedding，而是对每一个入参、出参进行embedding来提高我的匹配度。
不过这导致原来我的向量数据库只有500条数据对应500个API，一下子变成了6000条数据
二、泛化能力太弱导致匹配不上
之后的一个case是，我想要查询「广告的点击率」，预计要找到的接口组合是「获取自定义报表字段」``「查询自定义报表」这两个接口。
但使用余弦相似度始终找不到，原因是这两个接口在描述里面没有提到广告点击率，仅仅靠余弦相似度的语义匹配是找不到的。
最后的解决办法是：我把「apiNameList」和「要查询的字段」扔给大模型来预先选出10个API，之后再考虑embedding出入参选择其他API。
三、现在我对embedding/RAG的看法
1.并非银弹，而是不得已之举，embedding是最粗也是最不得已才应该采用的方法。人工分层，比如将API/文档归类一下直接传给大模型，可能效果更好（类似claude skills的方法）。
2.要理解原理： 如果一定要做embedding，要理解其基于语义的原理，是线上要注意两点「构建时切分规则的选择」「查询时query的改写」，保证语义上能够匹配到
我是三选，阿里3年负责压测平台，目前在字节广告平台做to C 的AI Agent（已上线）。分享AI前沿技术和工程落地实践。原则是
「分享真实，solid的AI工程经验」「观点输出，讲些有用的」，公众号同名。