这是一篇翻译文章，觉得确实很有启发，所以发出来大家一起看看。

我们现在做RAG应用，对于tokens确实很敏感，能省一些是一些吧，但是这篇文章是针对英文的，不知道对于中文支持的怎么样？

我们后面也会真正用起来，会再给大家汇报一下使用效果，或者会发布我们自己的改良方法。

感谢原作者：Iulia Brezeanu，原文和引用在文末。

推理过程是使用大型语言模型时消耗资金和时间成本的因素之一，对于较长的输入，这个问题会更加凸显。下面，您可以看到模型性能与推理时间之间的关系。

小型模型每秒生成更多的tokens，往往在Open LLM排行榜上得分较低。增加模型参数大小可以提高性能，但会降低推理吞吐量。这使得在实际应用中部署它们变得困难[1]。
提高LLMs的速度并减少资源需求将使其能够更广泛地被个人或小型组织使用。

对于提高LLM的效率，目前大家提出了不同的解决方案来，有些人会关注模型架构或系统。然而，像ChatGPT或Claude这样的专有模型只能通过API访问，因此我们无法改变它们的内部算法。

本文我们将讨论一种简单且廉价的方法，该方法仅依赖于改变输入给模型的方式——即提示压缩。

阅读全文

开始

AI领域最近的风声：2024是RAG爆发年。

对于这些信息，我的理解是这样的：

LLMs属于Infra，属于大厂和已经被资本投资的“AI大厂”们玩的，2023年大部分的投资也都是大额的，聚焦在LLMs这一领域。但是LLMs要找到健康的商业模式，必须与更丰富的业务场景结合起来，就需要大量基于LLMs的应用去拓展市场，不论是toC还是toB。所以到了Q4，有些资本已经在讨论2024年的投资要更加分散，更关注AI原生应用。作为基于LLMs应用支撑技术的RAG，也就必然会被特别关注，我想这就是所谓的2024是RAG爆发年的道理了。

但是今天我不是来讨论RAG的，虽然公众号“土猛的员外”是有很明显的RAG标签的，我今天更想讨论的是AI原生应用（AI-Native App）这个话题：

• 什么是AI原生应用？
• AI原生应用有什么不同之处？
• AI原生应用的猜想

什么是AI原生应用？

当电动机出现时

在讲什么是AI原生应用之前，我们可以先来看看电动机在最开始时候的应用。

阅读全文

主要内容：

RAG在我们产品体系中的定位；

TorchV RAG的技术选型；

RAG知识目录

0.开始

从9月份开始在微信公众号分享RAG技术以来，收获了很多来自业界的认可和鼓励，所以11月中旬从老东家离职之后就和小明开始了创业之旅——创建了TorchV品牌，主要是围绕RAG+LLM的产品研发和应用销售。经过一个多月的努力，我们已经有了一个基础架构和一个产品。当然和规划中的成型战力还有一定的距离，但是依然可以分享一下RAG在TorchV产品体系中应用情况，主要包含以下三个问题：

• TorchV如何围绕RAG打造产品体系？
• TorchV RAG的技术选型；
• 常见问题。

阅读全文

昨晚和小明在讨论elasticsearch的检索，整整写了三黑板。主要原因是elasticsearch的检索有knn（其实是ann，前面文章有讲过）和bm25两种，如何在不同的场景（针对不同客户）设置不同的boost比例就变得非常重要。昨晚讨论的最终结果是在针对不同的客户（租户）都分别拉出五个参数，便于在面对不同客户场景时可以将检索准确度做到最佳。

可以简单展示一下其中的三个参数：

• boost：这是es自带的参数，取值0-1，一般是用来控制混合检索中BM25和KNN的分值占比的。我们内部会写成boost * BM25_SCORE+(1-boost) * KNN_SCORE。也就是说，boost=1，那么就完全用BM25的得分来排序了，以此类推；
• kms：kNN_min_score，取值0-1，这是用来设置重排之后的knn得分最小值，低于这个值，我们认为RAG检索无召回。比如kms=0.6，就是重排之后得分低于0.6的结果都不需要。如果所有召回的结果都低于0.6，那么就看下一个参数f_llm；
• f_llm：finally_llm，True | False，默认是False。如果设置成True，那么在某次检索中所有召回结果分值都低于kms的时候，系统会将用户的原始Query直接给到LLM。否则，系统会告诉用户，“据已知资料，无法回答您的问题！”

