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

今天这篇是上周本来就想写的，就是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

本文是一篇英文翻译转载文章，主要介绍了HNSW算法。

原文链接：https://dataman-ai.medium.com/search-like-light-speed-1-hnsw-c5b0d4665926

我喜欢《玩具总动员》里的太空护林员“巴斯光年”，我喜欢他的口头禅“飞向无限！” 当我搜索信息时，我也享受找到正确信息的速度。这一切都是因为高速互联网和足够的带宽吗？不完全是！事实上，近乎即时搜索结果的算法是至关重要的。信息检索速度是计算机科学中的一个重要课题。随着文本、图像或音频数据的大型语言模型（大语言模型）的高维Embeddings，信息检索的速度是数据科学中的一个优先课题。

在这篇文章中，我将讨论:

• NLP中的向量Embeddings
• KNN (K-Nearest Neighbors)无法跟上速度
• 近似最近邻(ANN)感觉就像光速
• 快速搜索的初始算法
• 理解分层导航小世界图算法(HNSW)
• 代码示例:Embedding新闻文章
• 代码示例:FAISS用于HNSW搜索

本文及其后续系列解释了使巴斯光年的梦想成为可能的最先进算法。您将对这一领域及其应用的重要性有一个景观理解。您将有动手编码示例。我们开始吧。

NLP中的向量Embeddings

向量Embeddings是自然语言处理（NLP）中的一个基本概念，是单词、句子、文档、图像、音频或视频数据等对象的数字表示。这些Embeddings的目的是捕获它们所表示的对象的语义和上下文信息。

让我们首先描述一下单词Embeddings。2014年，一个突破性的想法Word2Vec(发音为“Word - to - Vector”)在自然语言处理中被提出，它将单词或短语转换或“嵌入”为数字的高维向量，称为单词Embeddings。这些词Embeddings捕捉词之间的语义和上下文关系，使机器能够理解和使用人类语言。图1显示了三维空间中的高维向量。“铁（iron）”这个词与“火药（gunpowder）”、“金属（metals）”和“钢（steel）”等词很接近，但与“有机（organic）”、“糖（sugar）”或“谷物（grain）”等不相关的词相去甚远。例如，猫和狗的概念可能很接近。

图 (1)：文字Embeddings(图片来源:作者)

单词Embeddings可以实现单词的相似或不相似。这是一项了不起的创新。既然单词可以嵌入，为什么句子不能呢？这就是句子Embeddings的诞生。句子Embeddings捕获整个句子的语义和上下文信息，使机器能够理解和比较句子。生成句子Embeddings的常用方法包括Doc2Vec (Document-to-vector)。强大的基于llm的词Embeddings将成为NLP的标准，如BERT(来自Transformers的双向编码器表示)、ELMo(来自语言模型的Embeddings)、Llama(大型语言模型元AI，由Meta AI于2023年2月推出)，以及OpenAI的多个模型。

既然文本可以作为向量嵌入，为什么不能嵌入图像呢？这就产生了图像Embeddings。卷积神经网络(cnn)和视觉几何组(VGG)用于生成图像Embeddings。图像Embeddings使图像检索和分类成为可能。

既然图像可以作为矢量嵌入，为什么不能嵌入音频呢？你说得对！音频Embeddings可以捕获音频数据的声学特征，并可以进行音频分类和检索。视频Embeddings如何？它们捕获图像特征流用于视频分类。那么地理空间Embeddings呢？当然可以。纬度和经度坐标等地理空间数据可以嵌入到高维向量中，便于信息检索。

Embeddings使一切变得简单。如果你有一篇文章，需要找到类似的文章，你只需要计算你的文章的向量到其他文章的向量之间的距离。最近的向量就是你的搜索结果。我们可以用k近邻法（KNN），对吧？然而，速度是个问题。KNN的搜索将使光年皱眉。对于巴斯光年来说，完成一次简单的搜索需要…需要不知道多少年。研究的挑战不是最近的邻居在哪里，而是“如何”找到它们。

k-最近邻(KNNs)无法跟上速度

假设你有一本新书，你想在图书馆找到类似的书。k-最近邻（KNN）将浏览书架上的每一本书，并将它们从最相似到最不相似的顺序排列，以确定最相似的书。你有耐心做这么麻烦的工作吗？相反，人工神经网络对图书馆中的图书进行预排序和索引。要找到与你的新书相似的书，你所需要做的就是去正确的楼层，正确的区域，正确的通道找到相似的书。此外，你通常不需要对前10本相似的书进行精确排名，比如100%、99%或95%的匹配度。这就是近似近邻（ANN）的思想。

让我们来了解一下为什么人工神经网络可以更有效地搜索。

近似最近邻(ANN)感觉像光速

ANN （Approximate Nearest Neighbors）对大数据进行预索引，方便快速搜索。在索引期间，构建数据结构以促进更快的查询。当您想为一个查询点找到近似的最近邻居时，您可以将该查询点提供给ANN算法。人工神经网络算法首先从数据集中识别一组可能接近查询点的候选数据点。使用预构建的数据结构选择候选对象。这一步骤大大减少了需要检查接近性的数据点的数量。在候选点被选中之前，ANN计算每个候选点与查询点之间的实际距离(如欧几里得距离、余弦相似度)。然后根据与查询点的距离/相似度对候选项进行排名。排名靠前的候选人作为近似近邻返回。在某些情况下，还可以设置距离阈值，只返回该阈值内的候选对象。人工神经网络背后的关键思想是，为了显著降低计算成本，它牺牲了找到绝对最近邻的保证。这些算法的目标是在计算效率和准确性之间取得平衡。

然而，在高维空间中，过去的实验表明ANN并不比KNN节省多少时间(见[4])。有几种创新的人工神经网络算法适用于高维空间。我将列出这些算法的字母表。您很快就会熟悉这些字母，并且可能更愿意在NLP社区中使用它们进行交流。让我们学习流行的最先进的算法。

最先进的快速搜索算法

这些不同的人工神经网络算法是不同的方法来形成数据结构，以实现有效的检索。有三种类型的算法：基于图的、基于哈希的和基于树的。

基于图的算法创建数据的图表示，其中每个数据点是一个节点，边表示数据点之间的接近性或相似性。最引人注目的是层次导航小世界图(HNSW)。

基于哈希的算法使用哈希函数将数据点映射到哈希码或桶。流行的算法包括:位置敏感哈希（LSH）、多索引哈希（MIH）和产品量化

基于树的算法将数据集划分为树状结构，以便快速搜索。流行的是kd树、球树和随机投影树（RP树）。对于低维空间（≤10），基于树的算法是非常有效的。

有几个流行的代码库:

1. Scikit-learn：它的NearestNeighbors类提供了一个简单的接口，可以使用LSH等技术进行精确和近似的最近邻搜索。
2. Hnswlib：它是HNSW的Python包装器。
3. FAISS：该库支持多种ANN算法，包括HNSW, IVFADC(带ADC量化的倒置文件)和IVFPQ(带产品量化的倒置文件)。
4. Annoy (Approximate Nearest Neighbors Oh Yeah)：Annoy是一个c++库，也提供了Python接口。
5. NMSLIB(非度量空间库)：它是用c++编写的，并具有Python包装器。它可以执行HNSW、LSH、MIH或随机投影树等算法。

使用上述代码库，您可以超级快速地执行搜索查询。您还需要了解其他库的变体。这里我只提到其中的三个。第一个是PyNNDescent。PyNNDescent是一个Python库，用于基于NN-descent的搜索算法，它是LSH的一个变体。第二个是NearPy。它支持多个距离度量和哈希族。第三个是PyKDTree。PyKDTree是一个Python库，用于基于kd树的最近邻（KNN）搜索。虽然kd树更常用于精确搜索，但PyKDTree也可以通过一些启发式优化用于近似搜索。

此外，如果您询问哪些算法和库执行速度最好，您只需要了解**ANN- benchmark **库，专门为对人工神经网络搜索算法进行基准测试而设计。它提供了一个标准化的框架来评估算法，如Annoy， FLANN， scikit-learn (LSHForest, KDTree, BallTree)， PANNS， NearPy， KGraph， NMSLIB(非度量空间库)，hnswlib， RPForest， FAISS， nndescent， PyNNDescent等等。

这不仅仅是最近邻在哪里，而是如何有效地找到他们。让我们学习第一个算法——HNSW。HNSW通常可以在几毫秒内从数百万个数据点中找到最近邻。

了解分层导航小世界图(HNSW)

HNSW是一种用于在高维空间中进行高效人工神经网络搜索的数据结构和算法。它是跳表和小世界图（SWG）结构的扩展，可以有效地找到近似的最近邻。如果我们先学习跳表和小世界图，学习HNSW就会很简单。

跳表是一种数据结构，用于维护一组已排序的元素，并允许进行高效的搜索、插入和删除操作。它是由William Pugh在1989年发明的。图(2)显示了数字[3、6、7、9、12、17、19、21、25、26]的排序链表。假设我们想找到目标19。当值小于目标时，我们向右移动。需要6步才能找到它。

图 (2): 排序链表

现在，如果列表的每个其他节点都有一个指向前面节点2的指针，如图3所示，可以将这些指针视为“高速公路”。数学规则是“当数值小于目标时向右移动”。需要4个步骤才能达到19。

图 (3): 跳表，其指针指向后面两个节点

这些高速公路加快了搜索速度。我们可以增加更多。现在，如果列表中每三个其他节点都有一个指向前面第三个节点的指针，如图(4)所示，那么只需要3步就可以到达19。

你可能会问，如何选择这些点作为”高速公路“？它们可以是预先确定的或随机选择的。这些节点的随机选择是Small World和NHSW中数据构建的重要步骤，我将在后面介绍。

图 (4): 跳表再升级，指向后面三个节点的指针

由跳表的思路延伸到Small World，我们来看看是怎么做的。

由跳表的思路延伸到Small World

小世界（small world）网络是一种特殊的网络，在这种网络中，你可以快速地联系到网络中的其他人或点。这有点像“凯文·培根的六度”(Six Degrees of Kevin Bacon)游戏，在这个游戏中，你可以通过一系列其他演员，在不到六个步骤的时间里，将任何演员与凯文·培根联系起来。

想象一下，你有一群朋友排成一个圆圈，如图5所示。每个朋友都与坐在他们旁边的人直接相连。我们称它为“原始圆”。

现在，这就是奇迹发生的地方。你可以随机选择将其中一些连接改变给圆圈中的其他人，就像图5中的红色连接线一样。这就像这些连接的“抢椅子”游戏。有人跳到另一把椅子上的几率用概率p表示。如果p很小，移动的人就不多，网络看起来就很像原来的圆圈。但如果p很大，很多人就会跳来跳去，网络就会变得有点混乱。当您选择正确的p值(不太小也不太大)时，红色连接是最优的。网络变成了一个小世界网络。你可以很快地从一个朋友转到另一个朋友(这就是“小世界”的特点)。

图 (5): small-world网络

现在让我们学习从小世界网络到可导航小世界的过渡。

从小世界到HNSW

现在我们要扩展到高维空间。图中的每个节点都是一个高维向量。在高维空间中，搜索速度会变慢。这是不可避免的“维度的诅咒”。HNSW是一种高级数据结构，用于优化高维空间中的相似性搜索。

让我们看看HNSW如何构建图的层次结构。HNSW从图(6)中的第0层这样的基础图开始。它通常使用随机初始化数据点来构建。

图 (6): HNSW

HNSW在层次结构中的基础层之上构造附加层。每个层将有更少的顶点和边的数量。可以把高层中的顶点看作是跳跃列表中访问“高速公路”的点。你也可以将这些顶点视为游戏“Six Degrees of Kevin Bacon”中的演员Kevin Bacon，其他顶点可以在不到6步的时间内连接到他。

一旦构建了上面的层次结构，数据点就被编入索引，并准备进行查询搜索。假设查询点是桃色数据点。为了找到一个近似最近的邻居，HNSW从入门级(第2层)开始，并通过层次结构向下遍历以找到最近的顶点。在遍历的每一步，算法检查从查询点到当前节点邻居的距离，然后选择距离最小的相邻节点作为下一个基本节点。查询点到最近邻居之间的距离是常用的度量，如欧几里得距离或余弦相似度。当满足某个停止条件(例如距离计算次数)时，搜索终止。

现在让我们看看HNSW是如何构建这些层的。

HNSW如何构建数据结构?

HNSW首先初始化一个空图作为数据结构的基础。该图表示一个接一个插入数据点的空间。HNSW将数据点组织成多层。每一层表示数据结构中不同级别的粒度。层数是预定义的，通常取决于数据的特征。

每个数据点随机分配到一个层。最高的一层用于最粗略的表示，随着层的向下移动，表示变得更精细。这个任务是用一个特定的概率分布来完成的，这个概率分布叫做指数衰减概率分布。这种分布使得数据点到达更高层的可能性大大降低。如果你还记得跳跃列表中随机选择的数据点作为“高速公路”，这里的一些数据点是随机选择到最高层的。在后面的代码示例中，我们将看到每层中的数据点数量，并且数据点的数量在更高层中呈指数级减少。

为了在每一层内有效地构建连接，HNSW使用贪婪搜索算法。它从顶层开始，试图将每个数据点连接到同一层内最近的邻居。一旦建立了一层中的连接，HNSW将使用连接点作为搜索的起点继续向下扩展到下一层。构建过程一直持续到处理完所有层，并且完全构建了数据结构。

让我们简单总结一下HNSW中数据结构的构造。让我也参考Malkov和Yashunin[3]中的符号，并在附录中解释HNSW算法。您可能会发现它们有助于更明确地理解HNSW的算法。HNSW声明一个空结构并逐个插入数据元素。它保持每个数据点每层最多有M个连接的属性，并且每个数据点的连接总数不超过最大值(Mmax)。在每一层中，HNSW找到与新数据点最近的K个邻居。然后，它根据距离更新候选数据点集和找到的最近邻居列表(W)。如果W中的数据点数量超过了动态候选列表(ef)的大小，则该函数从W中删除最远的数据点。

接下来，我将向您展示代码示例。该笔记本可通过此链接获得。

代码示例

接下来，让我们使用库FAISS执行HNSW搜索。我将使用NLP中包含新闻文章的流行数据集。然后，我使用“SentenceTransformer”执行Embeddings。然后，我将向您展示如何使用HNSW通过查询搜索类似的文章。

Data

