大家好,这里是最佳拍档,我是大飞
近期大家应该都知道
ChatGPT的访问量有所下降
引发了很多激烈的讨论
不过这并不意味着开发者对整个AIGC的热情有所减少
因为从Google Trends的趋势可以看出
LangChain的热度依然只增不减
原因就在于LangChain作为大模型能力“B2B2C”的一个重要的中间站
能够将大模型和其他的项目
丝滑地连接在一起
达到1+1大于3的效果
大家现在也都比较清楚的是
提高大模型应用性能的一个关键手段
就是将大语言模型和外部数据相结合
具体而言就是让大语言模型接入现成的数据集
并且要求AI应用能够记住用户的对话
通过“反思”对话上下文生成“新的记忆”。
当用户在AI应用中进行检索时
应用系统会先在现有数据集中提取相关信息
然后结合用户查询以及记忆的上下文
最终高效准确地返回检索结果
因此LangChain+向量数据库就是一个最好的方式
为了帮助开发者们深入理解使用LangChain和向量数据库
进行语义搜索的原理及实例,最近
LangChain的联合创始人兼首席执行官哈里森·蔡斯
联合向量数据库厂商Zilliz
进行了一次干货满满的直播讨论
共同探讨了如何使用LangChain和向量数据库进行语义搜索
以及在此过程中可能会遇到的一些典型案例
由于视频较长
大飞我对重点内容做了一些总结
跟大家分享一下
首先哈里森回答了一下
什么是检索的问题
他认为
检索是指从内存或者其他存储设备中
获取信息的过程
那么
如何利用检索技术、向量数据库、AI代理等技术
来搭建一个接入外部知识库的大语言模型应用呢?
哈里森表示
尽管现在大语言模型功能强大
但是在使用上还存在一些限制
比如大语言模型只能记住预先训练时的信息
这就意味着
大语言模型并不能够做到实时更新数据
举个例子,刚开始的时候
ChatGPT的数据仅涵盖2021年及以前的数据
因此当时ChatGPT无法回答2021年之后的信息
只有等他开放了插件的系统之后呢
才能够获取实时的数据
除此之外
大语言模型还缺乏特定领域的专业信息
比如跟特定业务相关的数据
在这种情况下
检索技术就能够作为一种补充的形式
帮助我们打破大语言模型本身的使用限制
换言之
检索技术能够为大语言模型应用提供更多信息上下文
从而帮助它返回更准确的答案
那么检索技术的主流用例之一
就是语义搜索
哈里森解释了语义搜索如何在CVP架构中
也就是ChatGPT+Vector Database+Prompt
架构里边
来发挥它的作用,如图所示
如果用户提出了一个一般的问题
并且大语言模型可以回答
那么它就会直接返回问题的答案
但是
如果用户提出的问题是特定领域的专业问题
那么这个问题会被转化为向量
并被发送到向量数据库中
而向量数据库中已经预先存储了一些专业文档片段的embedding向量
当用户的专业问题向量被发送到向量数据库后
会在数据库中进行相似性搜索
从而找到 “top-k”个最相关的结果
这些找到的结果
会与用户查询的问题
一同经过类似LangChain这样的AI代理处理
合并发送给大语言模型
最终返回令人满意的响应结果
由于语义搜索十分常用
并且能够有效解决多种大语言模型应用的问题
于是哈里森列举了5个语义搜索的典型案例
并且详细分析了每种情况
第一个案例,重复信息
如果数据库中存有许多重复的文档
检索信息会面临一些挑战
这些重复的内容其实不适用于大语言模型
会产生很多不必要的上下文
对于这个问题
哈里森提出了3种解决方案
第一种
通过语义搜索过滤掉类似的文档
例如在将提示发送到ChatGPT之前
LangChain会检索20-30个相似文档
并通过向量检索技术过滤掉或者绕过重复的文本
再将提示发送到ChatGPT
第二种
利用最大边际相关算法来优化多样性
这种搜索侧重于从其他检索到的向量中
获取相似和多样的结果
第三种,在存储之前对文档进行去重
但是,这种方法挑战性最大
因为需要大量的时间和精力
来确定一个相似性分数
用来判定文档是否重复
即便设置了一个相似性分数
它也未必十分准确
因为单个事物的单个向量维度差异巨大
分数稍有偏差,结果就会大相径庭
第二个案例是冲突信息
如果对于同一个问题
不同来源的数据会给出不同的回答
这样会导致信息冲突
如果将这些数据据全部都给到大语言模型
可能会导致大语言模型产生混乱
例如
用户想要通过大语言模型应用查询公司的休假政策
但是人力资源文件和一些临时会议记录
给出了不同的答案
对于这种情况
哈里森提出了以下2种解决方案
第一种是对来源进行优先级排序
并将优先级打分权重
加入到检索中
第二种是将所有源信息都传入生成的步骤
交由大语言模型来判断哪个信息源更可靠
第三个案例是时效性
我们都知道,信息需要不断的更新
才能保证信息的时效性
例如
公司的休假政策可能会偶尔更新
那么大语言应用需要能够确保给到用户
更新后的正确信息
对于这种情况
哈里森提出了3种解决方案
第一种
在检索中对最近的信息进行加权
从而完全过滤掉过时的信息
第二种,给生成的信息带上时间戳
这样就要求大语言模型优先选择更近期的信息
第三种,不断反思
也就是不断修订大语言模型对某一个话题的理解
第四个案例是元数据查询
在某些情况下
用户提出的问题更侧重于元数据信息而非内容本身
例如
用户可能会查询“1980年间关于外星人的电影”。
其中
“关于外星人的电影”这一部分可以进行语义搜索
而”1980年间“其实是需要通过精确匹配来筛选结果的
对于这种情况
哈里森建议在执行语义搜索检索之前
先加入一个元数据过滤器
这样一来
当用户查询”1980年间关于外星人的电影“时
其实会分为两个步骤
第一个步骤是元数据过滤器
通过精确匹配
先筛选出年份为1980年的电影
第二个步骤再进行语义搜索
查询筛选结果中”关于外星人“的电影
许多向量存储都允许在查询前
先通过元数据过滤器筛选数据
如果大家选择的向量存储器不支持在查询前进行元数据过滤
那么在语义搜索之后
再过滤数据也是一个可行的方案
第五个案例是多跳问题
用户可能会一次提出多个问题
这就会给语义搜索带来挑战
对于这种情况
哈里森建议使用像LangChain之类的AI代理工具
可以将问题分解为几个步骤
并使用语言模型作为推理引擎
来检索所需信息
但是这种方法的一个弊端
就是要多次调用大语言模型
导致使用成本较为高昂
对此
Zilliz的工程师建议集成GPTCache与LangChain
使用GPTCache来存储大语言模型生成的问题和答案
这样在用户下一次提出类似查询时
GPTCache会先在缓存中
搜索是否是已经问过的重复问题
之后如有必要
再执行语义搜索并调用大语言模型
这样一来
可以大大节省大语言模型的调用成本
那关于GPTCache
这是Zilliz开源的一个大语言模型的缓存服务
类似于Redis、MemCache这些服务的作用
我们有机会也可以详细做一期视频介绍一下
在最后的问答环节
哈里森也回答了几个问题
比如说对于如何写出好的prompt
哈里森认为关键在于要先明确自己想要什么
如果你无法清楚表达自己的意图
那么大语言模型也是不知道该怎么做的
这就和人类之间的交流一样
LangChain后续也会添加一些功能
帮助用户来优化Prompt
那谈到怎么看当前的赛道和其他竞品
哈里森认为整个文本检索和生成的赛道仍处于早期阶段
发展非常迅速
在文字检索阶段
LangChain模块化的架构可以支持自定义向量检索系统
更加具有灵活性
Vectara是一套出色的端到端全托管的检索解决方案
而LlamaIndex提供了一些更有趣的数据结构
例如树型结构,可供实验使用
在文字生成阶段
LangChain可以和其他方案进行集成
那谈到大语言模型正在不断放宽prompt的上下文字数限制
这对检索会有什么样的影响
哈里森认为
虽然Anthropic推出了支持10万上下文长度的
大语言模型上下文转换器插件
但是向量数据库提供了一种更加高效的解决方案
设想一下
如果大语言模型负责所有计算的工作
而向量数据库负责所有存储的工作
那么计算开销就会飞速上涨
这也就是说,处理的上下文越多
成本越高
这时我们就可以使用向量数据库来节省开销
计算总是比存储更贵的
有的甚至贵100多倍
而且使用上下文转换器
大语言模型仍有可能会忘记早期对话中的内容
好了,以上就是大飞对这次谈话
重点内容的总结归纳
有兴趣的同学可以去看一下原视频
地址我会放在视频说明里
需要简单填写几个信息,即可观看
本期的视频内容就到这里
感谢大家的观看
我们下期再见
发表回复