阅读全文

看到O’Reilly的调查好文，翻译转发分享给大家。

本文的主要内容：

• 企业是如何使用生成式AI的？
• 在使用中遇到了哪些瓶颈？
• 企业希望生成式AI可以解决哪些缺陷和差距？

生成式AI是2023年最大的科技故事。几乎每个人都玩过ChatGPT、Stable Diffusion、GitHub Copilot或Midjourney。一些人甚至试用了Bard或Claude.ai，或者在他们的笔记本电脑上运行Llama（或Llama.cpp）。每个人都对这些语言模型和图像生成程序将如何改变工作的本质、迎来奇点、甚至可能毁灭人类有着自己的看法。在企业中，我们看到了从大规模采用，到严格限制，甚至禁止使用生成式AI的风向变化。

现实是什么?我们想知道人们到底在做什么，所以在9月份我们调查了O’Reilly的用户。我们的调查重点是：

• 企业是如何使用生成式AI的？
• 在使用中遇到了哪些瓶颈？
• 企业希望生成式AI可以解决哪些缺陷和差距？

调查报告主要内容

阅读全文

本文主要内容：

大模型LLM为什么会有幻觉？

“消灭”幻觉的四个主要方法

幻觉如何检测

在之前我一篇文章比较受欢迎的文章《大模型主流应用RAG的介绍——从架构到技术细节》中提到了大语言模型（LLM）的主要缺点有三点：

• 幻觉问题：大模型的底层原理是基于概率，所以它有时候会一本正经胡说八道，比如我们问大模型的问答系统，“良渚博物院下周一开门吗？”我相信这样的问题你不能连续问，因为大模型会有一定的几率告诉你开门。而如果游客真的在下周一去了良渚博物院，那估计就要失望了，如果这个Chat还是博物院官方提供的，那事情最终会演变成一通12345的投诉电话。所以在很多需要非常精确的场景，仅仅依赖GPT的这种生成式回答是很不严谨的，而且看起来很难消除。
• 新鲜度问题：规模越大（参数越多、tokens越多），大模型训练的成本越高。类似OpenAI的ChatGPT3.5，目前的数据新鲜度依然保留在2021年，对于之后的事情就不知道了。而且对于一些高时效性的事情，大模型更加无能为力，比如帮我看看今天晚上有什么电影值得去看？这种任务是需要去淘票票、猫眼等网站先去获取最新电影信息的，大模型本身无法完成这个任务。
• 数据安全：OpenAI已经遭到过几次隐私数据的投诉，而对于企业来说，如果把自己的经营数据、合同文件等机密文件和数据上传到互联网上的大模型，那想想都可怕。如果企业人员想提一个类似这样的问题：“帮我看看3月份XX部门的销售环比数据与哪些兄弟部门的增长是密切相关的？”，这需要打穿企业内部的很多数据。既要保证安全，又要借助AI能力，那么最好的方式就是把数据全部放在本地，企业数据的业务计算全部在本地完成。而在线的大模型仅仅完成一个归纳的功能，甚至，LLM都可以完全本地化部署。

这三个问题中，“新鲜度问题”已经基本上被解决了，像GPT-4 Turbo这样的最新大模型已经有类似RAG（Retrieval Augmented Generation，检索增强生成）这样的技术，可以借助外挂快速吸收最新知识（世界知识）。剩下的两个问题，“数据安全”最好的解决方案当然是本地化，敏感数据不上公网才是最安全的。次之的解决方案是使用可信度更高的大模型厂商，他们肯定都有基本的职业操守。当然这不是本文主要讨论的问题。好了，剩下最棘手的就是大模型的“幻觉问题”了，所以今天我们主要来讲讲幻觉，以及如何“消灭”幻觉。

幻觉产生的原因