总检察长的新闻文章语料库由[A.]Gulli](http://groups.di.unipi.it/~gulli/AG_corpus_of_news_articles.html)，是一个从2000多个新闻来源收集100多万篇新闻文章的大型网站。Zhang、Zhao和LeCun在论文中构建了一个较小的集合，其中采样了“世界”、“体育”、“商业”和“科学”等新闻文章，并将其用作文本分类基准。这个数据集“ag_news”已经成为一个经常使用的数据集，可以在Kaggle、PyTorch、Huggingface和Tensorflow中使用。让我们下载[数据从Kaggle](https://www.kaggle.com/datasets/amananandrai/ag-news-classification-dataset)。训练样本和测试样本分别有12万篇和7600篇新闻文章。

1
2
3
4
5
6
7
8
9

import pandas as pd
import numpy as np
import faiss
pd.set_option('display.max_colwidth', -1)
path = "/content/gdrive/My Drive/data"
train = pd.read_csv(path + "/gensim/ag_news_train.csv")
print(train.shape)
print(train.columns)
train['Description'][0:5]

输出形状为(120000,3)，列为[‘ Class Index ‘， ‘ Title ‘， ‘ Description ‘]。我们对“描述”栏感兴趣。以下是排名前五的记录。

• 路透社——卖空者，华尔街日益减少的\band极端愤世嫉俗者，又看到了绿色
• 路透——私人投资公司凯雷投资集团(\which)以在国防工业投资时机恰当、偶尔引发争议而闻名，该公司已悄然将赌注押在了市场的另一个领域
• 路透社——油价飙升，加上对\about经济和盈利前景的担忧，预计将在下周\summer经济低迷的深度\hang拖累股市
• 路透社——一位石油官员周六表示，在\intelligence显示反叛民兵可能袭击\infrastructure后，当局已经停止了伊拉克南部主要管道\flows的石油出口
• 法新社——在距离美国总统大选仅剩三个月的时间里，世界油价不断刷新纪录，人们的钱包越来越紧，这给经济带来了新的威胁

数据嵌入

出于说明的目的，我只使用10,000条记录进行Embeddings。

1

sentences = train['Description'][0:10000]

您需要pip安装“sentence_transformers”库。

1
2

!pip install sentence_transformers
from sentence_transformers import SentenceTransformer

然后让我们使用预训练模型“bert-base-nli-mean-tokens”来声明模型。在本页上有许多预先训练好的模型。

1

model = SentenceTransformer('bert-base-nli-mean-tokens')

然后我们将“句子”编码为“sentence_embeddings”。

1
2
3

sentence_embeddings = model.encode(sentences)
print(sentence_embeddings.shape)
sentence_embeddings[0:5]

输出是10,000个列表。每个列表或向量的维数为768。下面是前5个Embeddings的输出。

array([[-0.26105028, 0.8585296 , 0.03941074, …, 1.0689917 , 1.1770816 , -0.74388623], [-0.2222097 , -0.03594436, 0.5209106 , …, 0.15727971, -0.3867779 , 0.49948674], [-0.3001758 , -0.41582862, 0.86036515, …, -0.6246218 , 0.52692914, -0.36817163], [ 0.3295024 , 0.22334357, 0.30229023, …, -0.41823167, 0.01728885, -0.05920589], [-0.22277102, 0.7840586 , 0.2004052 , …, -0.9121561 , 0.2918987 , -0.12284964]], dtype=float32)

这有助于保存Embeddings以备将来使用。

1
2

with open(path + '/AG_news.npy', 'wb') as file:
    np.save(file, sentence_embeddings)

在上面的代码中，我使用了“npy”文件扩展名，这是NumPy数组文件的常规扩展名。下面是加载数据的代码:

1
2

with open (path + '/AG_news.npy', 'rb') as f:
    sentence_embeddings = np.load(f, allow_pickle=True)

有了这些Embeddings，我们就可以在HNSW数据结构中组织它们了。

使用FAISS构建NHSW数据结构索引

您需要像下面这样pip安装FAISS库:

1

!pip install faiss-cpu --no-cache

我将使用HNSWFlat(dim, m)类来构建HNSW。它需要预先确定的参数dim表示向量的维数，m表示数据元素与其他元素连接的边数。

1
2
3
4

import faiss
m = 32
dim = 768
index = faiss.IndexHNSWFlat(dim, m)

如前所述，HNSW指数的创建分为两个不同的阶段。在初始阶段，该算法采用概率分布来预测引入新数据节点的最上层。在接下来的阶段，收集每个数据点的最近邻居，然后用一个表示为m的值进行修剪(在我们的例子中是m=16)。整个过程是迭代的，从插入层开始，一直到底层。

HNSW中有两个重要参数“efConstruction”和“efSearch”。这两个参数控制着索引结构构建的效率和有效性。它们帮助您在HNSW索引结构中的索引构建和最近邻搜索操作的速度和质量之间取得平衡。

1. efConstruction:该参数用于HNSW索引的构建。它控制了构建索引结构的速度和结构质量之间的权衡。” efConstruction “值决定了在构建阶段要考虑多少候选项目。较高的“efConstruction”值将产生更准确的索引结构，但也会使构建过程变慢。
2. efSearch:该参数用于在HNSW索引中查找查询点的最近邻居。“efSearch”值控制搜索速度和搜索质量之间的权衡。较高的“efSearch”值将导致更准确和详尽的搜索，但也会更慢。我们将“efConstruction”和“efSearch”分别设置为40和16:

1
2

index.hnsw.efConstruction = 40 
index.hnsw.efSearch = 16  

我们已经声明了上面的数据结构。现在我们准备将数据“sentence_embeddings”一个接一个地插入到数据结构中:

1

index.add(sentence_embeddings)

一旦完成，我们可以检查HNSW数据结构中有多少数据元素:

1

index.ntotal

输出为10000。它是“sentence_embeddings”中的数据点数。接下来，HNSW建造了多少层?让我们来检查最大级别:

1
2

# the HNSW index starts with no levels
index.hnsw.max_level

最高级别为2.0。这意味着有第0层，第1层和第2层。接下来，您可能想知道每层中数据元素的数量。让我们来看看:

1
2

levels = faiss.vector_to_array(index.hnsw.levels)
np.bincount(levels)

输出为array([0,9713,280,7])。“0”没有意义，你可以忽略它。它说第0层有9713个数据元素，第1层有280个元素，第2层只有7个元素。注意，9713 + 280 + 7 = 10000。您是否发现，较高层的数据元素数量比前几层呈指数级减少?这是因为数据元素的层分配采用指数衰减概率分布。

FAISS为HNSW搜索示例

假设我们的搜索查询是“经济繁荣与股市（economic booming and stock market）”。我们希望找到与我们的搜索查询相关的文章。我们将首先嵌入搜索查询:

1

qry1 = model.encode(["economic booming and stock market"])

使用代码index.search()，搜索过程非常简单。这里k是最近邻居的个数。我们将其设置为5以返回5个邻居。index.search()函数返回两个值” d “和” I “。

• “d”:查询向量与k个最近邻居之间的距离列表。默认的距离度量是欧几里得距离。
• “I”:它是索引中k个最近邻居的位置对应的索引列表。这些索引可用于查找数据集中的实际数据点。

1
2
3
4
5

%%time
k=5
d, I = index.search(qry1, k)
print(I)
print(d)

索引列表的输出是[[1467 4838 4464 7461 8299]]。我们将使用这些索引打印出搜索结果。

注意，我使用“%%time”来度量执行时间。它输出

*CPU时间:user: 5.57 ms, sys: 5µs, total: 5.58 ms

这意味着搜索只需要几毫秒。这确实是令人难以置信的快!

距离输出列表为:[[158.19066 163.69077 164.47517 164.64172 164.64172]]

1
2

for i in I[0]:
  print(train['Description'][i])

输出：

‘Rising oil prices are expected to hit China’s growth rate this year.’

‘Developing countries are starting to flex their financial muscles and invest overseas.

‘The Tehran Stock Exchange has performed magnificently, but the market’s list of risks is outsized.’

‘Federal Express raised its earnings forecast, citing strong demand for its international express, ground and less-than-truckload services.’

‘Federal Express raised its earnings forecast, citing strong demand for its international express, ground and less-than-truckload services.’ (Our data have duplications)

这些文章都是关于经济和股票市场的新闻。搜索速度以毫秒计非常快。这不仅仅是结果在哪里的问题，而是如何快速得到结果的问题，不是吗?

您可以通过此链接下载笔记本进行上述搜索。

总结

我希望这篇文章能帮助你理解近似近邻(ANN)，以及它是如何提供高效搜索的。这篇文章解释了不同的人工神经网络算法，包括基于图的HNSW，基于哈希的LSH或产品量化，以及基于树的KD-Trees。这篇文章解释了HNSW如何构建其数据结构并逐个插入数据元素。本文演示了如何使用FAISS库构建用于查询搜索的HNSW。在下一篇文章“搜索像光速- (2)LSH，”中，我将讨论基于哈希的算法。

附录

在Malkov和Yashunin[3]的论文中，算法1到5伪代码中提供了HNSW方法。伪代码给出了算法的具体定义。我将这些描述添加到伪代码中，因为一些读者可能会发现它们有助于理解HNSW。算法1、算法2和算法3或算法4中的一个用于完成数据结构。一旦数据结构完成，以后的任何查询搜索都只使用算法5。

• 算法1:“INSERT”函数构建数据结构
• 算法2:“SEARCH-LAYER”函数计算KNN并存储邻居
• 算法3:“SEARCH-NEIGHBORS-SIMPLE”是一种选择邻居的简单方法
• 算法4:“SELECT-NEIGHBORS-HEURISTIC”函数是一种更复杂的选择邻居的方法
• 算法5:“KNN-SEARCH”函数进行查询搜索

让我们从算法1开始。

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

Algorithm 1: INSERT()

INSERT(hnsw, q, M, Mmax, efConstruction, mL)
Input: multilayer graph hnsw, new element q, number of established
connections M, maximum number of connections for each element
per layer Mmax, size of the dynamic candidate list efConstruction, nor-
malization factor for level generation mL
Output: update hnsw inserting element q
1 W ← ∅ // list for the currently found nearest elements
2 ep ← get enter point for hnsw
3 L ← level of ep // top layer for hnsw
4 l ← ⌊-ln(unif(0..1))∙mL⌋ // new element’s level
5 for lc ← L … l+1
6 W ← SEARCH-LAYER(q, ep, ef=1, lc)
7 ep ← get the nearest element from W to q
8 for lc ← min(L, l) … 0
9 W ← SEARCH-LAYER(q, ep, efConstruction, lc)
10 neighbors ← SELECT-NEIGHBORS(q, W, M, lc) // alg. 3 or alg. 4
11 add bidirectionall connectionts from neighbors to q at layer lc
12 for each e ∈ neighbors // shrink connections if needed
13 eConn ← neighbourhood(e) at layer lc
14 if │eConn│ > Mmax // shrink connections of e
// if lc = 0 then Mmax = Mmax0
15 eNewConn ← SELECT-NEIGHBORS(e, eConn, Mmax, lc)
// alg. 3 or alg. 4
16 set neighbourhood(e) at layer lc to eNewConn
17 ep ← W
18 if l > L
19 set enter point for hnsw to q

它在多层图中插入一个新元素q，保持每个元素每层最多有M个连接，并且每个元素的连接总数不超过Mmax的属性。该算法还保证连接元素之间的距离不大于某一最大距离，并且每层的连接数是均衡的。步骤如下:

1. W←∅:初始化一个空列表W来存储当前找到的最近的元素。
2. ep←get enter point for hnsw:获取多层图hnsw的进入点(即起始点)。
3. L←ep的电平:获取进入点ep的电平。
4. l←ln(unitif(0..1))∙mL⌋:为新元素q生成一个介于0和mL之间的随机级别，其中mL是级别生成的归一化因子。
5. for lc←L…L +1:循环从L到L +1的层。
6. W←SEARCH LAYER(q, ep, ef=1, lc):使用进入点ep和最大距离ef=1在lc层中搜索离q最近的元素。将找到的元素存储在列表W中。
7. ep←取W到q最近的元素:取W到q最近的元素。
8. for lc←min(L, L)…0:循环遍历从min(L, L)到0的层。
9. W←SEARCH LAYER(q, ep, efConstruction, lc):使用进入点ep和最大距离efConstruction搜索层lc中离q最近的元素。将找到的元素存储在列表W中。
10. neighbors←SELECT neighbors (q, W, M, lc):选择W到q最近的M个邻居，只考虑lc层的元素。
11. 在lc层添加邻居到q的双向连接:在lc层添加q与所选邻居之间的双向连接。
12. 对于每个e∈neighbors: //如果需要收缩连接
    对于q的每个邻居e，检查e的连接数是否超过Mmax。如果是这样，使用SELECT neighbors (e, eConn, Mmax, lc)选择一组新的邻居来收缩e的连接，其中eConn是e在lc层的当前连接集。
13. eNewConn←SELECT NEIGHBORS(e, eConn, Mmax, lc):为e选择一组新的邻居，只考虑lc层的元素，保证连接数不超过Mmax。
14. set neighborhood (e) at layer lc to eNewConn:将层lc的e的连接集更新为新的set eNewConn。
15. ep <- W:设置hnsw的进入点为q。
16. if 1 > L:将hnsw的起始点设为q，因为新元素q现在是图的一部分。
17. return hnsw:返回更新后的多层图hnsw。

让我们看看算法2。

它在HNSW数据结构上执行K近邻搜索，以查找特定层lc中与查询元素q最近的K个元素。然后，它根据查询元素q与候选元素C和e之间的距离更新候选元素C的集合和找到的最近邻居列表W。最后，如果W中的元素数量超过了动态候选列表ef的大小，则该函数删除从W到q最远的元素。

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

Algorithm 2: SEARCH-LAYER()

SEARCH-LAYER(q, ep, ef, lc)
Input: query element q, enter points ep, number of nearest to q ele-
ments to return ef, layer number lc
Output: ef closest neighbors to q
1 v ← ep // set of visited elements
2 C ← ep // set of candidates
3 W ← ep // dynamic list of found nearest neighbors
4 while │C│ > 0
5 c ← extract nearest element from C to q
6 f ← get furthest element from W to q
7 if distance(c, q) > distance(f, q)
8 break // all elements in W are evaluated
9 for each e ∈ neighbourhood(c) at layer lc // update C and W
10 if e ∉ v
11 v ← v ⋃ e
12 f ← get furthest element from W to q
13 if distance(e, q) < distance(f, q) or │W│ < ef
14 C ← C ⋃ e
15 W ← W ⋃ e
16 if │W│ > ef
17 remove furthest element from W to q
18 return W

以下是上述代码的步骤:

1. 初始化变量v为当前的入口点ep。
2. 初始化集合C为当前候选集合。
3. 初始化一个空列表W来存储找到的最近邻。
4. 循环直到候选集合C中的所有元素都求值为止。
5. 从候选元素集合c中提取离查询元素q最近的元素c。
6. 获取从找到的最近邻W到查询元素q的列表中最远的元素f。
7. 如果c到q的距离大于f到q的距离:
8. 然后打破这个循环。
9. 对于lc层c邻域内的每个元素e:
10. 如果e不在访问元素v的集合中，则:
11. 将e添加到访问元素v的集合中。
12. 设f为从W到q的最远的元素。
13. 如果e和q之间的距离小于等于f和q之间的距离，或者W中的元素个数大于等于ef(动态候选列表的大小)，则:
14. 将候选集C更新为C∈e。
15. 将发现的最近邻居W的列表更新为W∈e。
16. 如果W中的元素个数大于等于ef，则:
17. 移除从W到q的最远的元素。
18. 返回找到的最近邻居W的列表。

算法3.

这是一个简单的最近邻选择算法，它接受一个基本元素q、一组候选元素C和一些邻居M作为输入。它返回候选元素C集合中离q最近的M个元素。

1
2
3
4
5
6
7

Algorithm 3: SELECT-NEIGHBORS-SIMPLE()

SELECT-NEIGHBORS-SIMPLE(q, C, M)
Input: base element q, candidate elements C, number of neighbors to
return M
Output: M nearest elements to q
return M nearest elements from C to q

步骤如下:

1. 初始化一个空集R来存储选中的邻居。
2. 初始化一个工作队列W来存储候选元素。
3. 如果设置了extendCandidates标志(即true)，则通过将C中每个元素的邻居添加到队列W来扩展候选列表。
4. 而W的大小大于0,R的大小小于M:
5. 从W到q中提取最近的元素e。
6. 如果e比R中的任何元素更接近q，把e加到R中。
7. 否则，将e添加到丢弃队列Wd中。
8. 如果设置了keepPrunedConnections标志(即true)，则从Wd添加一些丢弃的连接到R。
9. 返回R。

让我们看看算法4。

这是一个更复杂的最近邻选择算法，它接受一个基本元素q、一组候选元素C、若干个邻居M、一个层数lc和两个标志extendCandidates和keepPrunedConnections作为输入。它返回由启发式选择的M个元素。

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

Algorithm 4: SELECT-NEIGHBORS-HEURISTIC()

SELECT-NEIGHBORS-HEURISTIC(q, C, M, lc, extendCandidates, keep-
PrunedConnections)
Input: base element q, candidate elements C, number of neighbors to
return M, layer number lc, flag indicating whether or not to extend
candidate list extendCandidates, flag indicating whether or not to add
discarded elements keepPrunedConnections
Output: M elements selected by the heuristic
1 R ← ∅
2 W ← C // working queue for the candidates
3 if extendCandidates // extend candidates by their neighbors
4 for each e ∈ C
5 for each eadj ∈ neighbourhood(e) at layer lc
6 if eadj ∉ W
7 W ← W ⋃ eadj
8 Wd ← ∅ // queue for the discarded candidates
9 while │W│ > 0 and │R│< M
10 e ← extract nearest element from W to q
11 if e is closer to q compared to any element from R
12 R ← R ⋃ e
13 else
14 Wd ← Wd ⋃ e
15 if keepPrunedConnections // add some of the discarded
// connections from Wd
16 while │Wd│> 0 and │R│< M
17 R ← R ⋃ extract nearest element from Wd to q
18 return R

步骤如下:

1. 初始化三个队列:R用于选择的邻居，W用于工作的候选，Wd用于丢弃的候选。
2. 设置R的大小为0,W的大小为C的大小。
3. 如果extendCandidates被设置(即，true):
4. 对于C中的每个元素e:
5. 对于第lc层e的每一个邻居eadj:
6. 如果eadj不在W中，则在W中添加它。
7. 而W的大小大于0,R的大小小于M:
8. 从W到q中提取最近的元素e。
9. 如果e比R中的任何元素更接近q，把e加到R中。
10. 否则，将e加到Wd。
11. 如果设置了keepPrunedConnections(即true):
12. 而Wd的大小大于0,R的大小小于M:
13. 从Wd到q中提取最近的元素e。
14. 如果e比R中的任何元素更接近q，就把e加到R中。
15. 返回R。

最后，让我们看看算法5。

这个搜索算法与算法1基本相同。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Algorithm 5: K-NN-SEARCH()

K-NN-SEARCH(hnsw, q, K, ef)
Input: multilayer graph hnsw, query element q, number of nearest
neighbors to return K, size of the dynamic candidate list ef
Output: K nearest elements to q
1 W ← ∅ // set for the current nearest elements
2 ep ← get enter point for hnsw
3 L ← level of ep // top layer for hnsw
4 for lc ← L … 1
5 W ← SEARCH-LAYER(q, ep, ef=1, lc)
6 ep ← get nearest element from W to q
7 W ← SEARCH-LAYER(q, ep, ef, lc =0)
8 return K nearest elements from W to q

步骤如下:

1. 初始化一个空集合W(当前最近元素的集合)，并将进入点ep设置为网络的顶层。
2. 设置进入点ep的水平为顶层L。
3. 对于每一层lc，从L到1(即从顶层到底层):
4. 使用查询元素q和当前最近的元素W搜索当前层，并将最近的元素添加到W中。
5. 将进入点ep设置为W到q最近的元素。
6. 使用查询元素q和当前最近的元素W搜索下一层，并将最近的元素添加到W中。
7. 返回W中最接近的K个元素作为输出。

引用

• [1] Pugh, W. (1990). Skip lists: A probabilistic alternative to balanced trees. Communications of the ACM, 33(6), 668–676. doi:10.1145/78973.78977. S2CID 207691558.
• [2] Xiang Zhang, Junbo Zhao, & Yann LeCun. (2015). Character-level Convolutional Networks for Text Classification
• [3] Yu. A. Malkov, & D. A. Yashunin. (2018). Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs.
• [4] Aristides Gionis, Piotr Indyk, Rajeev Motwani, et al. 1999. Similarity search in high dimensions via hashing. In Vldb, Vol. 99. 518–529.

Update: 2024-01-26

我们的TorchV Bot产品目前已经开始试用了，详情可以点击：https://www.luxiangdong.com/2024/01/25/lanuch-1
目前只接受企业用户试用，需要您填写一些信息，必要信息如下：

邮箱： 用来接收地址和账号
如何称呼您：
所服务的公司：
您的职位：

当然，如果您可以告诉我们您的使用场景，我们将更加感激！
对了，可以发送到yuanwai@mengjia.net
另外，也可以直接加我微信（lxdhdgss）联系我。

ChatGLM3-6B来了

上周又新出来一个新的国产大语言模型——ChatGLM3-6B，据说这次他们还另外上线了3B和1.5B两个模型，但是没有选择开源。这类小体量的模型如果能力OK的话，应用前景是非常广的，可以作为桌面应用，甚至在手机上就可以部署。

好，不说这么多，今天我们先来看看ChatGLM3-6B的能力相比之前的ChatGLM2-6B是否有较大提升。

周末的时候我下载了ChatGLM3-6B的模型文件，这次的文件大小和ChatGLM2-6B几乎是差不多的。甚至我开始都觉得可能是同一份model文件，但是使用ll命令看详细字节数，每个文件的大小是不同的，所以我还是重新下载了一份。

说实话，对于ChatGLM2-6B我还是比较失望的，从年初的惊艳，到后面的泯然众人，ChatGLM2-6B在我们RAG应用中已经完全不适用了，连基本的归纳都做不好，我们本来是把离线大模型的希望都寄托给它的。后续在一些应用中，我们使用在线大模型是智谱（ChatGLM所属公司）的Lite版和Pro版，这两个能力上还行。

但是离线需求肯定是一个刚需，特别是对于企业客户，他们不希望自己的机密数据文件被上传到在线大模型，所以后面Baichuan2-13B出来之后，离线的大模型，我们就开始转向了百川。但是百川的13B也有个问题，就是对GPU要求很高，非负载状态下需要18GB的显存，也就是需要至少4090的显卡（24GB），而目前市面上数量较多的3090显卡（16GB）则无法胜任。所以对于此次ChatGLM3-6B的公布，我很激动，希望可以为后面的RAG应用做一个相对性价比较高的配置方案。

测试方法

首先我必须说，我不去做科学的对比测试，如果你需要看官方评测，我也可以贴一个ChatGLM官方给出的2和3的比较：

我想要更加”老土“一些、更加直接一些的方式，我的评测方法是这样的：

• 参加对比的模型：ChatGLM2-6B、ChatGLM3-6B、Baichuan2-13B和ChatGPT-3.5。是的，Baichuan2-13B和ChatGPT3.5在参数体量上和6B完全不同，有点耍流氓，但是不妨作为一组对比，从更广度的对比上来看各个模型的能力；
• 只测试7个问题：这次我只给出7个问题，分别包括实体提取、逻辑计算、英文翻译、归纳、计数、SQL生成和生成代码展示分析图表（问题集在分项评测中会贴出）。四个模型提交的问题都是一样的，这里需要说明一下就是ChatGLM2和3模型的Cli模式对于输入文字的显示不太友好，所以后面的截图中会出现一些显示问题，但是从答案中可以看到，实际并没有真正丢失这些信息；
• 只截取首次答案：我们都知道大模型对于同一个答案的每次结果输出会出现不太一样，比如连续问十次可能会有一次出现完全不同的结果，所以为了整个测试更加公平，我们只取第一次输出；
• 评比方法：为了让评比更简单明了，在输出中，只要基本正确，我就会判为争取。如果出现了重要的错误，影响了整体的正确性，那才会判错。我后面的各项评测截图都会贴出来，大家也可以自己分析，并得出自己的答案。

所以你看到了，这不是一次科学的评测。我最关心的还是大模型对于RAG应用中G（生成）的支撑效果。

我可以在说说我的环境：Intel i7 / 64GB / RTX 4090 / 2TB SSD，操作系统是Ubuntu Server 22.04，Python3.11，Conda环境。

分项评测

至于测试过程，我就不一一录屏了，直接上评测结果，分为7项测试，最后再加一个总结。

1.实体提取

实体和关系提取当然也可以使用NER，但是有大模型，为什么不用呢，而且它后面还可以做格式，所以在RAG应用中，我们喜欢用大模型来提取实体。而且，这种提取方式对于短句子特别有效——对的，就是对于用户的提问内容的实体提取。

Prompt:

请帮我分析一下这段话”我需要看2021年3月至7月（含）的浙江分公司的自研产品的销售数据报表“，如果包含时间，请帮我列出”时间:xxxx年xx月“这样的格式，如果包含机构，请帮我列出”机构：xxxx“，如果包含其他实体，请帮我列出”实体：xxxx/xxxx“

评测意义

这个prompt中，我们如果可以将时间、机构和其他实体先提取出来，就可以使用元数据过滤，在这么多月份的文件，这么多分公司（机构）的文件中，直接过滤掉大量不相干的文件chunk，极大提高向量相似度计算的速度。对于RAG应用来说，这是很关键的一种优化能力。

评测结果

• ChatGLM2-6B（0）：完全不知道在做什么；
• ChatGLM3-6B（0.5）：其实它也提取出了时间和机构，但是没有提取出其他的实体，给0.5分；
• Baichuan2-13B（1）：应该说提取的比较好，最后的输出没用使用/是个缺陷；
• ChatGPT-3.5（1）：提取的比较好，包括/也给到了，但是它没有7月（含），也许是对中文理解的偏差吧。

2.逻辑计算

这是一道我用了半年多的题目，很多大模型被我考倒了。

Prompt:

小明老婆昨天生了一对龙凤胎，他们还有一个4岁的女儿，那么现在小明一共有几个孩子？分别是几个儿子，几个女儿？

评测意义

这里需要大模型对中文有一定理解能力，知道龙凤胎是一男一女，然后要去计算4岁的女儿，要做加法。如果大模型的逻辑计算能力出色，那我们可以将很多有文字有数字的内容塞给它，直接计算。比如一篇用记事本记录的今日花销流水账，直接就可以计算出来。是大模型是否”聪明“的一大体现。

评测结果

惊喜的事情来了！

这道题，居然只有被认为最弱的ChatGLM2-6B答对了！！！我之前是试过多次ChatGPT-3.5的，好像基本都是正确的，但是这次居然打错了，看来最近OpenAI算力吃紧，有意降低ChatGPT的能力是有一些依据的。

• ChatGLM2-6B（1）：完全正确，惊喜；
• ChatGLM3-6B（0）：错误；
• Baichuan2-13B（0）：错误；
• ChatGPT-3.5（0）：居然连ChatGPT-3.5都错了。

3.翻译

翻译算是一项常规技能了，特别是英文翻译成中文。

Prompt:

你是精通计算机科学的专家，并且是一位专业翻译人员，请帮我翻译以下英文内容：“With Large Language Models(LLM) such as Chat GPT, machines can interact with humans in ways that weren’t possible before. There’s a growing interest in fine-tuning these pre-trained LLM models to preserve data privacy and cater to domain-specific tasks, thanks to the democratization of open-source Large Language Models. We can find numerous posts discussing model fine-tuning and application of in-context learning (I’ve even written three articles myself.., each delving into a distinct technique). But it’s essential to grasp the fundamentals. When should you opt for fine-tuning, and when is in-context learning the better choice? How do you kickstart the process, and how do these methods fit into the bigger picture? What techniques are readily available for you to implement? In this post, we’re diving into the fine-tuning process for pretrained models, explore different fine-tuning methods, and provide a comparison of the latest state-of-the-art techniques.”

评测意义

常规技能，意义就不评价了，对于中文支持的模型，这是必备项。

评测结果

• ChatGLM2-6B（0.5）：马马虎虎还是可以的，但还是有三个瑕疵。首先把fine-tuning翻译成了精调，这个也许有些不太符合习惯，一般还是用微调；第二个问题是表情符附近的myself；然后最后一句，”并比较最先进的最新状态“，语法上有些生硬；
• ChatGLM3-6B（0.8）：其他都很好，也是最后一句，”并比较最先进的最新状态“，语法上有些生硬，这可能是GLM训练语料存在的问题；
• Baichuan2-13B（1）：翻译的比较优质；
• ChatGPT-3.5（1）：吹毛求疵一下，”机器可以以以前不可能的方式“这一句有优化空间，但是意思没错。

4.归纳

归纳应该算是RAG应用中非常重要的一项能力了，我们通过向量计算召回内容，然后让大模型进行归纳和润色，然后再输出最终结果。所以归纳的能力也不需要过多介绍了。

Prompt:

请帮我将分析一下文字的含义，然后使用不超过30个字进行归纳：我们可以看到有很多关于如何构建RAG应用程序的示例代码和开源框架（如LlamaIndex和Langchain），目前它们产出一些技术和代码案例，使用的托底LLM基本上都是OpenAI的ChatGPT。我们碰的一些已经在做RAG应用的企业，也是无一例外的在使用OpenAI。就像上面说的，这本身是正确的逻辑，因为先用目前的上限做测试，至少我们”未来可期“——等国产大模型慢慢追上来。但不得不说，ChatGPT虽然还不完美，但已经很强大了。看了这些案例之后，我们也能发现完全基于ChatGPT好像有点背离我们构建RAG的初衷，也存在一些风险： 违背设计初衷：RAG的设计初衷是减轻LLM的各类问题，比如前面说到的减少幻觉、减少费用，增加实时性。但重度依赖ChatGPT反而把RAG做成了一个大模型的客户端，有点违背帮LLM分担压力的初衷； 国内使用风险：在国内使用ChatGPT属于是两头堵的状况，OpenAI对中国大陆用户是明确禁用的，国家对于非可控信源也是有严格的使用说明的。如果你只是自己搭建在家里或者公司内容研究用，那可能风险相对较小。但是如果要基于LLM和RAG技术对外提供经营服务，那基本上你还是需要退回到使用国内经过网信办审核的大模型。 而像我们这样使用国产大模型，或使用自己本地部署的开源大模型，确实在整体效果上和OpenAI是存在一些差距的，有时候事倍功半，想想还是挺气人的。我们需要为大模型本身的能力差距做很多”胶水组件“，其实就是很多中间件，比如表格处理，使用OpenAI的话我们可以直接使用开源的PandasAI（我之前也介绍过这个库），它会产生一些代码执行语句，给到ChatGPT，就能生产很好的结果。但是在国产大模型里面，没有这么强的程序执行能力，我们就需要做一些表格存储、处理和计算的额外功能，像这样的例子还有很多。 但是这样做的好处是我们对RAG整个体系中各个环节都越来越清楚，可以快速定位到问题，知道怎么做一个胶水组件去解决问题。假以时日，国产大模型追上了GPT-3.5的水平了，那精通RAG内部各个细节的你，做出来的应用应该也会比别人的更优秀。

评测意义

RAG应用中最重要的技能之一，要保证语义不发生偏转，不能南辕北辙。

评测结果

• ChatGLM2-6B（0）：出现严重错误，原文说的是使用ChatGPT有风险，结果归纳的时候变成了国产大模型；
• ChatGLM3-6B（1）：非常完美；
• Baichuan2-13B（0.6）：画蛇添足了，强行解释了一下RAG，结果解释错了，只能给一个0.6分；
• ChatGPT-3.5（1）：非常完美。

5.统计次数

这也是一个传统艺能了，这可以帮助我们分析文章中哪些内容是比较重要的，和传统的TF-IDF是反着来的。

Prompt:

请帮我找出在后面将要给出的内容中，一共提到了多少个ChatGPT。以下是需要查找的内容：我们可以看到有很多关于如何构建RAG应用程序的示例代码和开源框架（如LlamaIndex和Langchain），目前它们产出一些技术和代码案例，使用的托底LLM基本上都是OpenAI的ChatGPT。我们碰的一些已经在做RAG应用的企业，也是无一例外的在使用OpenAI。就像上面说的，这本身是正确的逻辑，因为先用目前的上限做测试，至少我们”未来可期“——等国产大模型慢慢追上来。但不得不说，ChatGPT虽然还不完美，但已经很强大了。看了这些案例之后，我们也能发现完全基于ChatGPT好像有点背离我们构建RAG的初衷，也存在一些风险： 违背设计初衷：RAG的设计初衷是减轻LLM的各类问题，比如前面说到的减少幻觉、减少费用，增加实时性。但重度依赖ChatGPT反而把RAG做成了一个大模型的客户端，有点违背帮LLM分担压力的初衷； 国内使用风险：在国内使用ChatGPT属于是两头堵的状况，OpenAI对中国大陆用户是明确禁用的，国家对于非可控信源也是有严格的使用说明的。如果你只是自己搭建在家里或者公司内容研究用，那可能风险相对较小。但是如果要基于LLM和RAG技术对外提供经营服务，那基本上你还是需要退回到使用国内经过网信办审核的大模型。 而像我们这样使用国产大模型，或使用自己本地部署的开源大模型，确实在整体效果上和OpenAI是存在一些差距的，有时候事倍功半，想想还是挺气人的。我们需要为大模型本身的能力差距做很多”胶水组件“，其实就是很多中间件，比如表格处理，使用OpenAI的话我们可以直接使用开源的PandasAI（我之前也介绍过这个库），它会产生一些代码执行语句，给到ChatGPT，就能生产很好的结果。但是在国产大模型里面，没有这么强的程序执行能力，我们就需要做一些表格存储、处理和计算的额外功能，像这样的例子还有很多。 但是这样做的好处是我们对RAG整个体系中各个环节都越来越清楚，可以快速定位到问题，知道怎么做一个胶水组件去解决问题。假以时日，国产大模型追上了GPT-3.5的水平了，那精通RAG内部各个细节的你，做出来的应用应该也会比别人的更优秀。

评测意义

在RAG应用中，我们有时候需要统计各chunk或page中和问题相关的词频，以进行重排（rerank），所以统计也是有实际意义的。

上面这段话（从”以下是需要查找的内容：“开始），其实是有 6处 提到ChatGPT的，我们来看看各个模型的评测结果。

评测结果

• ChatGLM2-6B（0）：2次，错误；
• ChatGLM3-6B（0）：5次，错误；
• Baichuan2-13B（1）：6次，正确；
• ChatGPT-3.5（0）：4次，错误。

这个评测中，居然只有Baichuan2-13B是正确的，可怕。

6.生成SQL

生成SQL可以让我们通过语义理解来完成对本地数据库的查询，获取我们需要的数据，而不是通过程序员手动写SQL，或者只能按已经固化的SQL来进行某些变量（比如时间、实体等）的选择。

Prompt：

已知有两个mysql表，一个是代表销售人员的表:Persons，另一个是代表订单的表:Orders。具体的表定义如下： 表Persons： CREATE TABLE Persons (PersonID int, LastName varchar(255), FirstName varchar(255), Address varchar(255), City varchar(255), PRIMARY KEY (PersonID) ); 表Orders： CREATE TABLE Orders (O_Id int NOT NULL, OrderNo int NOT NULL, P_Id int, PRIMARY KEY (O_Id), FOREIGN KEY (P_Id) REFERENCES Persons(PersonID) ) 请帮我生成一个SQL语句，查询销售人员”Zhang san“的所有订单数据。

评测意义

在RAG应用中，根据语义生成SQL的能力是非常强大的，我们真的可以摆脱程序员预设的SQL来做事情。

评测结果

• ChatGLM2-6B（0）：P_Id = 123456是什么鬼，而且OrderNo LIKE '%Zhang san%'也是不知所云了；
• ChatGLM3-6B（1）：非常正确；
• Baichuan2-13B（1）：非常正确；
• ChatGPT-3.5（0）：ChatGPT-3.5用的语法我感觉是最好的，但是，它最后犯了一个错误，居然直接是Persons.LastName = 'Zhang san'，还是败在了对中文的理解上啊。

7.生成代码展示分析图表

这项任务我最初觉得是有一些挑战的。

Prompt:

已知浙江分公司2021年3月至7月（含）的自研产品销售数据依次为118万元、671万元、446万元、902万元和1011万元，请帮我用python的pyplot制作一个可查看趋势的柱状图表,注意，月份等标签请使用中文，并且，计量单位使用”万元“。

评测意义

在大模型的企业应用中，除了检索之外，我们很多时候也需要快速的得到一些数据分析指标，特别是一些趋势，用图表会更加直观，所以您直接说话，让应用（业务系统+数据库+大模型）立即给你直观的图表就变得很重要。一般我们会首先将语义转化为python代码，然后用matplotlib.pyplot等组件进行显示。当然，如果更复杂、更美观的分析图表，可以使用其他组件。

评测结果

• ChatGLM2-6B（0）：代码直接报错，无法运行；
• ChatGLM3-6B（0.8）：基本满足，唯一的缺憾是缺少label，然后对中文的理解反而差了一些，特别是月份变成了May等；
• Baichuan2-13B（1）：正确，而且还多了一个图例，很棒，中文乱码是因为我本地没装好中文环境；
• ChatGPT-3.5（1）：正确，中文乱码是因为我本地没装好中文环境。

另外我贴一下各个模型给出的代码：

ChatGLM2-6B

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

import matplotlib.pyplot as plt

# 数据
sales_data = [1180000, 6710000, 4460000, 9020000, 10110000]

# 标签
labels = ['1月', '2月', '3月', '4月', '5月', '6月', '7月']

# 创建图表
plt.bar(labels, sales_data)

# 设置图表标题和坐标轴标签
plt.title('自研产品销售趋势')
plt.xlabel('月份')
plt.ylabel('销售额（万元）')

# 显示图表
plt.show()

ChatGLM3-6B

1
2
3
4
5
6
7
8
9
10
11
12

import pandas as pd
import matplotlib.pyplot as plt

data = {'Month': ['Mar', 'Apr', 'May', 'Jun', 'Jul'],
        'Sales': [118, 671, 446, 902, 1011]}
df = pd.DataFrame(data)

plt.bar(df['Month'], df['Sales'])
plt.xlabel('月份')
plt.ylabel('销售金额（万元）')
plt.title('浙江分公司2021年3月至7月自研产品销售数据')
plt.show()

Baichuan2-13B

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

import matplotlib.pyplot as plt
import numpy as np

# 数据
months = ['3月', '4月', '5月', '6月', '7月']
values = [118, 671, 446, 902, 1011]
units = ['万元'] * 5

# 设置柱状图的宽度和位置
bar_width = 0.25
x = np.arange(len(months))

# 绘制柱状图
fig, ax = plt.subplots()
bars = ax.bar(x, values, bar_width, label='自研产品销售数据', color='blue')
ax.set_xticks(x)
ax.set_xticklabels(months)
ax.set_ylabel('销售额（万元）')
ax.set_title('浙江分公司自研产品销售数据趋势')
ax.legend()

# 显示条形图的标签
for bar in bars:
    height = bar.get_height()
    ax.text(bar.get_x() + bar.get_width() / 2, height, str(height), ha='center', va='bottom')

# 显示图形
plt.show()

ChatGPT-3.5

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

import matplotlib.pyplot as plt

# 月份和销售数据
months = ["3月", "4月", "5月", "6月", "7月"]
sales_data = [118, 671, 446, 902, 1011]

# 设置中文显示
plt.rcParams['font.sans-serif'] = 'SimHei'
plt.rcParams['axes.unicode_minus'] = False

# 创建柱状图
plt.bar(months, sales_data, color='skyblue')
plt.xlabel("月份")
plt.ylabel("销售额（万元）")
plt.title("2021年3月至7月浙江分公司自研产品销售数据")

# 显示数值标签
for x, y in zip(months, sales_data):
    plt.text(x, y, str(y), ha='center', va='bottom')

# 显示图表
plt.show()

总结

我们先看总结一下上面的评分：

这个结果，惊不惊喜意不意外！Baichuan2-13B和ChatGLM2-6B居然都超过了ChatGPT-3.5。

当然，这只是我针对目前在RAG应用上所做的一些具体能力的测试，如果真的要全面测试，我相信ChatGPT-3.5依然会遥遥领先。而且ChatGPT-3.5对于中文的一些细节方面理解偏差，是主要的失分原因，不然它应该是得到最高的6分的。

另外声明一点，我不是为百川打广告，因为本人不认识任何百川的人员，但目前确实在试用百川的大模型，效果不错。

ChatGLM3-6B这次的能力让我感到惊艳，毕竟和百川13B在参数体量上相差两倍多，但是能力上比较接近，在RAG中非常重要的归纳和SQL生成两项中都非常出色。而且，最关键的事ChatGLM3-6B可以在RTX 3090上部署，这是非常涨粉的优势！

以上三个本地模型都没有经过微调，我相信大家可以在ChatGLM3-6B和Baichuan2-13B中选定其中一款，然后进行微调，去匹配自己的RAG应用。

最后，什么是行业大模型？难道装进去行业知识多就是这个行业的大模型吗？RAG就是来解决行业知识问题的。所以，在行业里面应用，我更倾向于专项大模型，比如金融行业，就需要更强的逻辑计算、SQL和图表生成能力；而文博行业，更倾向的润色、归纳和统计次数等能力。所以，我认为可以有专项大模型，只有行业应用，没有行业大模型。

本文主要内容：

• 近期关于RAG的一些行业交流
• RAG过度依赖ChatGPT好吗？
• RAG存在的一些问题
• 5个改善RAG性能的方法

近期行业交流的收获

近两周我们也在做一些RAG方面接地气的探索，所谓接地气，就是不仅仅研究产品技术，还包括和一些行业人士交流RAG在他们的业务场景中的需求。包括与金融、法律、高校、生产型工厂、贸易公司、电商、餐饮、知识产权和文旅等行业的人士交流，后续还安排了和政务、医疗、通信、能源、教育（非义务教育）和交通等行业的人士交流。说实在的，现在大家需要的基本都是Chat——快速根据已有文档，建立知识对话系统。但是随着交流的深入，我们和行业专家也发现了一些有意思的应用，绕开了问答系统，而且，这些系统往往更加适配行业客户的需要。

增加行业交流，是做产品PMF中的一个基础工作，使我们要知可以道技术能带来什么产品，而产品能为使用者带去什么价值。后续我们会继续交流，但是会把重心锁定在其中的两三个行业，做好真正有价值的产品。

通过近期的交流，也发现了一些问题，和大家分享一下。

RAG过度依赖ChatGPT好吗？

假设我们有一个可以无限输入tokens长度的LLM，输入字符串的长度对生成式LLM的精度没有影响。除此之外，它的行为与所有其他流行的大语言模型完全相同。我们称这个模型为完美LLM。我们认为它是完美的，不是因为它有出色的性能，而是因为它有理想的无限输入tokens长度，这在今天是不可能的。无限制的输入tokens长度确实是一个吸引人的特性。事实上，像ClaudeAI就允许输入的tokens长度为100万！但是，100万tokens够了吗？因为它只相当于4-5MB，仍然比实际业务中的大量文档要小得多。

现在的问题是：当你拥有如此完美的LLM时，你还会考虑RAG架构吗？具有无限输入长度的完美LLM减少了构建复杂RAG的必要性。然而，可能是的，您仍然需要考虑RAG体系结构。RAG架构不仅克服了LLM输入长度的限制，而且降低了LLM调用的成本，提高了处理速度。生成式大语言模型必须按顺序处理内容：输入越长，速度越慢。

关于调用成本我想多说一句，传统的应用程序，随着并发量增加，其实边际成本是在下降的。当然它也有一个临界点，比如1千并发和1万并发需要的硬件资源会急剧上升。但是总体上来说，边际成本还是会随着并发量增加而下降。但是，这种情况目前在GPU算力主导的LLM身上没有发生，现在基本上还是存在着并发越高成本也越高的情况。也许后面会有所改善，但是目前我还没有看到这个迹象，如果你有看到不同的信息，也可以分享一下。

但这里我想提一个相反的意见！

我们可以看到有很多关于如何构建RAG应用程序的示例代码和开源框架（如LlamaIndex和Langchain），目前它们产出一些技术和代码案例，使用的托底LLM基本上都是OpenAI的ChatGPT。我们碰的一些已经在做RAG应用的企业，也是无一例外的在试用OpenAI。就像上面说的，这本身是正确的逻辑，因为先用目前的上限做测试，至少我们”未来可期“——等国产大模型慢慢追上来。但不得不说，ChatGPT虽然还不完美，但已经很强大了。看了这些案例之后，我们也能发现完全基于ChatGPT好像有点背离我们构建RAG的初衷，也存在一些风险：

• 违背设计初衷：RAG的设计初衷是减轻LLM的各类问题，比如前面说到的减少幻觉、减少费用，增加实时性。但重度依赖ChatGPT反而把RAG做成了一个大模型的客户端，有点违背帮LLM分担压力的初衷；
• 国内使用风险：在国内使用ChatGPT属于是两头堵的状况，OpenAI对中国大陆用户是明确禁用的，国家对于非可控信源也是有严格的使用说明的。如果你只是自己搭建在家里或者公司内容研究用，那可能风险相对较小。但是如果要基于LLM和RAG技术对外提供经营服务，那基本上你还是需要退回到使用国内经过网信办审核的大模型。

而像我们这样使用国产大模型，或使用自己本地部署的开源大模型，确实在整体效果上和OpenAI是存在一些差距的，有时候事倍功半，想想还是挺气人的。我们需要为大模型本身的能力差距做很多”胶水组件“，其实就是很多中间件，比如表格处理，使用OpenAI的话我们可以直接使用开源的PandasAI（我之前也介绍过这个库），它会产生一些代码执行语句，给到ChatGPT，就能生产很好的结果。但是在国产大模型里面，没有这么强的程序执行能力，我们就需要做一些表格存储、处理和计算的额外功能，像这样的例子还有很多。

但是这样做的好处是我们对RAG整个体系中各个环节都越来越清楚，可以快速定位到问题，知道怎么做一个胶水组件去解决问题。假以时日，国产大模型追上了GPT-3.5的水平了，那精通RAG内部各个细节的你，做出来的应用应该也会比别人的更优秀。

RAG性能预期

我们直接将Prompt输入到LLM中，LLM会直接消化输入文本中的所有信息，最终结果的准确性仅取决于生成式LLM的性能。

对于普通的RAG应用程序，还有两个影响最终性能的组件：语义搜索方法和RAG实现。

RAG架构使用Embedding模型来生成真实知识和查询的向量。然后使用向量相似度匹配算法来检索最相关的内容。Embedding模型从文本中提取表征向量的能力是非常关键的。除了Embedding模型之外，在RAG开发中还有很多实现细节，这些细节也会严重影响最终的结果。也就是说，RAG输出的准确率等于LLM的准确率 x 语义搜索的准确率 x RAG信息保存率。

如果这三个因素都小于100%，RAG应用程序的预期精度会低于直接使用LLM模型的精度（我在之前的文章中已经提到过）。如果RAG的设计不合理，其性能会显著下降。当我们开始考虑我们的RAG应用程序设计时，这是要记住的第一个概念。否则，意想不到的结果会让我们非常失望。

信息保存

很容易理解，LLM模型和语义搜索都不能达到100%的准确率。让我解释一下什么是RAG信息保存率。

我们提供给应用程序的文本语料库可以包含非常丰富的信息。让我们来看看语料库中的内容以及如何将信息输入LLM:

上图描述了文本语料库中的实体关系。实体分布在整个语料库中，引用关系也无处不在。在分块之后，实体在每个筒仓中受到约束，并且chunk之间的关系都被切断。在检索短语中，只有top-k的chunk会有机会被检索召回，然后发送给LLM处理输出。这意味着只有一部分实体和关系可以转发到LLM。如果需要广泛的关系知识来响应查询，LLM将会遇到麻烦。

除了实体关系之外，分块操作还会对输入中的其他各种类型的信息产生影响：

1. 上下文信息:

在大多数情况下，文本具有多层上下文信息。例如，《统计学习的要素》这本书有18章，每一章都专注于一个主题。每章有副标题和第二层副标题等。人们习惯于在语境中理解文章。分块策略使内容与上下文脱节。

2. 位置信息:

文本的权重取决于它们在文档中的位置。文档开头和结尾的文字比中间的文字更重要。它们出现在一章的开头或结尾比出现在一章的中间更重要。

3. 连续的信息:

自然文本也经常使用显性和隐性语言连接来连接主题。例如，一个故事可能以“in the beginning”开头，然后以“then”、“therefore”、“after that”继续，直到以“finally”、“finally”等结尾。使用分块策略，这种连接不再是完整的。不仅谜题不见了，而且排序顺序也被打乱了。

4. 描述信息:

这指的是描述单个主题的信息。使用分块，可能无法保证描述性信息集中在一起。想象一下你正在打电话，突然电话线被切断了。这取决于你的电话有多重要，当它发生时，影响范围从微不足道到非常令人沮丧。

RAG的优势和劣势

如果我们把只使用分块和向量相似度搜索的抹布称为“香草抹布”，我们可以看到它们只能处理几种类型的查询，因为它们丢失了我们之前谈到的一些输入信息:

1. 擅长小范围的描述性问题回答。例如，哪个主体具有某些特征?
2. 不擅长关系推理，即寻找从实体A到实体B的路径或识别实体集团。
3. 不擅长时间跨度很长的总结。例如，“列出所有哈利波特的战斗”或“哈利波特有多少次战斗?”

RAG应用程序在这类任务上的表现很差，因为只有少数chunk可以输入到LLM中，而且这些chunk是分散的。LLM会缺少很多辅助信息，比如元数据和世界知识。当然，元数据和世界知识都是可以去增加的，这也是我们现在的工作之一。

了解RAG能做什么和不能做什么，可以让我们为RAG寻找最适合的领域，避免强行进入错误的地方，比如千万别让RAG去写诗，它的算数能力也很差，我们现在是自己做了外挂程序（胶水组件）来完成这部分工作的。

如何改进RAG应用程序

讨论了RAG应用程序的局限性之后，让我们看看如何改进它的性能。

好好优化你喂给LLM的内容

通常，在处理输入查询时，我们只是接受用户输入的任何内容。这并不理想，不仅因为存在prompt泄漏和prompt注入等安全风险，还因为性能也可能令人失望。

根据研究人员的说法，大语言模型对prompt中的拼写错误和措辞差异很敏感，为了确保大语言模型以其最佳性能运行，请考虑纠正所有错字并将输入改写为大语言模型更容易理解的形式。

保持Embedding模型在同一层面上

在大多数情况下，用户发送简短的查询，比如“告诉我更多关于徐悲鸿的信息”。然后，将查询转换为Embedding向量，该向量捕获该特定查询的本质。使用直接查询进行语义搜索可能具有挑战性，因为:

1. 用户查询很短，以问题的形式出现。它们包含有限的语义特征。虽然文档Embeddings以各种形式的语句的形式很长，但文档Embeddings在其向量中具有丰富得多的信息。
2. 由于用户查询中的语义特征有限，语义搜索功能热衷于过度解释查询中的琐碎细节，致使文档Embedding有很大的噪声。分块使情况变得更糟，因为许多关系、上下文和顺序链接都是错乱了。
3. Embedding模型和LLM属于不同的家族。他们接受的训练不同，行为也不同（比如Baichuan2-13B和ChatGLM2-6B在功能和行为上就差异很大，一个马上会给出简洁明确的答案，另一个则更像诗人，可能答案也是对的，但是用词浮躁对于用户干扰很大）。Embedding模型不具有与生成大语言模型相同水平的推理能力。他们甚至不像生成大语言模型那样重视语言细节。直接使用用户输入进行查询，在最坏的情况下，会使语义搜索功能降级为关键字搜索。
4. 由于Embedding和LLM是两种不同的模型，在整个过程中扮演着不同的角色，它们并不在同一层面上。这两个模型根据他们自己对需求的理解来完成他们的工作，但他们彼此不交谈。检索到的信息可能不是LLM产生最佳结果所需的信息。这两个模型没有办法相互对齐。

为了避免这个问题，您可能希望首先使用LLM来增加用户查询。考虑下面的例子:

原始用户查询：跟我说说托尼·艾伯特。

在原始查询的基础上使用Bard重新表述的增强查询:

• 艾伯特的政治背景是什么?

• 托尼·阿博特最显著的成就是什么?

• 艾伯特的政治观点是什么?

• 托尼·阿博特的个人兴趣是什么?

• 托尼·阿博特卷入了哪些争议?

你能看到信息丰富程度的提高吗？增强查询提供了更多的特性，从而产生了更好的检索结果。此外，通过发送增强查询，LLM有机会告诉Embedding模型它需要什么，Embedding模型可以更好地为LLM提供高质量的块。这就是两种模式协同工作的方式。

分块策略

块（chunk）大小是我们可以为RAG应用程序调优的为数不多的超级参数之一。为了获得更好的结果，建议使用较小的块大小。微软就有这样的分析:

在分割文本时，我们也可以选择不同的分割策略。最简单的方法是在单词的中间切断。我们也可以尝试不同的策略，比如在一个句子或段落的中间切断。为了得到更好的结果，我们可以重叠相邻的块。来自微软分析的分块策略比较:

Embedding模型的语义提取能力有限。它们在呈现多主题、多回合语料库时不如简单语料库有效。这就是为什么RAG更喜欢较短的块。那么块的大小是最好的呢?在微软的分析中，最小的块大小是512个tokens。一些企业级RAG应用程序中的块大小只有100个tokens。最小的块大小是否总是能获得更好的结果?

如前所述，分块策略会将文本语料库分解成小块，导致信息丢失。数据块越小，丢失的信息就越多。所以，有一个最优的块大小。过小的分块可能不太理想。然而，寻找最优块大小就像超参数调优一样。你必须用你的数据做实验。

减少信息损失

微软的分析发现，大量重叠的分块可以提高准确性。为什么它有帮助，我们能否找到更好的方法来提高RAG性能?

重叠背后的原因是重叠可以帮助将相邻的块链接在一起，并为块提供更好的上下文信息。然而，即使是非常激进的25%重叠也只能将准确率提高1.5%，从42.4%提高到43.9%。这意味着这不是优化RAG性能的最有效方法。我们不能通过更多的重叠来进一步提高RAG的性能。记住，重叠分块甚至不能用于小块。

但是重叠有时候在处理代词的时候很有效，比如上一个chunk说到”徐悲鸿非常擅长画马“，然后下一句说”他画马的主要技法是xxxxx“，这时候如果缺少了重叠，就会让这个代词变成”无主之地“。

当然，目前还有一种非常流行的做法是引入知识图谱，包括NebulaGraph提出的Graph RAG。

在知识图谱的帮助下，RAG可以将这些关系存储在图数据库中。块之间的连接可以完全保留。如果关系推理对您的项目至关重要，那么这是一个非常可观的解决方案。

然而，带有知识图谱的RAG并不是没有挑战的。从非结构化文本中建立知识图谱是非常重要的。有很多关于从文本输入中提取实体-关系三元组的实验。当你需要将解决方案产品化时，情况就不同了。自动提取的实体和关系可能包含大量的噪声，忽略了太多的真实信息。你们必须非常仔细地检查产品的质量。即使在填充知识图谱之后，所支持的查询也与图数据库设计紧密耦合。

支持向量搜索的关系数据库不像带有Knowledge Graph的RAG那么花哨，它也是工具箱中非常重要的组件。像pgvector这样的数据库允许您将复杂的信息存储为列，同时保留语义搜索功能。它比知识图谱更容易与其他企业系统集成，也更灵活。

这些都是值得考虑的有效选择。唯一需要注意的是，许多支持矢量的图形数据库、搜索引擎和关系数据库并没有完全优化为向量数据库。它们在处理大规模向量索引时的速度可能不理想，特别是当它们必须经常更新索引时。可参考之前的一篇文章《》

看看主要原因是什么

有时，我们发现RAG不能很好地回答我们的问题。我们应该考虑以下问题，而不是盲目的捣腾一通:

• LLM是否已经获得了它需要的所有信息?
• 这些信息是否对LLM友好的方式喂进去的?

让我们考虑下面的例子:

我们正在SharePoint网站上构建一个RAG应用程序。其中一个网页是关于所有的项目和他们的团队成员，包括所有人的个人资料。我们需要确保RAG准确地回答项目与团队成员的问题：然而，最初的结果非常令人失望。

初步调查显示，SharePoint网站没有以结构化的方式组织内容，从而使信息的从属关系易于理解。删除所有HTML标签后，网页内容如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

project A
Client Contact: Steve
Team Members:
person A
person B
email of person A
email of person B
role of person A
role of person B
description of person A
description of person B

project B
...

如果说人类很难区分谁是谁，那么RAG也很难区分。为了更好地组织信息，我们使用Python代码根据HTML属性将信息聚合在一起，将每个项目和团队成员的姓名分离到一个文本文件中，并将每个人的信息放入自己的文件中:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

file project_A.txt:

project name: project_A
Client Contact: Steve
Team Members:
Adam Smith
Jobs Musk

file person_A.txt:
name: Adam Smith
email: adam.smith@xxx.com
role: engineer
description: Hobbies/passion: rock climbing

...

生成的文本文件很小，这似乎与RAG分块实践不一致。原因是合并后的文件避免了分裂的问题，完全消除了噪音。有了新生成的文件，RAG可以毫无问题地回答诸如“谁在做项目x?”以及“亚当·斯密的爱好是什么?”

然而，当我们把问题转过来:“亚当·斯密在做哪个项目?”我们看到亚当·斯密被列在项目成员名单中。我们不太确定为什么Embedding模型不能捕捉到它。为了帮助LLM完成工作，我们可以使信息脱颖而出。我们在这个人的文件中添加了一行，明确地说明了项目的参与情况:

1
2
3
4
5
6
7

file person_A.txt:
name: Adam Smith
email: adam.smith@xxx.com
role: engineer
description: Hobbies/passion: rock climbing

project: project_A

这一行使RAG应用程序能够100%准确地回答上述问题。

结束语

RAG作为一项新兴技术，正在快速发展。我发现逐项研究它的组成部分对我有很大帮助。通过研究细节，我可以更深入地了解这项技术的利弊，并对一项新想法是否可行有一个基本预判。有一些非常流行的框架可以帮助我们更快地开发RAG应用程序。我发现其中的一些执行理念非常鼓舞人心。但是，我不建议仅仅因为它们很容易上手就开始学习或开发基于这些库的RAG，很多时候如果你真的要扎根进去，还是可以考虑一下”古法酿造“，会有更多惊喜的收获。

如果您已经阅读了本文，那么您肯定同意RAG是一个复杂的体系结构，所谓入门简单精通极难。很多国外的文章以及流行的框架掩盖了所有的细节，这让人们认为这些细节并不重要。当我们在项目中遇到问题时，会发现很难找到出路，因为有太多的实现细节。而且对于国内的程序员来说，这个难度还会极大提高，因为我们在正式环境中很难对接OpenAI的ChatGPT，除非你只是把应用部署在自己家里或者公司自用。抛开ChatGPT这个”超级“大模型，替换成可以本地部署的开源大模型或者国产大模型，如果你要达到一样的效果，那就需要在中间件和应用层做很多胶水组件。

如果你刚刚接触RAG不够，我还是建议你先从基本知识开始研究，了解内部细节，再用那些主流框架的时候，你才会收放自如。

引用

0.Practical Considerations in RAG Application Design：https://pub.towardsai.net/practical-considerations-in-rag-application-design-b5d5f0b2d19b （本文很多内容来自该文章）

1.Prompt Robustness: How to Measure and How to Enhance：https://pub.towardsai.net/prompt-robustness-how-to-measure-and-how-to-enhance-644fb6493ec?source=post_page-----b5d5f0b2d19b--------------------------------

2.Azure Cognitive Search: Outperforming vector search with hybrid retrieval and ranking capabilities：https://techcommunity.microsoft.com/t5/azure-ai-services-blog/azure-cognitive-search-outperforming-vector-search-with-hybrid/ba-p/3929167?source=post_page-----b5d5f0b2d19b--------------------------------

3.What We Need to Know Before Adopting a Vector Database：https://medium.com/@kelvin.lu.au/what-we-need-to-know-before-adopting-a-vector-database-85e137570fbb?source=post_page-----b5d5f0b2d19b--------------------------------

4.Disadvantages of RAG：https://medium.com/@kelvin.lu.au/disadvantages-of-rag-5024692f2c53?source=post_page-----b5d5f0b2d19b--------------------------------

Update: 2024-01-26

我们的TorchV Bot产品目前已经开始试用了，详情可以点击：https://www.luxiangdong.com/2024/01/25/lanuch-1
目前只接受企业用户试用，需要您填写一些信息，必要信息如下：

邮箱： 用来接收地址和账号
如何称呼您：
所服务的公司：
您的职位：

当然，如果您可以告诉我们您的使用场景，我们将更加感激！
对了，可以发送到yuanwai@mengjia.net
另外，也可以直接加我微信（lxdhdgss）联系我。

本文导读：

• 实际业务中应该如何使用大模型的思考
• 记录一款大模型产品的0到1过程

在公司已经六年多了，六年多里收获很多成长，从纯研发leader开始，先后带过大数据产研团队、AI产研团队和运营团队，而且还作为独立销售和解决方案获得一些著名客户的订单，从一个coder变成了多面手。所以，在即将离别之际，不去讲其他纷争，只从产品角度去写两篇文章总结过去。上篇写今年之前三年的一些感想，主要记录力石小知的成长——《总结一下过去三年的产品心路》。这篇写的就是今年，在大语言模型（LLM）开始进入国内之后，我们如何思考它带来的影响，以及如何务实去落地一款产品。

本文有7000多字，有点长，Enjoy！

一、对大模型技术的积累

看过上篇的朋友应该知道，我们在2019年就已经开始了AI产品的研发，并且这几年有一定的市场品牌口碑和数据积累。也正因为有这样的“AI传统”，我们才有一定的人才储备（比如我们的小胡，B站ID：良睦路程序员，Github：yuanzhoulvpi2017），所以当今年大模型这波新的AI浪潮袭来的时候，我们算是入局比较早的：

• 参与大模型社区：在今年2月份，我们团队发布了最早的ChatGLM-6B社区版LoRA版本代码——（见下图）获得智谱官方PPT的介绍，这个Github Repository就是我们团队的；
• 发布商用大模型：3月份我们基于BLOOM-7B训练了自己的可商用大模型，是从CLM（因果模型训练）开始的全量训练，到后面的SFT（有监督精细微调），也因此获得某大厂和两家运营商的合作。当然后面因为要发证，我们知道自己无法在近两年内获得牌照，因此也就掉头重点转向大模型应用了；
• 打造大模型应用：使用大模型改进上篇提到的产品——小知，原来小知基于BERT，现在变成BERT在前，GPT在后兜底的双模型系统。另外更重要的就是创造了一个基于大模型的新产品，这也是本文后面重要要讲的内容。

而且相对其他同行来说，我们还有一个独特的优势就是数据积累。

小知3年多服务中产生的数据量极大，且格式就是“问答指令集”，非常适合SFT（有监督精度微调）。有朋友可能知道之前Dolly2大模型发布的时候，他们用了仅仅1.5万条自己生成的问答指令集，就基于gpt-neox训练出了一个很有竞争力的模型。所以就文旅行业来说，我们的微调工作在百万级挑选出来的数据帮助下就相对有效。加上我们有一个很有活力的团队，于是如何将LLM用在产品中就自然而然成为了我们团队的新任务之一。

二、大模型的还有哪些缺点

这次大模型和以往的新技术的出现有所不同，大家一开始都是先从OpenAI的ChatGPT开始的，有点”开局即巅峰“的意思，以至于后面大家接触”车水马龙“会笑得人仰马翻。基于ChatGPT的普及，大模型的优点我就不赘述了，下面我们说说这位法学硕士（这是一个梗）的缺点。

1.大模型的主要缺点

Chat（问答系统）只是最基本的大模型应用，说白了就是OpenAI放出来的一个Demo。我们把大模型应用在企业业务中时，问题依然很多，主要包括：

• 幻觉问题：大模型的底层原理是基于概率，所以它有时候会一本正经胡说八道，比如我们问大模型的Chat（问答系统），“良渚博物院下周一开门吗？”我相信这样的问题你不能连续问，因为大模型会有一定的几率告诉你开门（而实际情况是周一闭馆，除非碰上法定节日）。而如果游客真的在下周一去了良渚博物院，那估计就要失望了。如果这个Chat还是博物院官方提供的，那事情最终会演变成一通12345的投诉电话。所以在很多需要非常精准服务的场景，仅仅依赖GPT这种”盲目自信“的生成式回答是很不严谨的，而且看起来很难消除——目前我们常见的解决方案是前置一个BERT和语料维护，或者使用RAG（检索增强生成，目前正在成为主流）或者预置大量prompt做优化（有公司这么在做）。
• 新鲜度问题：规模越大（参数越多、tokens越多），大模型训练的成本越高。类似OpenAI的ChatGPT3.5，目前的数据新鲜度依然保留在2021年，对于之后的事情就不知道了。而且对于一些高时效性的事情，大模型更加无能为力，比如帮我看看今天晚上有什么电影值得去看？这种任务是需要去淘票票、猫眼等网站先去获取最新电影信息的，大模型本身无法完成这个任务。现在主流的解决方案是增加RAG方案；
• 数据安全：先抛开OpenAI已经遭到过几次隐私数据的投诉。就企业应用来说，如果把自己的经营数据、合同文件等机密文件和数据上传到云上的大模型，那想想都可怕。如果企业人员想提一个类似这样的问题：“帮我看看3月份XX部门的销售环比数据与哪些兄弟部门的增长是密切相关的？”，这需要打穿企业内部的很多数据。既要保证安全，又要借助AI能力，目前最好的方式就是把数据全部放在本地，企业数据的业务计算也全部在本地完成，然后在本地部署参数相对较小的大模型；
• 费用问题：ChatGPT一开始是免费的，到后面开始API调用的收费，再后面出现的GPT-4的价格已经让很多人认识到AI是有成本的。这甚至造成了Langchain、AutoGPT等半自动和全自动的Agent框架立马遭遇冷落~~费用扣的太快了！！

2.国内大模型的问题

上面说的还是OpenAI的问题，再说回到国内，我们的大模型的能力和OpenAI还是有很大差距的，包括一些常用的推理能力。

除了能力上的差距，国内AI大模型及相关产业的从业者还面临着更多的问题：

1. OpenAI等大模型的使用限制：即使你获得了GPT-4的API调用权限，依然会被突然封禁。而且国内对于公共应用中使用OpenAI和Claude等外部大模型的限制也是很严格的，所以自己玩玩可以，但真的要企业中对外服务，还是需要正视外部API的问题；
2. 政策法规的严格把关：目前包括微信（小程序）等应用端，对于应用中大模型的介入是需要提供各类备案的，大部分公司无法做到（好像有点无解，但是别急~）。

3.我们的选择

所以我们对于大模型在产品中的应用是相对较为谨慎的，目前主要的大模型应用思路包括以下几点：

1. 国产模型优先：绝不直接采用国外的大模型API服务，而是采用国内的产品，如智谱/百川/文心一言/通义千问等的API。或者就是分不同使用场景，采用自己本地部署的Baichuan2-13B/ChatGLM2-6B等国产大模型和Llama7B等开源模型。因为采用国外大模型虽然确实很爽，但是会形成整个技术栈依赖，弱化内部真正解决问题的能力；
2. RAG优先：RAG（Retrieval Augmented Generation，检索增强生成）做为大模型应用的一种优秀补充，借助向量embedding、相似度匹配等技术，可以将客户给定的PDF、Word和视频等内容快速形成知识对话能力。相对于微调（Fine-Tuning），RAG在知识新鲜度、幻觉和数据安全方面都更容易掌控，特别是幻觉问题，对于后续应用上线时候的审查是非常有效的。而且最关键的是RAG这种胶水组件的解决方案可以很大程度上减轻我们对大模型能力的依赖；
3. 预生成优先：我相信现在国内大模型应用到后面最大的成本会是符合法规方面的对齐工作，内部审查也是很多公司的高月活产品最大的人力成本之一（听说B站的审核人员有4位数）。所以我们目前优先考虑的做法是预生成，通过大模型提升生产效率，把以前无法想象的生产成本极大压缩（后面介绍产品的时候会说到），所有呈现给最终用户的产品内容是透明可审查的，避免大模型在生产环境中突然”抽风“。

好了，说了这么多思考，接下来我们开始来说说今年做的这款新产品的0到1.

三、大模型产品启动

1.产品赛道选择

我现在所处的行业是数字农文旅。

农业农村是个大市场，也是国家这几年重点在发展的赛道，各种项目资金可以说非常充沛。但是农村也有一个大问题，就是它是一个大行业，却不是大市场，更多的客户是非常分散的，且不是知识密集型行业，所以对大语言模型并不友好。加上这两年接触下来，涉及的项目还是以形象工程为主，真正的产品力无法深入体现，个人感觉也没有能力真正把产品力做出来。所以放弃数字乡村赛道。

接下来是旅游。很多人可能看到疫情后旅游市场的爆棚，但在行业内，我们可以看到旅游消费依然乏力，City Walk、郊游（公园搭帐篷）等形式火热兴起。对于景区、文旅集团等，目前的日子依然不太好过…。我一个朋友在10月9日截了一个上市文旅公司的二级市场走势图可以说明一些问题。但是最可怕的是，除了一些稀缺级别的景区和一些新型服务形式的景区之外，景区这种靠山吃山靠水吃水的服务形式，正在失去游客…

综合考虑之后，这次我瞄准的是文博行业，更具体的说就是博物馆（院）和遗址公园一类的客户。就像上面说到的City Walk的火热，文博场馆就是大家主要的目的地或参观游玩点之一。

可以这么说，这次产品赛道的选择，我没有去看政策影响和甲方的资金是否充沛这些传统的toG/toB玩法，而是主打toC。这次的甲方更多是站在合作伙伴的位置上，我们是帮助他们一起来赚钱的，所以更看重的是人去了哪里。这个观念也可以参考我之前的一篇文章《进击吧！硬地骇客————独立开发者时代来临》里面提到的市场环境变化。

2.产品构思的产生

因为我是良渚遗址项目（其中旅游这部分）的商务+售前，所以和良渚遗址的领导比较熟。有一次就请教了监测中心的孙主任，他对于文物活化的看法。这一问不得了，确实颠覆了我很多认知，因为之前我对于活化的思考更多实在VR这些方面上，当然基本上都需要大投入大建设。主任对VR/AR也基本上是认可的，但是他说技术不能解决核心问题，他觉得核心问题就几句话：”文物活化，就是要让观众看得懂、喜欢看，看了之后能传播！“（具体意思应该就是这样的，可能用词上更我写的更准确一些）。当时有种被电流击中的感觉，真正的内容如此简单直白。

有了这句话的影响，我就去找各种资料加深这种感觉，其中对我帮助最大的是窦文涛的《锵锵行天下·第三季》，里面有一期讲《富春山居图》的，非常精彩，确实讲出了很多我之前自己看展品根本看不出来的道道。

特写一：黄公望把自己也已经画进了《富春山居图》中，也是对他自己在富春江畔九年的写生生活留下一个缩影；

特写二：水的画法和山是有直接关系的，有直接冲刷山体的，有掠过山体的，也有打了回漩到山坳里泛起粼粼波光的，每种笔触是对山水的真实写照；

特写三：通过清晰度和识别度造成远近和悠远，营造江面被一层薄雾笼罩的视觉，通过这种技法，让观察者心中感觉到烟云，既为“烟云供养”的技法；

特写四：披麻皴技法，古代山石画中非常精髓的技法，利用中锋手法，高处做大结构、气势磅礴，低处（离观察者近）构思精巧。

这么一解读，是不是对这幅浙江博物馆的镇馆之宝（浙博只有前半卷，也就是《剩山图》，后半卷在台北故宫）有了更多了解。

通过这两件事，我对新产品有了一些初步构思，就是文化文物不是仅仅靠听就能听懂的，文化文物是需要视听同步才能做到“看得懂、喜欢看，看了之后有谈资”的。于是我觉得这里面是有一个空白市场，而且也是一个风险相对较小的产品——导游讲解机已经有十多年历史了，我们去升级迭代这个产品，去拿这一块市场。

3.产品调研无需太多

我把调研分成两拨，第一拨调研是让我团队的一位我认为比较聪慧的同事（倩文）去的，她走了五个馆，写了大概万把字的调研报告，给了我第一手的信息。也是已通过这些资料，我坚定了做这个产品的决心，这里肯定是有市场空白的。

第二拨调研是我自己去的，而且还邀请了另外两个同事，一位是我们分管副总裁王总，另外一位是我们的产品总监欧阳。这一拨调研我有重点地将目标放在了我自己的原有客户身上。两个客户分别是宁波天一阁博物院和杭州的良渚古城（和博物院）。调研发现其实市面上已经有AR眼镜的产品，外形看上去其实还是挺酷的，但问题也很明显，主要是三点：

• AR眼镜夺走了观众的第一视野，虽然我们带着眼镜，但是看的却是眼镜里面的视频，而不是眼前的文物。而且为了画面清晰，观看时还需要把里面的墨镜盖下来，根本看不见前面的路，造成游客行走困难；
• AR眼镜里面的视频内容更新很不方便，价格贵、制作也非常困难，所以我们调研的其中一个博物馆的馆方人员和我们说，今年已经是合作第15年了，期间却只改了三段视频，因为制作成本有难度，而且成本太高了。
• 没有什么交互，就是到一个点位，然后视频弹出来，说实话和在家里看视频没有太大区别。

对于传统的导游机，它的问题还是无法用画面来展示文物背后的故事。

于是，我觉得也不需要再调研了，因为我已经可以给新产品做定义了。

4.产品定义

我给新产品定的内部名称是”可交互AI讲解“。

下面是给这个产品做的几个定义：

1. 降低新产品风险：讲解器市场存在已经十多年，本身就证明了这个市场存在，我们要做的是迭代这些原有的产品，分割一部分市场，产品风险较小，但是市场够大；
2. 体验上要优于现有应用：即使现在有手机扫码讲解这些新功能，但是我们会使用iPad作为主要载体，在显示效果、屏幕大小和实用性方面都远超手机，高达5GB的离线资源预安装在iPad里，无需游客自己手机下载，不用担心耗流量和耗电；
3. 视频是最佳展现形式：讲解语音和视频画面同步，可以讲解深度内容，比如上面说的富春山居图，只有画面同步才能完美展现出来；
4. 交互带来不一样的体验：可交互，观众在使用期间，可以随时进行交互，比如只要说”小知小知“，就可以用语音提问：”黄公望在来富春江之前是在哪里啊？“，交互采用的就是基于大模型的RAG技术；
5. 内容快速预生成：这也是支撑整个产品逻辑的底层核心。我希望是，内容运营人员挑选一本关于目标文物的电子书并上传，系统就可以自动将电子书内容做解读，分离图文，提取出很多小故事，然后自动生成一段一段的讲解视频。这才能满足100x的内容制作效率，才能时常更新内容，也能满足快速扩张的需要；
6. 合作大于项目：前面我也说了，这个产品我希望是toC的，所以我和客户的关系其实是平等的，我把产品放在你这边，让游客/观众付费使用，然后我们一起分润。这种方式比我们之前项目制打法要快很多，而且赚的是现金生意。

基于这6点，我已经可以规划处一个产品了：

前端

一个iPad作为主要载体，搭配耳机，播放的是关于当前文物的讲解视频。

后端

后端的核心是使用AI进行自动化内容生产，但是我们不会真的去追求一步到位，而是先使用半自动化的方式。前期会让内容编辑人员参与内容建设，然后记录他们的生产过程，结合上线之后的用户喜好数据，逐步进行全自动内容生产流程。

后端的简易流程图如下：

Step1：内容运营人员挑选有趣的内容，一般是电子书、论文和网络内容，当然需要经过馆方审核。然后将内容制作成PDF、Markdown等格式，上传到系统；

Step2：系统的调度程序（TaskScheduler）开始运行，将文档进行内容提取；

Step3：图片的提取相对复杂，首先单独存储图片，如果有图示文字的，存入图片相关的描述文本；如果没有图示，那么将图片上下文存入图片描述文本；或者还有一种就是文本中有下标（比如[3]），图片在章节末尾的，那就存在下标的上下文到图片的描述文本。图片的描述文本进行embedding处理。描述文本和图片直接的实体关系通过RDS进行对应（多对多关系）；

Step4：提存和存储文字，会先使用大模型进行润色，在Prompt里面设置较多角色、指令和带有行业knowhow的输出格式模板。润色之后的文字进行embedding处理。

Step5：中间略去一些处理细节，然后再以讲解文本为基础进行时间轴创建。讲解文本的chunk_size基本上是以句子为单元的，将讲解文本与图片描述文本进行语义匹配（相似度算法），自动组合视频时间轴，生成一段”伪视频“。为什么是”伪视频“，因为这时候其实是一个mp3播放器和一个带有转场特效的图片播放器的叠加。这个期间，运营人员可以对内容进行最后的调整；

Step6：合成最终视频的过程其实非常简单，其实就是录屏。

说实在的，这可能只描述了整个过程的50%流程，后面不断优化之后，整个流程不断增加新功能，整个生成过程也在不断完善。里面用到的技术也非常繁多，包括：

• ASR
• TTS
• Embedding
• 向量数据库
• 大语言模型（GPT）
• NLP、BERT

使用场景

其实定义使用场景这个工作是在我们第二拨调研之前做好的，这次调研我们面向是业内专业人士和馆方领导，需要有PPT做演示，要让对方快速理解使用场景，才能获得市场成功。如果你看过我上一篇文章《总结一下过去三年的产品心路》的话，是不是”产品-市场对角线“的感觉又出来了。

你知道，仅仅靠语言描述是很难把一个产品讲清楚的，即使你会画一些简单的线框图，对于其他行业的人来说也不好理解。所以有必要用相对真实的画先描述一下使用场景。我们这个时代最大的好处就是有各种AI工具可以帮助我们完成自己不擅长的事情，比如我不是画家，也不是摄影师，但是我依然可以用Midjourney画出脑海中的使用场景，于是，就有了下面这两张图：

四、产品研发过程

这个过程我肯定不太像说的太多，因为细节太过于繁琐，即使讲出来可能也索然无味，加上我也确实不能说太多，但有两点我觉得是可以分享的。

1.组织保障

读过之前《三年产品心路》的朋友应该知道我之前带队做小知的时候，开始的半年是靠实力生撑过来的，人员抓肩见肘。但这次不一样，老板把AI产品线定义为公司最重要的核心竞争力，加上VP王总加入之后，确实为这个产品注入了相对丰富的产研资源。

产品由公司P序列最高的产品经理欧阳（P9）负责，研发方面也是P8、P9的同事领衔，比如我经常提到的著名开源作者小明，还有公司最好的前端六木。当然AI算法和大模型方面参与的还有最开始提到的”良睦路程序员“小胡。付萍带的内容运营团队也全数参加，前面提到第一次调研的倩文负责整个产品研发进度的把控。

整个产品团队最多有16人，常规也有9人，对我来说，这次打的就是富裕仗。所以欧阳经常感叹的一句话是，两个月前还只是一份PPT啊，现在就已经出来v0.8版本了。总结下来，组织力量是非常重要的，没有组织能力的保障，很多产品出不来：市场+产品+研发+AI+运营+项目管理，这样的团队配置我相信在我们行业内是不太有的，所以我对于分享产品过程也没有太刻意的保留。

2.不断迭代

”产品-市场对角线“里面很重要的一点就是持续收集需求，然后迭代升级。

这次我们拜访了多家潜在客户，收集了大量需求，最终选择在宁波天一阁博物院首先落地。原因可能是他们刚好有一个展会的契机，而且黄主任是我觉得为数不多的既懂技术（包括大模型）又懂文博专业知识的专家。我们和天一阁联名参办宁波数字经济展会是一个非常好的机会，因为如果只是和黄主任聊聊天，我觉得很多建议不会太深刻，因为和他自身没有太大利益关系。而共同去办展，他在很多时候比我还重视这件事情，所以获得的需求是真切的。

五、后记

可交互AI讲解（后续可能会改名为”文博佳“）现在已经处于落地阶段，要处理的细节还有很多，11月份会在天一阁博物院率先落地。后面的几家意向博物馆也基本上做了联系，获得口头认可。

这算是又一个从Idea到产品的过程，不过这次理论推导更充分，也算是我在公司创造的第四个产品。这次的历程，最重要的是使用大模型对于实际业务结合的探索，虽然这次大模型在整个产品的技术组成中占比没过30%，但也是一个有意义的尝试。我们做产品最重要的不是炫技，而是要最终呈现用户价值，大模型、向量等在中间起到的作用是解决了内容生产效率的问题，这样我们才有胆量在前端（用户端）做到高要求，不然产品的持续力不够，内容断档，也最终只是昙花一现。

我目前更聚焦的是RAG方面的研发，大家都大模型、RAG感兴趣的话，可以关注我！

前面刚测试了Baichuan2-13B的本地化模型能力，对于我来说，归纳能力已经足够了。但是一旦深入RAG的应用，Baichuan2还是有一些弱势的，比如在表格的处理能力上，显得力不从心。让我们比较失望的是，目前国内一众模型里面，对这一块的处理能力都够呛，唯一可行的还是OpenAI的ChatGPT。

于是这两天也在空隙里面找可以本地化部署，对于RAG又比较友好的LLM，发现还真的有几个新的LLM出来了。

首先看到的是Mistral-7B，据说性能超过了Llama-13B。正当我准备好好研究一下的时候，又看到Wenqi Glantz老师在推Zephyr-7b-alpha，而且推荐理由里面有两点正是我想要的：

• 对RAG比较友好；
• 性能比Mistral-7B更强。

并且她还做了对比。

Zephyr介绍

下面我们来看看Zephyr-7b-alpha的介绍，以及它的性能如何！

Zephyr其实是一个大语言模型的系列名称，Zephyr-7B-alpha是该系列的第一款型号，它是基于Mistral-7B-v0.1微调而来的，使用直接偏好优化(DPO)对公开可用的合成数据集进行混合训练。我们发现，删除这些数据集的内置对齐提高了MT Bench上的性能，可以让模型更加出类拔萃。当然，这个模型因为是MIT的协议，所以是可以免费商用的，和其他很多可商用模型一样，也是申明仅用于教育和研究目的，意思就是在商用上出什么幺蛾子我不管的。

我在它的官方提供的测试地址上做了测试，首先它是支持中文的（答案当然是不准的）：

然后呢，它对于表格类型的问答，处理能力应该说比较弱吧，甚至有点不听指令（机器觉醒？）

Wenqi Glantz使用了EDD（评估驱动开发）的视角来探索zephyr-7b-alpha，使用LlamaIndex构建的多文档RAG管道，并与OpenAI模型GPT-3.5进行了比较。

zephyr-7b-alpha是一种7b参数类似gpt的模型，从Mistralai/Mistral-7B-v0.1微调而来。根据HuggingFace MT Bench，一个评估机器翻译(MT)系统质量的基准套件，zephyr-7b-alpha优于Llama-2-70b-chat-hf和Mistral-7B-Instruct-v0.1，请看下面的比较表。

LlamaIndex一直对各种LLM做兼容性跟踪评测，执行了一个LLM兼容性跟踪，从中我们了解到zephyr-7b-alpha是迄今为止唯一一个在高级RAG任务上表现良好的开源7b模型。

从上面的截图中可以看出，尽管zephyr-7b-alpha在大多数类别中都优于其他两个7b模型，但作为数据agent，它仍然有其局限性。让我们在下一节中继续进行评估POC时记下它。

BAAI/bge-base-en-v1.5

BAAI/big-base-en-v1.5是由北京人工智能研究院(BAAI)开发的文本Embedding模型。它是一个在大量文本和代码数据集上训练的大型语言模型。它可以为各种NLP任务生成文本Embeddings，例如检索、分类、聚类和语义搜索。它是HuggingFace的MTEB(海量文本Embedding基准)排行榜上目前排名第二的Embedding模型，仅次于其更强大的兄弟big-large-en-v1.5。

我们将使用BAAI/big-base-en-v1.5作为评估POC的Embedding模型。

POC评估

我们用两种实现策略评估了一个多文档RAG管道的能力:

• 递归检索器+文档代理
• 元数据替换+节点句子窗口

正如上面关于zephyr-7b-alpha的部分所指出的，它对数据代理有限制。在本文中，我们将忽略递归检索器+文档代理的实现策略，而将重点放在相同的多文档RAG管道的元数据替换+节点句子窗口的策略上。我们将比较以下两种实现:

• gpt-3.5-turbo + BAAI/bge-base-en-v1.5
• zephyr-7b-alpha + BAAI/bge-base-en-v1.5

gpt-3.5-turbo + BAAI/bge-base-en-v1.5

现在，让我们使用Embedding模型——BAAI/big-base-en-v1.5 ，请参阅下面的代码片段。注意，在构造ServiceContext时，embed_model现在指向local:BAAI/big-base-en-v1.5。

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

#define LLM and embedding model
llm = OpenAI(model="gpt-3.5-turbo", temperature=0.1)
ctx = ServiceContext.from_defaults(
    llm=llm,
    embed_model="local:BAAI/bge-base-en-v1.5"
)

from llama_index import VectorStoreIndex

# extract nodes and build index
document_list = SimpleDirectoryReader("data").load_data()
nodes = node_parser.get_nodes_from_documents(document_list)
sentence_index = VectorStoreIndex(nodes, service_context=ctx)

from llama_index.indices.postprocessor import MetadataReplacementPostProcessor

# define query engine
metadata_query_engine = sentence_index.as_query_engine(
    similarity_top_k=2,
    # the target key defaults to `window` to match the node_parser's default
    node_postprocessors=[
        MetadataReplacementPostProcessor(target_metadata_key="window")
    ],
)

这将触发将local:BAAI/big-base-en-v1.5下载到我们在Colab的环境中（你也可以用本地环境）。

zephyr-7b-alpha + BAAI/bge-base-en-v1.5

现在，让我们试试zephyr-7b-alpha + BAAI/big-base-en-v1.5的组合。请参阅下面的代码片段。注意，在构建ServiceContext时，我将embed_model更改为local:BAAI/big-base-en-v1.5。

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

import torch
from transformers import BitsAndBytesConfig
from llama_index.prompts import PromptTemplate
from llama_index.llms import HuggingFaceLLM

quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
)

