AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


RAG检索失败率降低49%?Anthropic-Contextual-RAG方案解析-兼看老刘的课堂三部曲
发布日期:2024-09-21 11:24:46 浏览次数: 1523


今天是2024年9月21日,星期六,北京,天气晴。

我们里看两件事,一个是关于Anthropic发布的RAG检索方案Contextual Retrieval embeddings + contextual BM25,PR稿件传言检索失败率降低49%,我们看下它到底怎么回事儿,并看下实际落地可能性

另一个事是关于老刘课堂的一个总结。

最近琢磨了件事儿,就是如何以一种更有效的方式来进一步挖掘现有社区已有积累的价值,因此做成一个个小的课堂,进一步细分成一个个的小知识点,然后可以进行自定义的观看(比如网盘播放),也可以更精准的找到相关的点

因此,我将社区线上分享做了进一步的剪辑整理,以形成了特定专题下的一些知识集合,正式推出老刘课堂三部曲,总共设置了知识图谱、大模型以及RAG几个专题,以便更好地发挥其价值,并帮助更多的人,这个是与技术社区安全独立的另一条线,也是一种最新的尝试。

供大家一起参考并思考,关注技术进展,总会有很多收获。

一、先看Anthropic发布的RAG检索方案

在传统的RAG中,文档通常被分成更小的块,以便高效检索。虽然这种方法对许多应用程序都很有效,但当单个块缺乏足够的上下文时,它可能会导致问题。

例如,收集了一套财务信息(例如,美国SEC文件)嵌入知识库中,收到了以下问题:“ACME Corp在2023年第二季度的收入增长如何?”

相关块可能包含以下文本:“公司收入比上一季度增长了3%。”然而,这个块本身没有具体说明它指的是哪家公司或相关时间段,因此很难检索到正确的信息或有效地使用这些信息。

为了解决这个问题,一个缓解方法是提供上下文

过去曾提出过使用上下文来改善检索的其他方法,包括:

  • 将通用文档摘要添加到块中:《Using Summaries in Document Retrieval》(https://aclanthology.org/W02-0405.pdf)

  • 假设文档嵌入HyDE:《Precise Zero-Shot Dense Retrieval without Relevance Labels》(https://arxiv.org/pdf/2212.10496)

  • 基于摘要的索引:《A New Document Summary Index for LLM-powered QA Systems》(https://www.llamaindex.ai/blog/a-new-document-summary-index-for-llm-powered-qa-systems-9a32ece2f9ec)

Anthropic发布RAG检索方案。Contextual Retrieval embeddings + contextual BM25:使用Claude为每个文本片段生成上下文,在进行嵌入处理之前,先将生成的上下文添加到每个文本片段的前面,然后生成嵌入表示,效果有提升:https://www.anthropic.com/news/contextual-retrieval

对应的实操地址在:https://github.com/anthropics/anthropic-cookbook/blob/main/skills/contextual-embeddings/guide.ipynb

其核心在于,为每一个chunk都生成上下文,这个涉及2个问题,一个是怎么生成上下文,一个是如何快速的生成上下文,因为chunk的量是特别大,贵且慢

1、如何生成上下文

手动注释知识库中的数千甚至数百万块将是太多工作。为了实现上下文检索,使用Claude,编写了一个提示,指示模型提供简洁、特定于块的上下文,使用整个文档的上下文来解释块,prompt如下:

生成的样例如下:

通常是50-100个token,在嵌入块之前和创建BM25索引之前,会附加到块上:

2、如何快速生成上下文

使用提示缓存来降低上下文检索的成本,通过提示缓存,无需为每个块传递参考文档,只需将文档加载到缓存中一次,然后引用之前缓存的内容。

其中,提到prompt缓存可以看看:https://github.com/anthropics/anthropic-cookbook/blob/main/misc/prompt_caching.ipynb,https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching。

基本实现机制为,就是很长的prompt,如果重复用到,就不需要再重新处理这部分,从而加快效率。当发送启用提示缓存的请求时:

  • 1、系统检查提示前缀是否已从最近的查询中缓存。
  • 2、如果发现,使用缓存版本,减少处理时间和成本。
  • 3、否则,会处理完整的提示并缓存前缀以备将来使用。

这种方式这对带有许多例子的提示、大量的上下文或背景信息、具有一致指令的重复性任务、漫长的多转对话等场景带来的收益较大,提示中充分利用prompt caching,可以将延迟减少超过2倍,成本降低高达90%。当构建涉及详细书籍内容的重复任务时,这可以产生显著的节省。

假设800个token块、8000个token文档、50个token上下文指令和每个块100个上下文tokem,生成上下文块的一次性成本为1.02美元/百万个文档token。

但是,缓存的寿命为5分钟,每次使用缓存内容时都会刷新。

在生成完上下文后,使用上下文嵌入,上下文BM25,根据其评估脚本(ttps://github.com/anthropics/anthropic-cookbook/blob/main/misc/prompt_caching.ipynb)可以将失败的检索数量减少49%,当与rerank相结合时,将检索次数减少67%。

对于不同embedding的组合消融实验,也可看底下的数据,也很有趣。

最后总结就是,这种方法的核心就是用大模型生成上下文,这个对于很长的文章,全放进去,这个其实也不太现实。

此外,基于prompt-cache,也只是解决了单次生成上下文的时间和费用,但次数并没有减少 ,因此,也很难实际落地

但与前几天说的memo也有异曲同工之妙,大家可以看看。



53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询