就大语言模型（LLM）本身来说，可能是永远无法消除“幻觉”的，就像Sam Altman说：“幻觉和创造性是等价的”。这个概念我似乎很早就理解了，因为就像生物进化一样，只有不稳定的随机性才能带来的多样性，而多样性才能让物种穿越周期不断进化。

阅读全文

本文重点：

用弹子球机来展示大语言模型的一些内部原理

如何去调整参数，以达到我们想要的模型输出效果

今年5月份的时候我说国内真正使用过ChatGPT的人不超过5%，但是到了11月份，我再和企业、政府等的一些客户交流时，已经很难再碰到整个交谈过程中不说大语言模型（LLM）的了。但是说实话，大部分人对于LLM的了解还是很“新闻”化的，看到了现象但不达本质，往往造成了对LLM的“神化”。所以今天这篇文章，我希望用相对不那么技术化的描述来讲讲LLM的一些原理和概念，让大家对LLM有更近一步了解，也许对大家后面使用LLM及其应用有一定的帮助。

首先做个说明：本文不会讲太多数学公式，我会尽量保证非数学、统计专业的朋友可以看懂。

弹子球机

今年2月份我写过一篇关于GPT的文章《ChatGPT会给文旅行业带来什么改变》，里面提了一下ChatGPT的原理，如下图所示。

当时说的是假设我们有一个弹子球机器，把各种不同（颜色、重量、尺寸）的球从顶部扔进去，球会和里面的这些柱子（杯子上方的这些圈圈）相碰撞，最终掉下来，落进最下面的杯子里。我们期望机器可以做到”红色的球最终掉进红色的杯子，蓝色球掉进蓝色杯子，依次类推“，我们可以做的事情是调整机器里面的柱子（假设这些柱子表面是不规则的，而且我们可以旋转这些柱子）。

阅读全文

上周算是我正式离职创业的第一周，拜访客户、行业交流、选办公场地、置办办公设备等等，很多时间不在电脑面前，所以上周没更新任何文章。嗯，那就这周补上，发两篇！

今天这篇是上周本来就想写的，就是OpenAI DevDay（开发者大会）之后，基于大模型及相关的创业项目前景如何。

阅读全文

本文主要内容：

• 为什么一般情况下RAG的检索相关性存在问题？
• Rerank为什么可以解决这个问题？
• 几种常用Rerank组合评测；
• 如何在自己的产品中使用Rerank？

检索增强生成（RAG）是解决大语言模型（LLM）实际使用中的一套完整的技术，它可以有效解决LLM的三个主要问题：数据时效性、幻觉和数据安全问题（在我之前的文章《大模型主流应用RAG的介绍——从架构到技术细节》中有详细介绍）。但是随着RAG越来越火热，使用者越来越多，我们也会发现用的好的人/团队其实还是不多的。这也是RAG常被人吐槽的一点：入门简单，用好却非常难！

对于RAG的效果，我们之前已经做了很多方面的优化了，包括：

• 优化内容提取的方法：从源头解决内容提取的有效性，包括文本内容、表格内容（保留制表符）和图片内容（OCR识别）等，可以参看我之前的文章《完全指南——使用python提取PDF中的文本信息（包括表格和图片OCR）》；
• 优化chunking：从最开始的512固定长度切分，到后面的句切分，再到后面的NLTK和SpaCy，具体可参见我之前写的《最详细的文本分块(Chunking)方法——可以直接影响基于LLM应用效果》；
• 再之后是优化embedding模型：Embedding模型的选择其实很魔性，我们在优化过程中也会不断否定之前的一些判断。比如我们最开始用m3e，后面用bge，再后面还用了通义千问的embedding模型。总体来说，收费的通义千问还是好一些，但是不明显，有些方面却不如bge。最近一朋友也向我推荐了Jina embedding模型，不过他们的中文模型需要12月份才出来；
• 我们还优化了其他一些过程：比如prompt模板、关键词摘要、元数据存储等。

这些优化确实给我们带来了非常好的效果，但不够！我们在一些客户的实践过程中，还是发现相关性效果不佳，甚至造成了其中一个客户选择了其他方案（使用RAG+GPT-4的方案）。