def messages_to_prompt(messages):
  prompt = ""
  for message in messages:
    if message.role == 'system':
      prompt += f"<|system|>\n{message.content}</s>\n"
    elif message.role == 'user':
      prompt += f"<|user|>\n{message.content}</s>\n"
    elif message.role == 'assistant':
      prompt += f"<|assistant|>\n{message.content}</s>\n"

  # ensure we start with a system prompt, insert blank if needed
  if not prompt.startswith("<|system|>\n"):
    prompt = "<|system|>\n</s>\n" + prompt

  # add final assistant prompt
  prompt = prompt + "<|assistant|>\n"

  return prompt

# define LLM
llm_zephyr = HuggingFaceLLM(
    model_name="HuggingFaceH4/zephyr-7b-alpha",
    tokenizer_name="HuggingFaceH4/zephyr-7b-alpha",
    query_wrapper_prompt=PromptTemplate("<|system|>\n</s>\n<|user|>\n{query_str}</s>\n<|assistant|>\n"),
    context_window=3900,
    max_new_tokens=256,
    model_kwargs={"quantization_config": quantization_config},
    # tokenizer_kwargs={},
    generate_kwargs={"temperature": 0.7, "top_k": 50, "top_p": 0.95},
    messages_to_prompt=messages_to_prompt,
    device_map="auto",
)