我们还是坚持用国产大模型（如Baichuan2-13B、ChatGLM3-6B和QWen-14B等），毕竟主要服务的还是国内客户，加上现在接触的多数客户其实都有私有化部署的需求。所以我们进行了一段时间的探索，发现我们还有一项很有效的优化没有去做——ReRank。

所以，虽然Rerank优化我们还在做，但是今天我们可以先聊聊ReRank这个话题。

为什么需要Rerank

我们发现，在10月中旬之前，国内外的互联网上很难发现Rerank相关的话题。有少量人提到了，但是基本上都没有提到解决方案。我和小明在讨论Rerank的时候其实是先从提问题开始的。

阅读全文

在构建检索增强生成(RAG)管道时，一个关键组件是Retriver。我们有各种各样的Embedding模型可供选择，包括OpenAI、CohereAI和开源的Sentence-Transformers。此外，CohereAI和Sentence-Transformers也提供了一些重新排序器。

但是有了这些选项，我们如何确定最佳组合以获得一流的检索性能呢？我们如何知道哪种Embedding模型最适合我们的数据?或者哪个重新排名对我们的结果提升最大?

在这篇博文中，我们将使用LlamaIndex的检索评估（Retrieval Evaluation）模块来快速确定Embedding和重新排名模型的最佳组合。让我们开始吧！

让我们首先从理解检索评估（Retrieval Evaluation）中可用的度量标准开始。

理解检索评价中的度量标准

为了衡量我们的检索系统的有效性，我们主要依赖于两个被广泛接受的指标:命中率和**平均倒数排名(MRR)**。让我们深入研究这些指标，了解它们的重要性以及它们是如何运作的。

命中率:

Hit rate计算在前k个检索文档中找到正确答案的查询比例。简单来说，它是关于我们的系统在前几次猜测中正确的频率。

平均倒数排名(MRR):

对于每个查询，MRR通过查看排名最高的相关文档的排名来评估系统的准确性。具体来说，它是所有查询中这些秩的倒数的平均值。因此，如果第一个相关文档是顶部结果，则倒数排名为1;如果是第二个，倒数是1/2，以此类推。

现在我们已经确定了范围并熟悉了参数，是时候深入实验了。想要亲身体验，你也可以使用我们的谷歌Colab笔记本

设置环境

1

!pip install llama-index sentence-transformers cohere anthropic voyageai protobuf pypdf

设置各种key

1
2
3
4

openai_api_key = 'YOUR OPENAI API KEY'
cohere_api_key = 'YOUR COHEREAI API KEY'
anthropic_api_key = 'YOUR ANTHROPIC API KEY'
openai.api_key = openai_api_key

下载数据

本次实验我们将使用Llama2论文吧。

1

!wget --user-agent "Mozilla" "https://arxiv.org/pdf/2307.09288.pdf" -O "llama2.pdf"

加载数据

让我们加载数据。我们将使用从第1页到第36页进行实验，不包括目录、参考文献和附录。

然后将该数据解析为节点，节点表示我们想要检索的数据块。我们确实使用chunk_size为512。

1
2
3
4

documents = SimpleDirectoryReader(input_files=["llama2.pdf"]).load_data()

node_parser = SimpleNodeParser.from_defaults(chunk_size=512)
nodes = node_parser.get_nodes_from_documents(documents)

生成问题-上下文对:

为了评估的目的，我们创建了一个问题-上下文对的数据集。这个数据集可以被看作是我们数据中的一组问题及其相应的上下文。为了消除评估Embedding(OpenAI/ CohereAI)和重新排序(CohereAI)的偏见，我们使用Anthropic LLM来生成问题-上下文对。

让我们初始化一个prompt模板来生成问题-上下文对。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# Prompt to generate questions
qa_generate_prompt_tmpl = """\
Context information is below.

---------------------
{context_str}
---------------------

Given the context information and not prior knowledge.
generate only questions based on the below query.

You are a Professor. Your task is to setup \
{num_questions_per_chunk} questions for an upcoming \
quiz/examination. The questions should be diverse in nature \
across the document. The questions should not contain options, not start with Q1/ Q2. \
Restrict the questions to the context information provided.\
"""
llm = Anthropic(api_key=anthropic_api_key)
qa_dataset = generate_question_context_pairs(
    nodes, llm=llm, num_questions_per_chunk=2
)

过滤句子的功能，比如— Here are 2 questions based on provided context

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# function to clean the dataset
def filter_qa_dataset(qa_dataset):
    """
    Filters out queries from the qa_dataset that contain certain phrases and the corresponding
    entries in the relevant_docs, and creates a new EmbeddingQAFinetuneDataset object with
    the filtered data.

    :param qa_dataset: An object that has 'queries', 'corpus', and 'relevant_docs' attributes.
    :return: An EmbeddingQAFinetuneDataset object with the filtered queries, corpus and relevant_docs.
    """

    # Extract keys from queries and relevant_docs that need to be removed
    queries_relevant_docs_keys_to_remove = {
        k for k, v in qa_dataset.queries.items()
        if 'Here are 2' in v or 'Here are two' in v
    }

    # Filter queries and relevant_docs using dictionary comprehensions
    filtered_queries = {
        k: v for k, v in qa_dataset.queries.items()
        if k not in queries_relevant_docs_keys_to_remove
    }
    filtered_relevant_docs = {
        k: v for k, v in qa_dataset.relevant_docs.items()
        if k not in queries_relevant_docs_keys_to_remove
    }

    # Create a new instance of EmbeddingQAFinetuneDataset with the filtered data
    return EmbeddingQAFinetuneDataset(
        queries=filtered_queries,
        corpus=qa_dataset.corpus,
        relevant_docs=filtered_relevant_docs
    )

# filter out pairs with phrases `Here are 2 questions based on provided context`
qa_dataset = filter_qa_dataset(qa_dataset)

自定义检索:

为了识别最优的检索器，我们采用了Embedding模型和重新排序器的组合。首先，我们建立一个基本的VectorIndexRetriever。检索节点后，我们引入一个重新排序器来进一步优化结果。值得注意的是，在这个特殊的实验中，我们将similarity_top_k设置为10，并使用reranker选择top5。但是，您可以根据具体实验的需要随意调整此参数。我们在这里用OpenAIEmbedding显示代码，请参阅笔记本获取其他Embeddings的代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

embed_model = OpenAIEmbedding()
service_context = ServiceContext.from_defaults(llm=None, embed_model = embed_model)
vector_index = VectorStoreIndex(nodes, service_context=service_context)
vector_retriever = VectorIndexRetriever(index=vector_index, similarity_top_k = 10)
class CustomRetriever(BaseRetriever):
    """Custom retriever that performs both Vector search and Knowledge Graph search"""

    def __init__(
        self,
        vector_retriever: VectorIndexRetriever,
    ) -> None:
        """Init params."""

        self._vector_retriever = vector_retriever

    def _retrieve(self, query_bundle: QueryBundle) -> List[NodeWithScore]:
        """Retrieve nodes given query."""

    retrieved_nodes = self._vector_retriever.retrieve(query_bundle)

    if reranker != 'None':
      retrieved_nodes = reranker.postprocess_nodes(retrieved_nodes, query_bundle)
       else:
          retrieved_nodes = retrieved_nodes[:5]
         
       return retrieved_nodes

    async def _aretrieve(self, query_bundle: QueryBundle) -> List[NodeWithScore]:
        """Asynchronously retrieve nodes given query.

        Implemented by the user.

        """
        return self._retrieve(query_bundle)

    async def aretrieve(self, str_or_query_bundle: QueryType) -> List[NodeWithScore]:
        if isinstance(str_or_query_bundle, str):
            str_or_query_bundle = QueryBundle(str_or_query_bundle)
        return await self._aretrieve(str_or_query_bundle)

custom_retriever = CustomRetriever(vector_retriever)

评估

为了评估我们的检索器，我们计算了平均倒数排名(MRR)和命中率指标:

1
2
3
4

retriever_evaluator = RetrieverEvaluator.from_metric_names(
    ["mrr", "hit_rate"], retriever=custom_retriever
)
eval_results = await retriever_evaluator.aevaluate_dataset(qa_dataset)