from llama_index import ServiceContext

# constructing ServiceContext by defining both LLM and embedding model
service_context_zephyr = ServiceContext.from_defaults(
    llm=llm_zephyr, 
    embed_model="local:BAAI/bge-base-en-v1.5"
)

from llama_index import VectorStoreIndex

# extract nodes and build index
document_list = SimpleDirectoryReader("data").load_data()
nodes = node_parser.get_nodes_from_documents(document_list)
sentence_index_zephyr = VectorStoreIndex(nodes, service_context=service_context_zephyr)


from llama_index.indices.postprocessor import MetadataReplacementPostProcessor

# define query engine
metadata_query_engine_zephyr = sentence_index_zephyr.as_query_engine(
    similarity_top_k=2,
    # the target key defaults to `window` to match the node_parser's default
    node_postprocessors=[
        MetadataReplacementPostProcessor(target_metadata_key="window")
    ],
)

如果您在免费版Colab笔记本中运行上述代码，则在下载zephyr-7b-alpha 时可能会遇到错误。我不得不支付9.99美元的月费升级到专业版，并将硬件加速器的运行时类型更改为T4 GPU，并打开了High-RAM。这个小小的投资是非常值得的。

通过硬件调整，我们现在可以成功下载zephyr-7b-alpha。

评测