结果:

我们对各种Embedding模型和重新排序器进行了测试。以下是我们考虑的模型:

向量模型:

• OpenAI Embedding
• Voyage Embedding
• CohereAI Embedding (v2.0/ v3.0)
• Jina Embeddings
• BAAI/bge-large-en

Rerank模型:

• CohereAI
• bge-reranker-base
• bge-reranker-large

值得一提的是，这些结果为这个特定数据集和任务的性能提供了坚实的见解。但是，实际结果可能会根据数据特征、数据集大小和其他变量(如chunk_size、similarity_top_k等)而有所不同。

下表展示了基于命中率和平均倒数排名(MRR)指标的评估结果:

分析:

Embedding性能:

• OpenAI:表现出顶级的性能，特别是cohererank(0.926966命中率，0.865262 MRR)和big-reranker-large(0.910112命中率，0.853993 MRR)，表明与重排名工具的兼容性很强。
• big-large:在重新排序器上有了显著的改进，CohereRerank的结果最好(0.865169命中率，0.805618 MRR)。
• llm-embedder：从重新排名中受益匪浅，特别是CohereRerank (0.887640命中率，0.825843 MRR)，它提供了实质性的性能提升。
• **coherhere **: coherhere最新的v3.0Embeddings优于v2.0，并且通过集成本地CohereRerank，显着提高了其指标，拥有0.876404命中率和0.832584 MRR。
• Voyage:具有较强的初始性能，并被cohererank (0.915730命中率，0.847940 MRR)进一步放大，表明对重新排名的响应性较高。
• JinaAI:虽然起点较低，但big -rerank -large的收益显著(命中率0.601124,MRR 0.578652)，表明重新排名显著提升了它的性能。其性能不佳的一个潜在原因可能是Embedding针对8K上下文长度进行了优化。

重新排名的影响:

• **WithoutReranker **:为每个Embedding提供基准性能。
• bge-rerrank-base:通常可以提高Embeddings的命中率和MRR。
• bge-rerank-large:此rerank通常为Embeddings提供最高或接近最高的MRR。对于一些Embeddings，它的性能可以与 cohererank相媲美或超过。
• **Cohererank **:始终如一地提高所有Embeddings的性能，通常提供最好或接近最好的结果。

重新排序的必要性:

• 数据清楚地表明重新排名在优化搜索结果中的重要性。几乎所有的Embeddings都受益于重新排序，显示出更高的命中率和mrr
• 重新排序器，特别是CohereRerank，已经证明了它们将平均表现的Embedding转化为具有竞争力的能力，正如JinaAI所看到的那样。

整体优势:

• 当考虑到命中率和MRR时，OpenAI + CohereRerank和Voyage + big-reranker-large的组合成为最热门的竞争者。

• 然而，cohererank/big-reranker-large reranker在各种Embeddings中所带来的持续改善，使它们成为提高搜索质量的突出选择，无论使用的Embedding是什么。

综上所述，为了实现命中率和MRR的峰值性能，OpenAI或Voyage Embeddings与cohererank/big-reranker-largeReranker的组合脱颖而出。

结论:

在这篇博文中，我们演示了如何使用各种Embeddings和重新排序器来评估和提高检索器的性能。以下是我们的最终结论。

• Embeddings:OpenAI和 VoyageEmbeddings，特别是当与CohereRerank/big-reranker-large reranker配对时，为命中率和MRR设定了黄金标准。
• 重排器:重排器的影响，特别是cohererank/big-reanker-large，怎么强调都不为过。它们在提高许多Embeddings的MRR方面发挥了关键作用，显示了它们在使搜索结果更好方面的重要性。
• 基础是关键:为初始搜索选择正确的Embedding是至关重要的;如果基本搜索结果不好，即使是最好的重新排名器也帮不上什么忙。
• **一起工作:**为了获得最好的寻回犬，找到Embeddings和重新排序的正确组合是很重要的。这项研究表明，仔细测试并找到最佳配对是多么重要。

原文：https://blog.llamaindex.ai/boosting-rag-picking-the-best-embedding-reranker-models-42d079022e83