让我们使用LlamaIndex的响应评估模块添加剩余的评估代码。

综上所述，使用LlamaIndex的响应评估模块的高级步骤包括:

1. 使用DatasetGenerator自动生成评估问题。
2. 定义faithfulness和relevancy的评估者。
3. 使用BatchEvalRunner 来异步运行响应的评估。
4. 比较评价结果。

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

from llama_index.evaluation import FaithfulnessEvaluator, RelevancyEvaluator

# use gpt-4 to evaluate
gpt4_service_context = ServiceContext.from_defaults(llm=OpenAI(temperature=0.1, llm="gpt-4"))

# define evaluators
faithfulness_gpt4 = FaithfulnessEvaluator(service_context=gpt4_service_context)
relevancy_gpt4 = RelevancyEvaluator(service_context=gpt4_service_context)

from llama_index.evaluation import BatchEvalRunner

# define evaluation batch runner
runner = BatchEvalRunner(
    {"faithfulness": faithfulness_gpt4, "relevancy": relevancy_gpt4},
    workers=10,
    show_progress=True
)

让我们看看gpt-3.5-turbo和zephyr-7b-alpha的结果，两个测试的Embedding模型都是local:BAAI/big-base-en-v1.5。

评价

让我们收集这两个评估的结果并把它们放在一起（忽略all-mpent-base-v2）。

我们将faithfulness和relevancy的数字映射到一个图表中，得到以下结果。

我们可以看到:

• 与gpt-3.5-turbo + BAAI/big-base-en-v1.5相比，zephyr-7b-alpha + BAAI/big-base-en-v1.5的得分相同，faithfulness为0.93比0.93，relevancy为0.97比0.9。
• 评估执行时间在两个选项之间差异很大，zephyr-7b-alpha + BAAI/big-base-en-v1.5需要4分钟才能完成，而其他选项大约需要10秒。哎呀!这当然不理想。

zephyr-7b-alpha在评估的faithfulness和relevancy类别中确实看起来很有希望。然而，值得一提的是，HuggingFace:)对其局限性提出了几个关键点

Zephyr-7B-α没有通过RLHF等技术与人类偏好保持一致，也没有使用ChatGPT等循环过滤响应，因此模型可能产生有问题的输出(特别是在提示这样做的时候)。它也不知道语料库的大小和组成是用来训练基础模型的(Mistral-7B-v0.1)，但是它很可能包括了网络数据和技术来源如书籍和代码的混合。

同样重要的是要记住，从评估结果中得出的结论只适用于我们处理的特定用例。zephyr-7b-alpha + BAAI/big-base-en-v1.5在我们的POC RAG管道中略优于GPT-3.5，但这并不意味着它在您的用例中会优于GPT-3.5。本文旨在传达评估驱动开发的重要性，甚至在选择大语言模型和Embedding模型时也是如此。使用EDD作为瑞士军刀来剖析和评估您的用例，以找到最合适的工具和实现策略，使您的RAG管道成功。

总结

在本文中，我们通过EDD(评估驱动开发)的视角探索了zephyr-7b-alpha，使用rag相关技术:gpx-3.5-turbo + BAAI/big-base-en-v1.5和zephyr-7b-alpha + BAAI/big-base-en-v1.5。我们使用LlamaIndex的响应评估模块进行了评估，并比较了所有三种情况的结果。

我们可以得出结论，对于我们的POC RAG管道，zephyr-7b-alpha + BAAI/big-base-en-v1.5的组合略微优于OpenAI的ggt -3.5 + BAAI/big-base-en-v1.5。这对开源社区来说确实是一个鼓舞人心的消息!

引用

• Wenqi Glantz的评测原文：https://levelup.gitconnected.com/exploring-zephyr-7b-alpha-through-the-lens-of-evaluation-driven-development-faf69e9d9ec7
• HuggingFaceH4/zephyr-7b-alpha：https://huggingface.co/HuggingFaceH4/zephyr-7b-alpha
• BAAI/bge-base-en-v1.5：https://huggingface.co/BAAI/bge-base-en-v1.5
• Colab notebook for zephyr-7b-alpha-feature-test：https://colab.research.google.com/drive/16Ygf2IyGNkb725ZqtRmFQjwWBuzFX_kl?usp=sharing
• Open Source LLMs：https://docs.llamaindex.ai/en/stable/core_modules/model_modules/llms/root.html#open-source-llms
• LlamaIndex Response Evaluation Module：https://docs.llamaindex.ai/en/stable/core_modules/supporting_modules/evaluation/modules.html#response-evaluation

最近一直和小明在搞RAG，我们认为这对于大部分公司和个人来说，就是大模型的未来，有应用才能更好推动大模型发展，至少近三年内应该是。前面也输出了一些RAG方面的文章，也有了一套精确度相对较高的技术产品。但是你知道的，RAG领域也在不断发展，而且我们确实也还面临着一些实际的问题，所以最近开始细细研究LlamaIndex——我觉得适用于RAG领域的话，可能会比LangChain更优秀。今天我们先来看看LlamaIndex的索引。

什么是LlamaIndex

这是我自己列的一个结构图，当然是按我自己的理解画的，您只做参考吧，哈哈。

LlamaIndex是一个大型语言模型(大语言模型)的数据框架，提供以下工具:

• 数据摄取： LlamaIndex提供数据连接器来摄取您现有的数据源和数据格式(api, pdf，文档，SQL等)，以便您可以与大语言模型一起使用它们。
• 数据构建： LlamaIndex提供了构建数据(索引，图表)的方法，以便可以轻松地与大语言模型一起使用。
• 检索和查询接口： LlamaIndex为您的数据提供了高级检索/查询接口。您可以输入任何LLM输入prompt，LlamaIndex将返回检索到的上下文和知识增强的输出。
• 与其他框架集成： LlamaIndex允许轻松集成与您的外部应用程序框架(例如与LangChain, Flask, Docker, ChatGPT，或其他任何)。

LlamaIndex是为初学者和高级用户设计的。高级API允许初学者使用LlamaIndex在5行代码中摄取和查询他们的数据。低级api允许高级用户自定义和扩展任何模块(数据连接器、索引、检索器、查询引擎、重新排序模块)，以满足他们的需求。

以下是使用LlamaIndex的一些好处：

• 易于使用： LlamaIndex有一个简单直观的API，使其易于入门。
• 灵活： LlamaIndex可用于摄取和查询各种数据源和格式。
• 功能强大： LlamaIndex提供了广泛的功能，帮助您构建强大的LLM应用程序。
• 可扩展： LlamaIndex是开源和可扩展的，因此您可以自定义它以适应您的特定需求。

什么是index

LlamaIndex中的索引是一种数据结构，它允许您从大量文本语料库中快速搜索和检索数据。它的工作原理是在语料库中的关键字或短语与包含这些关键字或短语的文档之间创建映射。这种映射允许您快速找到包含特定关键字或短语的所有文档，即使语料库非常大。

索引对于各种任务都很有用，例如:

• 搜索信息：您可以使用索引快速找到包含特定关键字或短语的所有文档。这对于研究、客户支持或任何其他需要在大量文本语料库中查找信息的任务都很有用。
• 排序文档：您可以使用索引根据文档与特定查询的相关性对文档进行排序。这对于搜索引擎、推荐系统或任何其他需要对文档进行排序的应用程序都很有用。
• 分析文本：您可以使用索引来分析大量文本的内容。这对于理解文档的情感、识别主题或提取关键字非常有用。

LlamaIndex提供了各种不同的索引类型，每种类型都有自己的优缺点。特定任务的最佳索引类型将取决于任务的特定需求。

Llamaindex提供的结构或组织数据的索引类型:

让我们先了解一些术语。根据Llamaindex的官方文件:

• Node：对应于文档中的一大块文本。LlamaIndex接受Document对象，并在内部将它们解析/块化为Node对象。
• Response Synthesis：你可以认为是一个放置你选择Node的购物车，它会完成合成，然后处理后续的响应。

为了便于理解，我们可以将节点视为大约1k个单词的文本块，而响应合成则是通过查看相关节点(文本块)来给出问题答案(响应)的LLM。这里大家也可以回看我之前的文章《最详细的文本分块(Chunking)方法，直接影响LLM应用效果》。

Llamaindex提供不同类型的索引，以便更好地组织和检索相关信息，并使用Embeddings和LLM高效地运行查询。我们将逐一查看主要Index:

List Index :

List Index是一个简单的数据结构，它将文档存储为节点序列。在索引构建期间，文档文本被分块、转换为节点并存储在一个列表中。这使得它成为检索包含特定关键字或短语的文档的非常有效的索引。

使用列表索引的优点

• 效率：列表索引对于检索包含特定关键字或短语的文档非常有效，这是因为它只需要扫描节点列表来查找与查询匹配的文档。
• 简单：列表索引是非常简单的实现和使用，对于性能很重要，但开发时间有限的项目来说，这是一个很好的选择。
• 灵活性：列表索引可用于任何类型的文档数据，这使得它成为具有各种文档格式的项目的一个很好的选择。

在查询的过程中发生了什么？

在查询期间，如果没有指定其他查询参数，LlamaIndex只是将列表中的所有节点加载到响应合成模块中。

当用户输入关键字或短语时，查询列表索引。然后，索引扫描节点列表以查找包含关键字或短语的文档。然后将匹配查询的文档返回给响应合成模块:

使用List Index的缺点或问题:

• 可伸缩性：对于大型数据集，List Index可能会变得低效，这是因为它需要扫描整个节点列表来查找与查询匹配的文档。

向量存储索引

向量索引是一种将文档文本转化为向量的索引，向量通常是由编码器transformer模型(如Bert等)生成的，它们也被称为Embeddings模型（参考前面关于embedding的文章《Embedding——从入门到生产使用》）。向量表示文本的含义，可以根据用户的查询来查找相关文档。

使用LlamaIndex来创建向量Index是非常简单，可以从文档中直接提取文本建立索引，可以看下面这段代码：

1
2
3
4
5
6
7
8

from llama_index import Document, VectorStoreIndex

text_list = [text1, text2, ...]
documents = [Document(text=t) for t in text_list]

# build index
index = VectorStoreIndex.from_documents(documents)

或者我们也可以从先生成Node，才建立索引，我推荐这种方式，因为后面更好管理：

1
2
3
4
5
6
7
8
9
10
11
12

from llama_index import Document, VectorStoreIndex
from llama_index.node_parser import SimpleNodeParser

text_list = [text1, text2, ...]
documents = [Document(text=t) for t in text_list]

# parse nodes
parser = SimpleNodeParser.from_defaults()
nodes = parser.get_nodes_from_documents(documents)

# build index
index = VectorStoreIndex(nodes)

使用向量索引的优点:

• 向量索引对于查找类似文档非常有效。这是因为向量可以直接进行比较，而无需进行任何文本处理。
• 向量索引扩展相对容易，它们可以用于索引包含数百万甚至数十亿个文档的大型数据集。
• 向量索引创建相对容易，拥有Embedding模型（中文常用的包括m3e、bge等）之后，就可以为文档生成向量，并将它们存储在向量索引中。

我们看看向量索引在查询的时候发生了什么:

• 当您查询向量索引时，您提供一个查询字符串。查询字符串首先由相同的Embedding模型处理以生成向量。
• 然后将向量与索引中所有文档的向量进行匹配，具有最相似（可以设置top_k）向量的文档将作为查询的结果返回。
• 我们还可以定义返回top-k最相似的节点，并将它们传递到我们的响应合成模块。

总的来说，向量索引与传统查询的索引相比，更具备语义属性，可以让我们根据语义来检索，而不仅仅是按关键词匹配等字面意思来搜索。而且向量索引使用高效、可扩展能力强，且易于创建。当然了，它也有不好的一方面，就是如果您使用的不是本地embedding模型，而是使用OpenAI的text-embedding-ada-003、通义千问的embedding模型等，那么是需要成本的，而且量大的话可能很昂贵，即使使用免费的BGE、m3e等本地模型，也是需要一些硬件资源的。对了，说一点开心的，本地的embedding模型的话，我们自己是可以微调训练的，可以参考我之前的文章《手工微调embedding模型》。

TREe Index（树索引）

Tree Index也是一种索引类型，它将文档的文本存储在树状结构中。树中的每个节点表示其子文档的摘要。我相信看这篇文章的朋友应该多少都接触过树的数据结构，通过遍历树并查找与查询相关的节点，树索引可用于查找与给定查询相关的文档。

为什么用树？我们通过和数组、链表的比较，使用大学知识简单复习一下树的优点：

• 数组：支持随机访问，进过排序的数组在查找的时候效率极高——O(1)，但是数组的insert、delete等操作需要变动后续的所有元素，复杂度就会变大——O(n)；

• 链表：和数组相反，链表的插入删除等效率极高，只需要将前后连接点打断，插入，再接好，所以时间复杂度一般是O(1)。但是它的查询速度就慢了，需要全部遍历才能找到相应元素，一般时间复杂度是O(n)。当然，链接有很多变种，比如散列链表的查询复杂度也是可以做到O(1)的；

• 树：树结构算是一个折中吧，特别是二叉树，它的查询和操作（插入、删除等）的复杂度都是O(logn)。二分法的威力就是n越大，它的上升曲线会越来越平缓。比如一组有序数字的猜大小的游戏中，8个数字（n=8），只要猜3次；32个数字猜5次，但是1024个数字也只需要10次。且很关键的一点，二叉树的效率非常稳定，这一点在开发中对于性能的可预估性非常重要。

使用树索引的优点:

• 树索引对于查找相关文档非常有效，这是因为树结构允许索引快速地将搜索范围缩小到可能与查询相关的少量文档。
• 树索引也非常可扩展，它们可以用于索引包含数百万甚至数十亿个文档的大型数据集，不管数据量大小，性能相对稳定。
• 树索引相对容易创建，一旦有了文档，就可以通过手动或自动将文档分组到相关的集群中来创建树形结构。

在查询过程中发生了什么？

• 查询树索引时，需要提供查询字符串。首先处理查询字符串以识别与查询相关的关键字。
• 然后索引遍历树，从根节点开始（也可以是其他地方开始）。在每个节点上，索引检查查询中的关键字是否出现在节点的摘要中。如果是，则索引下降到节点的子节点。如果不是，则索引移动到下一个节点。
• 这个过程一直持续到索引到达一个叶子节点，或者直到它耗尽树中的所有节点。到达的叶节点是最有可能与查询相关的文档。
• 根据原始文档：查询树索引需要从根节点向下遍历到叶节点。默认情况下，(child_branch_factor=1)，查询在给定父节点的情况下选择一个子节点。如果child_branch_factor=2，查询将在每个级别选择两个子节点。

使用树索引的缺点:

• 树索引可能比其他类型的索引(如向量索引)更难创建。这是因为需要手动或自动地将文档分组到相关的集群中。
• 树索引在查找与查询“无关”的文档时效率较低（也就是空转的效率较低）。这是因为索引需要遍历整个树，即使查询只与少量文档相关。
• 树索引可能比其他类型的索引更难理解。这是因为树形结构不是人类可以直接解释的。

总的来说，树索引是索引和查询大型文本数据集的强大工具。它们对于查找相关文档非常有效，可伸缩，并且相对容易创建。但是，它们比其他类型的索引更难创建，并且在空转查询时效率较低。

关键词表索引

关键字表索引是一种将文档的关键字存储在表中的索引，我觉得这更加类似Map<k,v>或者字典的结构。表中的每一行代表一个关键字，每一列代表一个文档。通过在表中查找关键字，可以使用表索引来查找包含给定关键字的文档。

使用关键字表索引的优点:

• 关键字表索引对于查找包含特定关键字的文档非常有效，这是因为索引可以快速查找表中的关键字，并找到包含该关键字的所有文档。
• 关键字表索引也非常可扩展，它们可以用于索引包含数百万甚至数十亿个文档的大型数据集。
• 关键字表索引相对容易创建，一旦有了文档，就可以从文档中提取关键字并将其存储在关键字表中。

看看查询的过程:

• 查询关键字表索引时，需要提供关键字。然后索引在表中查找关键字并返回包含该关键字的所有文档。

使用关键字Index的缺点或问题:

• 关键字表索引在查找包含多个关键字的文档时效率较低，这是因为索引需要单独查找表中的每个关键字。
• 关键字表索引对于具有大量关键字的文档可扩展性较差，这是因为表需要更大才能存储所有文档的关键字。
• 对于同义词或相关关键字的文档，关键字表索引可能不太准确，这是因为索引将只返回包含所查询的确切关键字的文档。

总的来说，关键字表索引是索引和查询大型文本数据集的强大工具。它们对于查找包含特定关键字、可伸缩且相对容易创建的文档非常有效。但是，它们在查找包含多个关键字的文档时效率较低，在查找包含大量关键字的文档时可伸缩性较差，在查找包含同义词或相关关键字的文档时准确性较差。

总结

我们讨论了5种类型的索引，它们如何存储数据，在查询时如何工作，以及每种索引的优缺点。因此，您可以根据自己的要求和约束条件选择最适合的Index。有一些高级类型的索引，如知识图谱索引等，后面再单独讲，需要结合知识图谱本身的一些概念。

对LlamaIndex的研究是因为它确实很优秀，很多理念也给了我们极大启发。就像小明说的，他想好好学习LlamaIndex，然后用Java也写一个简化版，因为他要拯救广大面对AI大浪而处于彷徨中的Java程序员，哈哈。

引用

1.Different types of indexes in LlamaIndex to improve your RAG system：https://uttu-parashar.medium.com/different-types-of-indexes-in-llamaindex-to-improve-your-rag-system-fa9c49f40559

2.LlamaIndex官方文档：https://docs.llamaindex.ai/en/stable/core_modules/data_modules/documents_and_nodes/root.html

经过之前一段时间的捣腾，个人感觉我们的RAG应用已经来到了一个全新的层面，在语义理解（相关度）和准确度上都有了长足进步。

但是问题来了。之前和菊厂的业务交流中，对方明确提出一些客户的私有化部署意愿是很明确，主要原因是数据安全。这段时间和一些销售人员、潜在客户交流的时候也收到了类似信息。而我们现在的整套技术栈中，唯一还不能私有化的是LLM。而这也是最终客户最担心的问题——他们的数据被送进云上的公共LLM，不管这些LLM在数据安全上如何申明，对于一些数据就是资产的客户来说依然存在忧虑。所以我们最近就在开始做LLM的本地化测试。

LLM选择标准

在选本地化的LLM之前，我们先根据实际情况定义一些选择标准：

• 归纳优先：我们不需要LLM在各个方面都很优秀，不需要它们会很强的coding和复杂逻辑推理能力，RAG最重要的还是出色的归纳能力；
• 体量考虑：不要太大，最好在13B及以下，因为再大就需要一张A100等专业显卡，或者要多张消费级显卡。我们的目标是一张RTX 4090可以解决问题，对很多客户来说，A卡很难买，而且价格太高了；
• 中文能力：我们主要面对的还是中文业务，所以Llama对我们还是成本太高，如果自己做大量训练的话。

大模型试用选择

定义了选择标准之后，我们就来实际试用了。待选的其实也不多，我们自己有一个全量训练的BLOOM-7B，然后另外两个待选是ChatGLM2-6B和Baichuan2-13B。如果您还有其他更好的选择，可以私信我，哈。

试用自训练的BLOOM-7B

部署在公司内网的自训练BLOOM-7B是今年3月份就训练好的，当时也算是走在比较前面的，至少在我们文旅数字化行业，好像当时是没有的。BLOOM-7B在问答方面能力还是可以的，在文旅方面因为有我们自己多年的语料沉淀，在我们覆盖的客户景区的问答上，在当时效果超过ChatGPT。

但是，接入到RAG之后，发现归纳能力不太行。而且近期因为新的开源大模型出来很多，所以暂时也没有打算再去优化这个7B的大模型。所以，首先试用和淘汰的就是我们自己训练的BLOOM-7B，这个行业，真的一日千里啊，3月份训练的大模型，当时是小甜甜，现在已经是牛夫人了。

试用ChatGLM2-6B

目前我们使用的是智谱的标准版（API，在线版），效果应该说很棒，所以我们首先想到的是ChatGLM2-6B的开源版本。

ChatGLM2-6B因为已经有商业许可，所以两个月前就做了部署，把AutoModel.from_pretrained的指向从本地改成Hugging Face的模型地址让它更新到最新版本，然后接上我们的RAG做测试。说实话，使用同样的Prompt，ChatGLM2-6B的归纳能力只能说是复读机级别的(⊙o⊙)。LLM的归纳能力，太简单了可以通过Prompt优化改成复杂的，但是已经让它按最简单的方式去归纳了，依然是复读机的结果，那就不适用了。

因为ChatGLM2目前开放的就是6B和130B两个版本，但是130B的对于我们来说已经远超定义的选择范围，所以就放弃ChatGLM2了。

试用Baichuan2-13B

百川大模型选型

百川大模型是我们一个在老牌中厂的小伙伴给我们推荐的，据说他们内部已经在实用，而且效果不错，于是我就开始转向Baichuan2-13B。

我们首先选择的是13B，因为7B/6B这个级别的我们上面已经试用了，在技术层面没有碾压式的升级之前，参数体量有时候就决定了能力。对于Base和Chat，因为我们现在更多考察的还是归纳能力，所以为了方面考虑，选择了Chat版本。所以目前选择的就是Baichuan2-13B-Chat。

接下来就是考虑量化版本，官方给出了资源表：

按一张RTX 4090（24GB）来算的话，最佳的应该是Baichuan2-13B的8bits版本。但是官方只提供了fp16和4bits两个版本，唯独没有8bits量化版本。

安装和运行fp16版本

我的做法是先部署fp16，先试试效果呗。

第一步是git clone代码，然后在Hugging Face上，models的过程是比较痛苦的，三个bin文件近28GB，最近几个月我发现直接下载（wget）总是无法成功，而我的Ubuntu服务器是没有科学上网的。所以只能在家里的Mac上先下载，直到今天凌晨2点才完成（好困~），然后传到Ubuntu上。

先用fp16先安装，把cli_demo.py里面的model地址改成本地的，这样不用每次运行的时候都会查询并下载最新版权重文件，主要是等待时间太长了。

cli_demo.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

print("init model ...")
    model = AutoModelForCausalLM.from_pretrained(
        "baichuan-inc/Baichuan2-13B-Chat",  // 这里改成你自己的本地模型地址
        torch_dtype=torch.float16,
        device_map="auto",
        trust_remote_code=True
    )
    model.generation_config = GenerationConfig.from_pretrained(
        "baichuan-inc/Baichuan2-13B-Chat" // 这里改成你自己的本地模型地址
    )
    tokenizer = AutoTokenizer.from_pretrained(
        "baichuan-inc/Baichuan2-13B-Chat", // 这里改成你自己的本地模型地址
        use_fast=False,
        trust_remote_code=True
    )

运行程序：

1

python cli_demo.py

居然跑起来了，但是，推理的速度跟乌龟爬一样慢！

两个回合之后，直接就OutOfMemoryError了。

手工量化int8

那现在只能把fp16量化为8bits，还好，官网有提到量化的方法。

我们需要先安装两个lib：

1
2
3

pip install xformers

conda install bitsandbytes  //也可以使用pip

然后在原来的models平级目录mkdir一个models_8，然后我用了一个比较偷懒的做法，直接把cli_demo.py复制为quan8.py。

下面修改这个新复制的quan8.py。

quan8.py

1
2
3
4
5
6
7
8
9
10
11
12
13

def init_model():
    print("quant8int model ...")
    model = AutoModelForCausalLM.from_pretrained(
        "/home/tumeng/llm/Baichuan2/models",
        load_in_8bit=True,
        device_map="auto",
        trust_remote_code=True
    )
    model.save_pretrained(
        "/home/tumeng/llm/Baichuan2/models_8"
    )

    return model

我是比较偷懒的方式，因为当时太困了！

其他的代码我不管（运行的时候会报错，但不影响），就修改了init_model()函数。AutoModelForCausalLM.from_pretrained里面的第一个参数是原权重文件，save_pretrained里面是量化出来的int8权重文件保存的目录。

运行成功

再次修改cli_demo.py，将model指向到int8的模型

cli_demo.py

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

def init_model():
    print("init model ...")
    model = AutoModelForCausalLM.from_pretrained(
        "/home/tumeng/llm/Baichuan2/models_8",
        torch_dtype=torch.float16,
        device_map="auto",
        trust_remote_code=True
    )
    model.generation_config = GenerationConfig.from_pretrained(
        "/home/tumeng/llm/Baichuan2/models_8"
    )
    tokenizer = AutoTokenizer.from_pretrained(
        "/home/tumeng/llm/Baichuan2/models_8",
        use_fast=False,
        trust_remote_code=True
    )
    return model, tokenizer

再次运行cli_demp.py，这次运行成功了，而且推理速度满足要求，棒！

然后就到了检验Baichuan2-13B的归纳能力的时候了，我直接复制了小明给我的Prompt。

速度、归纳效果，都还可以！那私有化，暂时就先选型Baichuan2-13B了。

对了，其实Baichuan2-13B的逻辑能力是有短板的，我经常用的一道测试题，它答得不好。

结论

这次大模型的选型测试主要还是为了私有化的需要，如果没有私有化（甚至完全断网）需求的话，个人感觉智谱的API还是挺好用的。本次选择除了最开始定义的三个过滤条件外，其实还有一个就是可商用，ChatGLM2-6B、BLOOM-7B和Baichuan2-13B都是符合这一条件的。