本文是一篇英文翻译转载文章，主要介绍了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都是符合这一条件的。

这是一篇翻译稿，主要是觉得作者的这个观点还是有一些启发的。

主要内容：

• RAG-Fusion机制的介绍
• 多查询生成
• 倒数排序融合

RAG现在非常火，当然性能也非常出色，它绝对走在了信息检索技术的康庄大道上，RAG有许多优点:

• 向量搜索融合： RAG通过将向量搜索功能与生成模型集成，引入了一种新的范例。这种融合能够从大型语言模型(大语言模型)生成更丰富、更具上下文感知的输出。
• 减少幻觉： RAG显著降低了LLM的幻觉倾向，使生成的文本更基于数据。
• 个人和专业实用程序：从个人应用程序如筛选笔记到更专业的集成，RAG展示了在提高生产力和内容质量方面的多功能性，同时基于可信赖的数据源。

然而，我发现越来越多的“限制”:

• 当前搜索技术的限制： RAG受到限制我们基于检索的词法和向量搜索技术的相同限制。
• 人工搜索效率低下：人类并不擅长在搜索系统中输入他们想要的东西，比如打字错误、模糊的查询或有限的词汇，这通常会导致错过明显的顶级搜索结果之外的大量信息。虽然RAG有所帮助，但它并没有完全解决这个问题。
• 搜索的过度简化：我们流行的搜索模式将查询线性地映射到答案，缺乏深度来理解人类查询的多维本质。这种线性模型通常无法捕捉更复杂的用户查询的细微差别和上下文，从而导致相关性较低的结果。

那么，我们能做些什么来解决这些问题？我们需要一个系统，它不仅能检索我们的问题，还能掌握我们查询背后的细微差别，而不需要更高级的大语言模型。认识到这些挑战并受到可能性的启发，我开发了一个更精细的解决方案:RAG-Fusion。

为什么使用RAG-Fusion?

• 通过生成多个用户查询和重新排序结果来解决RAG固有的约束。
• 利用倒数排序融合（RRF）和自定义向量评分加权，生成全面准确的结果。

RAG-Fusion希望弥合用户明确提出的问题和他们（原本的意图）打算提出的问题之间的差距，更接近于发现通常仍然隐藏的变革性知识。

深入研究RAG-Fusion的机制

工具和技术栈

RAG Fusion的基本三要素与RAG相似，并在于相同的三个关键技术:

• 一种通用编程语言，通常是Python。
• 一个专用的向量搜索数据库，如Elasticsearch或Pinecone，指导文档检索。
• 一个强大的大型语言模型，如ChatGPT，制作文本。

然而，与RAG不同的是，RAG-Fusion通过几个额外的步骤来区分自己——查询生成和结果的重新排序。

RAG-Fusion’s 工作步骤:

1. 查询语句的相关性复制：通过LLM将用户的查询转换为相似但不同的查询。

2. 并发的向量搜索：对原始查询及其新生成的同级查询执行并发的向量搜索。

3. 智能重新排名：聚合和细化所有结果使用倒数排序融合(RRF)。

4. 最后优中选优：将精心挑选的结果与新查询配对，引导LLM进行有针对性的查询语句输出，考虑所有查询和重新排序的结果列表。

让我们更详细地介绍每一个步骤。

多查询生成

为什么使用多查询?

在传统的搜索系统中，用户经常输入一个单一的查询来查找信息。虽然这种方法很简单，但它有局限性。单个查询可能无法捕获用户感兴趣的全部范围，或者它可能太窄而无法产生全面的结果。这就是从不同角度生成多个查询的地方。

技术实施(Prompt工程)

prompt工程的使用对于生成多个查询至关重要，这些查询不仅与原始查询相似，而且还提供不同的角度或透视图。

下面是它的工作原理:

1. 对语言模型的函数调用:函数调用语言模型(在本例中为chatGPT)。这种方法需要一个特定的指令集(通常被描述为“系统消息”)来指导模型。例如，这里的系统消息指示模型充当“AI助手”。
2. 自然语言查询:然后模型根据原始查询生成多个查询。
3. 多样性和覆盖范围:这些查询不仅仅是随机变化。它们是精心生成的，以提供对原始问题的不同观点。例如，如果最初的查询是关于“气候变化的影响”，生成的查询可能包括“气候变化的经济后果”、“气候变化和公共卫生”等角度。

这种方法确保搜索过程考虑更广泛的信息，从而提高生成的摘要的质量和深度。

倒数排序融合 (RRF)

Why RRF?

倒数排序融合(RRF) 是一种将具有不同相关性指标的多个结果集组合成单个结果集的方法，不同的相关性指标也不必相互关联即可获得高质量的结果。该方法的优势在于不利用相关分数，而仅靠排名计算。相关分数存在的问题在于不同模型的分数范围差。RRF是与滑铁卢大学(CAN)和谷歌(Google)合作开发的(https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)，用其作者的话来说，“比任何单独的系统产生更好的结果，比标准的重新排名方法产生更好的结果”。

在elasticsearch的8.8版本，已经引入了RRF。

通过组合来自不同查询的排名，我们增加了最相关的文档出现在最终列表顶部的机会。RRF特别有效，因为它不依赖于搜索引擎分配的绝对分数，而是依赖于相对排名，这使得它非常适合组合来自可能具有不同分数尺度或分布的查询的结果。

通常，RRF用于混合词法和向量结果。虽然这种方法可以帮助弥补向量搜索在查找特定术语(例如首字母缩写词)时缺乏专一性的不足，但我对结果并不满意，它往往更像是多个结果集的拼凑，因为对于词法和向量搜索的相同查询很少出现相同的结果。

把RRF想象成那种坚持在做决定之前征求每个人意见的人，这种意见是有帮助的，兼听则明，多多益善。

技术实现

函数reciprocal_rank_fusion接受一个搜索结果字典，其中每个键都是一个查询，对应的值是一个文档id列表，按照它们与该查询的相关性排序。然后，RRF算法根据每个文档在不同列表中的排名计算一个新分数，并对它们进行排序，以创建一个最终的重新排名的列表。

在计算融合分数之后，该函数按照分数的降序对文档进行排序，以获得重新排序的最终列表，然后返回该列表。

生成的输出

用户意图保存

使用多个查询的挑战之一是可能会削弱用户的原始意图。为了缓解这种情况，我们指示模型在prompt工程中给予原始查询更多的权重。

技术实现

最后，重新排序的文档和所有查询被馈送到LLM的Prompt中，以典型的RAG方式生成输出，例如请求响应或摘要。

通过对这些技术和技巧进行分层，RAG Fusion提供了一种强大而细致的文本生成方法，它利用最好的搜索技术和生成AI来产生高质量，可靠的输出。

RAG-Fusion优缺点

优势

1、优质的原材料质量

当您使用RAG Fusion时，您的搜索深度不仅仅是“增强”，并且其实搜索范围已经被放大了。相关文档的重新排序意味着你不仅仅是在抓取信息的字面意思，而是在深入这个搜索的意图，所以会涉及到更多的优质文档和待搜索内容。

2、增强用户意图对齐

RAG Fusion的设计理念中包含了自动提示，很多时候我们在搜索的时候并不知道应该怎么描述，像Google、百度就会进行输入框的自动补全提示。RAG Fusion可以捕获用户信息需求的多个方面，从而提供整体输出并与对用户意图进行增强。

3、自动为用户查询输入纠错

该系统不仅可以解释用户的查询，还可以精炼用户的查询。通过生成多个查询变体，RAG Fusion执行隐式拼写和语法检查，从而提高搜索结果的准确性。

4、导航复杂查询（自动分解长句的意图）

人类的语言在表达复杂或专门的思想时往往会结结巴巴。该系统就像一个语言催化剂，生成各种变体，这些变体可能包含更集中、更相关的搜索结果所需的行话或术语。它还可以处理更长的、更复杂的查询，并将它们分解成更小的、可理解的块，用于向量搜索。

5、搜索中的意外发现（关联推荐）

以前在亚马逊买书的时候，总能因为相关推荐发现我更想要的书，RAG Fusion允许这个偶然的发现。通过使用更广泛的查询范围，系统有可能挖掘到信息，而这些信息虽然没有明确搜索，但却成为用户的“啊哈”时刻。这使得RAG Fusion有别于其他传统的搜索模型。

挑战

1、过于啰嗦的风险

RAG-Fusion的深度有时会导致信息泛滥。输出可能会详细到令人难以承受的程度，把RAG-Fusion想象成一个过度解释事物的朋友。

2、可能成本会比较昂贵

多查询输入是需要LLM来做处理的，这时候，很有可能会引起更多的tokens消耗。

最后

好了，最近发了不少关于RAG方面的文章了，下次准备做一个总结，把RAG需要的整个流程，以及对应的文章，都串起来讲一遍。再后面就是讲讲我们在RAG方向上的实际产品和技术案例了。

原文：https://towardsdatascience.com/forget-rag-the-future-is-rag-fusion-1147298d8ad1

本文将讲述从PDF中将表格、图像和纯文本提取出文本信息的完整过程，主要内容：

• PDF的分类：文本型、OCR和扫描型
• 针对不同类型的PDF，我们提取的理论依据
• 环境安装
• 编写提取纯文本的函数
• 编写提取图像中文本的函数
• 编写提取表格的文本内容的函数
• 最后的整合处理

写在前面

随着大型语言模型(LLM)的应用不断发展，从简单的文本摘要和翻译，到基于情绪和财务报告主题预测股票表现，再到复杂的检索（如RAG），都需要我们首先从真实世界提取文本数据。

有许多类型的文档共享这种非结构化信息，从网络文章、博客文章到手写信件和图表。然而，这些文本数据的很大一部分是以PDF格式存储和传输的（我们做的更极端，即使原先不是PDF，一般也会先把文字进行处理好，转换为PDF）。

因此，从PDF文档中提取信息，是很多类似RAG这样的应用第一步要处理的事情，在这个环节，我们需要做好三件事：

• 提取出来的文本要保持信息完整性，也就是准确性；
• 提出的结果需要有附加信息，也就是要保存元数据；
• 提取过程要完成自动化，也就是流程化。

然而，在我们开始之前，我们需要指定目前不同类型的pdf，更具体地说，是出现最频繁的三种:

1. 机器生成的pdf文件：这些pdf文件是在计算机上使用W3C技术(如HTML、CSS和Javascript)或其他软件(如Adobe Acrobat、Word或Typora等MarkDown工具)创建的。这种类型的文件可以包含各种组件，例如图像、文本和链接，这些组件都是可以被选中、搜索和易于编辑的。
2. 传统扫描文档：这些PDF文件是通过扫描仪、手机是的扫描王这样的APP从实物上扫描创建的。这些文件只不过是存储在PDF文件中的图像集合。也就是说，出现在这些图像中的元素，如文本或链接是不能被选择或搜索的。本质上，PDF只是这些图像的容器而已。
3. 带OCR的扫描文档：这种类似有点特殊，在扫描文档后，使用光学字符识别(OCR)软件识别文件中每个图像中的文本，将其转换为可搜索和可编辑的文本。然后软件会在图像上添加一个带有实际文本的图层，这样你就可以在浏览文件时选择它作为一个单独的组件。但是有时候我们不能完全信任OCR，因为它还是存在一定几率的识别错误的。

另外还有一种情况是，尽管现在越来越多的机器安装了OCR系统，可以识别扫描文档中的文本，但仍然有一些文档以图像格式包含整页。当你读到一篇很棒的文章时，你想选中一个句子，但却选择了整个页面。这可能是由于特定OCR程序的限制或OCR根本就可有介入。为了避免在最终本文提取的时候遗漏这些“看上去像文本的图片”，我在创建过程中需要考虑做一些处理。

理论方法

考虑到所有上面说的几种不同类型的PDF文件格式，对PDF的布局进行初步分析以确定每个组件所需的适当工具就很重要了。

更具体地说，根据此分析的结果，我们将应用适当的方法从PDF中提取文本，无论是在具有元数据的语料库块中呈现的文本、图像中的文本还是表格中的结构化文本。在没有OCR的扫描文档中，从图像中识别和提取文本将非常繁重。此过程的输出将是一个Python字典（dictionary），其中包含为PDF文件的每个页面提取的信息。该字典（dictionary）中的每个键将表示文档的页码，其对应的值将是一个列表，其中包含以下5个嵌套列表:

1. 从语料库中每个文本块提取的文本
2. 每个文本块中文本的格式，包括font-family和font-size
3. 从页面中的图像上提取的文本
4. 以结构化格式从表格中提取的文本
5. 页面的完整文本内容

这样，我们可以实现对每个PDF组件提取的文本的更合乎逻辑的分离，并且有时可以帮助我们更容易地检索通常出现在特定组件中的信息(例如，LOGO中的公司名称、表格中各数据的对应关系)。此外，从文本中提取的元数据，如font-family和font-size，可以用来轻松地识别文本标题或高亮的重要文本，这将帮助我们进一步分离，或者在多个不同的块中对文本进行合并、排序等后续处理。最后，以LLM能够理解的方式保留结构化表信息将显著提高对提取数据中关系的推理质量。然后，这些信息可以在最终输出的时候保留它原本的格式。

您可以在下面的图片中看到这种方法的流程图。

安装所需的库

在我们开始使用PDF文本提取之前，应该安装必要的库。机器上首先需要安装Python 3.10或更高版本。你也可以安装最新的Anaconda，我装的就是它。

PyPDF2：从存储路径读取PDF文件。

1

pip install PyPDF2

Pdfminer ：执行布局分析并从PDF中提取文本和格式。(.six版本的库是支持Python 3的版本)

1

pip install pdfminer.six

Pdfplumber： 识别PDF页面中的table并从中提取信息。

1

pip install pdfplumber

Pdf2image：将裁剪后的PDF图像转换为PNG图像。

1

pip install pdf2image

PIL： 读取PNG图像。

1

pip install Pillow

Pytesseract： 从图像中提取文本使用OCR技术

这个安装起来有点棘手，因为首先，您需要安装Google Tesseract OCR（链接在文章底部引用区），这是一个基于LSTM模型的OCR机器，用于识别行识别和字符模式。

如果你是Mac用户，你可以在你的终端上通过Brew安装它，这样就可以了。

1

brew install tesseract

对于Windows用户，可以参照以下步骤进行安装(https://linuxhint.com/install-tesseract-windows/)。安装软件后，需要将它们的可执行文件路径添加到计算机上的环境变量中。或者，也可以运行以下命令，使用以下代码直接将其路径包含在Python脚本中：

1

pytesseract.pytesseract.tesseract_cmd = r'C:\Program Files\Tesseract-OCR\tesseract.exe'

然后就可以安装Python库了

1

pip install pytesseract

最后，我们将在程序中导入所有库：

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

# 读取PDF
import PyPDF2
# 分析PDF的layout，提取文本
from pdfminer.high_level import extract_pages, extract_text
from pdfminer.layout import LTTextContainer, LTChar, LTRect, LTFigure
# 从PDF的表格中提取文本
import pdfplumber
# 从PDF中提取图片
from PIL import Image
from pdf2image import convert_from_path
# 运行OCR从图片中提取文本
import pytesseract 
# 清除过程中的各种过程文件
import os

现在我们都准备好了，让我们来试一下这些库怎么样。

文档的布局（Layout）分析

对于初步分析，我们使用PDFMiner的Python库将文档对象中的文本分离为多个页面对象，然后分解并检查每个页面的布局。PDF文件本身缺乏结构化信息，如我们可以一眼识别的段落、句子或单词等。相反，它们只理解文本中的单个字符及其在页面上的位置。通过这种方式，PDFMiner尝试将页面的内容重构为单个字符及其在文件中的位置。然后，通过比较这些字符与其他字符的距离，它组成适当的单词、句子、行和文本段落。为了实现这一点，PDFMiner使用高级函数extract_pages()从PDF文件中分离各个页面，并将它们转换为LTPage对象。

然后，对于每个LTPage对象，它从上到下遍历每个元素，并尝试将适当的组件识别为:

• LTFigure：表示PDF中页面上的图形或图像的区域。
• LTTextContainer：代表一个矩形区域（段落）中的一组文本行（line），然后进一步分析成LTTextLine对象的列表。它们中的每一个都表示一个LTChar对象列表，这些对象存储文本的单个字符及其元数据。
• LTRect表示一个二维矩形，可用于在LTPage对象中占位区或者Panel，图形或创建表。

因此，使用Python对页面进行重构之后，将页面元素分类为LTFigure(图像或图形)、LTTextContainer(文本信息)或LTRect(表格)，我们就可以选择适当的函数来更好地提取内容信息了。

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

for pagenum, page in enumerate(extract_pages(pdf_path)):

    # Iterate the elements that composed a page
    for element in page:

        # Check if the element is a text element
        if isinstance(element, LTTextContainer):
            # Function to extract text from the text block
            pass
            # Function to extract text format
            pass

        # Check the elements for images
        if isinstance(element, LTFigure):
            # Function to convert PDF to Image
            pass
            # Function to extract text with OCR
            pass

        # Check the elements for tables
        if isinstance(element, LTRect):
            # Function to extract table
            pass
            # Function to convert table content into a string
            pass

现在我们了解了流程的结构原理，接下来我们来创建从不同组件种提取文本所需的函数。

定义从PDF中提取文本的函数

从这里开始，从PDF中提取文本就非常简单了。

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

# 创建一个文本提取函数

def text_extraction(element):
    # 从行元素中提取文本
    line_text = element.get_text()
    
    # 探析文本的格式
    # 用文本行中出现的所有格式初始化列表
    line_formats = []
    for text_line in element:
        if isinstance(text_line, LTTextContainer):
            # 遍历文本行中的每个字符
            for character in text_line:
                if isinstance(character, LTChar):
                    # 追加字符的font-family
                    line_formats.append(character.fontname)
                    # 追加字符的font-size
                    line_formats.append(character.size)
    # 找到行中唯一的字体大小和名称
    format_per_line = list(set(line_formats))
    
    # 返回包含每行文本及其格式的元组
    return (line_text, format_per_line)

因此，要从文本容器中提取文本，我们只需使用LTTextContainer元素的get_text()方法。此方法检索构成特定语料库框中单词的所有字符，并将输出存储在文本数据列表中。此列表中的每个元素表示容器中包含的原始文本信息。

现在，为了识别该文本的格式，我们遍历LTTextContainer对象，以单独访问该语料库的每个文本行。在每次迭代中，都会创建一个新的LTTextLine对象，表示该语料库块中的一行文本。然后检查嵌套的line元素是否包含文本。如果是，我们将每个单独的字符元素作为LTChar访问，其中包含该字符的所有元数据。从这个元数据中，我们提取两种类型的格式，并将它们存储在一个单独的列表中，对应于检查的文本:

• 字符的font-family，包括字符是粗体还是斜体
• 字符的font-size

通常，特定文本块中的字符往往具有一致的格式，除非某些字符以粗体突出显示。为了便于进一步分析，我们捕获文本中所有字符的文本格式的唯一值，并将它们存储在适当的列表中。

定义从图像中提取文本的函数

在这里，我认为这是一个更棘手的部分。如何处理在PDF中找到的图像中的文本?

首先，我们需要在这里确定存储在pdf中的图像元素与文件的格式不同，例如JPEG或PNG。这样，为了对它们应用OCR软件，我们需要首先将它们从文件中分离出来，然后将它们转换为图像格式。

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

# 创建一个从pdf中裁剪图像元素的函数
def crop_image(element, pageObj):
    # 获取从PDF中裁剪图像的坐标
    [image_left, image_top, image_right, image_bottom] = [element.x0,element.y0,element.x1,element.y1] 
    # 使用坐标(left, bottom, right, top)裁剪页面
    pageObj.mediabox.lower_left = (image_left, image_bottom)
    pageObj.mediabox.upper_right = (image_right, image_top)
    # 将裁剪后的页面保存为新的PDF
    cropped_pdf_writer = PyPDF2.PdfWriter()
    cropped_pdf_writer.add_page(pageObj)
    # 将裁剪好的PDF保存到一个新文件
    with open('cropped_image.pdf', 'wb') as cropped_pdf_file:
        cropped_pdf_writer.write(cropped_pdf_file)

# 创建一个将PDF内容转换为image的函数
def convert_to_images(input_file,):
    images = convert_from_path(input_file)
    image = images[0]
    output_file = "PDF_image.png"
    image.save(output_file, "PNG")

# 创建从图片中提取文本的函数
def image_to_text(image_path):
    # 读取图片
    img = Image.open(image_path)
    # 从图片中抽取文本
    text = pytesseract.image_to_string(img)
    return text

为此，我们遵循以下流程:

1. 我们使用从PDFMiner检测到的LTFigure对象的元数据来裁剪图像框，利用其在页面布局中的坐标。然后使用PyPDF2库将其保存为新的PDF文件。
2. 然后，我们使用pdf2image库中的convert_from_file()函数将目录中的所有PDF文件转换为图像列表，并以PNG格式保存它们。
3. 最后，现在我们有了图像文件，我们使用PIL模块的image 包在脚本中读取它们，并实现pytesseract的image_to_string()函数，使用tesseract OCR引擎从图像中提取文本。

结果，这个过程返回图像中的文本，然后我们将其保存在输出字典中的第三个列表中。此列表包含从检查页面上的图像中提取的文本信息。

定义从表格中提取文本的函数

在本节中，我们将从PDF页面上的表格中提取更具逻辑结构的文本。这是一个比从语料库中提取文本稍微复杂的任务，因为我们需要考虑信息的粒度和表中呈现的数据点之间形成的关系。

虽然有几个库用于从pdf中提取表数据，其中Tabula-py是最著名的库之一，但我们已经确定了它们在功能上的某些限制。

在我们看来，最明显的问题来自于库在表的文本中使用换行特殊字符\n来标识表的不同行。这在大多数情况下工作得很好，但是当单元格中的文本被包装成2行或更多行时，它无法正确捕获，从而导致添加不必要的空行并丢失提取的单元格的上下文。

当我们尝试使用tabula-py从一个表中提取数据时，你可以看到下面的例子:

然后，提取的信息以Pandas DataFrame而不是字符串的形式输出。在大多数情况下，这可能是一种理想的格式，但是在考虑文本的Transformers的情况下，这些结果需要在输入到模型之前进行转换。

出于这个原因，出于各种原因，我们使用了pdfplumber库来处理这个任务。首先，它是基于pdfminer构建的。我们初步分析时用了六个，也就是说里面有类似的物品。此外，它的表检测方法基于行元素及其交点，这些交点构建包含文本的单元格，然后是表本身。这样，在确定表的单元格之后，我们就可以提取单元格中的内容，而不必携带需要呈现的行数。然后，当我们拥有表的内容时，将其格式化为类似表的字符串，并将其存储在适当的列表中。

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

# 从页面中提取表格内容

def extract_table(pdf_path, page_num, table_num):
    # 打开PDF文件
    pdf = pdfplumber.open(pdf_path)
    # 查找已检查的页面
    table_page = pdf.pages[page_num]
    # 提取适当的表格
    table = table_page.extract_tables()[table_num]
    return table

# 将表格转换为适当的格式
def table_converter(table):
    table_string = ''
    # 遍历表格的每一行
    for row_num in range(len(table)):
        row = table[row_num]
        # 从warp的文字删除线路断路器
        cleaned_row = [item.replace('\n', ' ') if item is not None and '\n' in item else 'None' if item is None else item for item in row]
        # 将表格转换为字符串，注意'|'、'\n'
        table_string+=('|'+'|'.join(cleaned_row)+'|'+'\n')
    # 删除最后一个换行符
    table_string = table_string[:-1]
    return table_string

为了实现这一点，我们创建了两个函数，**extract_table()用于将表的内容提取到一个列表的列表中，table_converter()**用于将这些列表的内容连接到一个类似表的字符串中。

**extract_table()**函数中:

1. 我们打开PDF文件。
2. 我们导航到PDF文件的检查页面。
3. 从pdfplumber在页面上找到的表列表中，我们选择所需的表。
4. 我们提取表的内容，并将其输出到一个嵌套列表的列表中，该列表表示表的每一行。

在**table_converter()**函数:

1. 我们在每个嵌套列表中迭代，并清除其上下文中来自任何换行文本的任何不需要的换行符。
2. 我们通过使用|符号将行中的每个元素分开来连接它们，从而创建表单元格的结构。
3. 最后，我们在末尾添加一个换行符以移动到下一行。

这将产生一个文本字符串，该字符串将显示表的内容，而不会丢失其中显示的数据的粒度。

整合所有文本

现在我们已经准备好了代码的所有组件，让我们将它们全部添加到一个功能齐全的代码中。

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
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

# 查找PDF路径
pdf_path = 'OFFER 3.pdf'

# 创建一个PDF文件对象
pdfFileObj = open(pdf_path, 'rb')
# 创建一个PDF阅读器对象
pdfReaded = PyPDF2.PdfReader(pdfFileObj)

# 创建字典以从每个图像中提取文本
text_per_page = {}
# 我们从PDF中提取页面
for pagenum, page in enumerate(extract_pages(pdf_path)):
    
    # 初始化从页面中提取文本所需的变量
    pageObj = pdfReaded.pages[pagenum]
    page_text = []
    line_format = []
    text_from_images = []
    text_from_tables = []
    page_content = []
    # 初始化检查表的数量
    table_num = 0
    first_element= True
    table_extraction_flag= False
    # 打开pdf文件
    pdf = pdfplumber.open(pdf_path)
    # 查找已检查的页面
    page_tables = pdf.pages[pagenum]
    # 找出本页上的表格数目
    tables = page_tables.find_tables()


    # 找到所有的元素
    page_elements = [(element.y1, element) for element in page._objs]
    # 对页面中出现的所有元素进行排序
    page_elements.sort(key=lambda a: a[0], reverse=True)

    # 查找组成页面的元素
    for i,component in enumerate(page_elements):
        # 提取PDF中元素顶部的位置
        pos= component[0]
        # 提取页面布局的元素
        element = component[1]
        
        # 检查该元素是否为文本元素
        if isinstance(element, LTTextContainer):
            # 检查文本是否出现在表中
            if table_extraction_flag == False:
                # 使用该函数提取每个文本元素的文本和格式
                (line_text, format_per_line) = text_extraction(element)
                # 将每行的文本追加到页文本
                page_text.append(line_text)
                # 附加每一行包含文本的格式
                line_format.append(format_per_line)
                page_content.append(line_text)
            else:
                # 省略表中出现的文本
                pass

        # 检查元素中的图像
        if isinstance(element, LTFigure):
            # 从PDF中裁剪图像
            crop_image(element, pageObj)
            # 将裁剪后的pdf转换为图像
            convert_to_images('cropped_image.pdf')
            # 从图像中提取文本
            image_text = image_to_text('PDF_image.png')
            text_from_images.append(image_text)
            page_content.append(image_text)
            # 在文本和格式列表中添加占位符
            page_text.append('image')
            line_format.append('image')

        # 检查表的元素
        if isinstance(element, LTRect):
            # 如果第一个矩形元素
            if first_element == True and (table_num+1) <= len(tables):
                # 找到表格的边界框
                lower_side = page.bbox[3] - tables[table_num].bbox[3]
                upper_side = element.y1 
                # 从表中提取信息
                table = extract_table(pdf_path, pagenum, table_num)
                # 将表信息转换为结构化字符串格式
                table_string = table_converter(table)
                # 将表字符串追加到列表中
                text_from_tables.append(table_string)
                page_content.append(table_string)
                # 将标志设置为True以再次避免该内容
                table_extraction_flag = True
                # 让它成为另一个元素
                first_element = False
                # 在文本和格式列表中添加占位符
                page_text.append('table')
                line_format.append('table')

            # 检查我们是否已经从页面中提取了表
            if element.y0 >= lower_side and element.y1 <= upper_side:
                pass
            elif not isinstance(page_elements[i+1][1], LTRect):
                table_extraction_flag = False
                first_element = True
                table_num+=1


    # 创建字典的键
    dctkey = 'Page_'+str(pagenum)
    # 将list的列表添加为页键的值
    text_per_page[dctkey]= [page_text, line_format, text_from_images,text_from_tables, page_content]

# 关闭pdf文件对象
pdfFileObj.close()

# 删除已创建的过程文件
os.remove('cropped_image.pdf')
os.remove('PDF_image.png')

# 显示页面内容
result = ''.join(text_per_page['Page_0'][4])
print(result)

上面的脚本将运行：

• 导入必要的库；

• 使用pyPDF2库打开PDF文件；

• 提取PDF的每个页面并重复以下步骤；

• 检查页面上是否有任何表，并使用pdfplumner创建它们的列表；

• 查找页面中嵌套的所有元素，并按照它们在页面布局中出现的顺序对它们进行排序。

然后对于每个元素:

检查它是否是一个文本容器，并且没有出现在表元素中。然后使用text_extraction()函数提取文本及其格式，否则传递该文本。

检查它是否为图像，并使用crop_image()函数从PDF中裁剪图像组件，使用convert_to_images()将其转换为图像文件，并使用image_to_text()函数使用OCR从中提取文本。

检查它是否是一个矩形元素。在这种情况下，我们检查第一个矩形是否是页表的一部分，如果是，我们移动到以下步骤:

1. 查找表的边界框，以便不再使用text_extraction()函数提取其文本。
2. 提取表的内容并将其转换为字符串。
3. 然后添加一个布尔参数来说明我们是从Table中提取文本的。
4. 此过程将在最后一个LTRect落在表的边界框中并且布局中的下一个元素不是矩形对象之后结束。(构成表的所有其他对象都将被传递)

每次迭代的输出将存储在5个列表中，命名为:

1. page_text：包含来自PDF中文本容器的文本(当文本从另一个元素中提取时，将放置占位符)
2. Line_format：包含上面提取的文本的格式(当文本从另一个元素提取时，将放置占位符)
3. Text_from_images：包含从页面上的图像中提取的文本
4. Text_from_tables：包含带有表内容的类表字符串
5. Page_content：以元素列表的形式包含页面上呈现的所有文本

所有的列表将被存储在字典的关键,将代表每次检查页面的数量。

之后，我们将关闭PDF文件。

然后，我们将删除在此过程中创建的所有附加文件。

最后，我们可以通过连接page_content列表的元素来显示页面的内容。

最后

我认为这是一种利用了各种库的最佳特性的方法，使过程能够适应我们可能遇到的各种类型的pdf和元素，但PDFMiner完成了大部分繁重的工作。同时,信息的格式文本可以帮助我们识别潜在的标题文本分离成不同的逻辑部分而不是每个页面内容并可以帮助我们识别文本更重要的。

然而，总是会有更有效的方法来做这个任务，尽管我认为这种方法是更具包容性。

引用

1. https://www.techopedia.com/12-practical-large-language-model-llm-applications
2. https://www.pdfa.org/wp-content/uploads/2018/06/1330_Johnson.pdf
3. https://pdfpro.com/blog/guides/pdf-ocr-guide/#:~:text=OCR technology reads text from, a searchable and editable PDF.
4. https://pdfminersix.readthedocs.io/en/latest/topic/converting_pdf_to_text.html#id1
5. https://github.com/pdfminer/pdfminer.six
6. Google Tesseract OCR：https://github.com/tesseract-ocr/tesseract

Update: 2024-01-26

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

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

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

本文主要内容：

1.为什么目前的市场对独立开发者越来越友好？从三个方面分析：价值导向、付费渠道和AI赋能。

2.独立开发者需要注意哪些事项？5点。

前些天国内的独立开发者圈子可是发生了不少事情：

• OpenAI等国外大模型的接入限制问题；
• APP接下来需要备案；
• 承德remote开发者的罚款问题。

这些事件无一不在国内开发者社区掀起轩然大波，很多人觉得独立开发者时代进入尾声……

但我觉得恰恰相反，从整个经济发展规律来看，接下来应该是独立开发者（或团队）真正迎来蓬勃发展时代。

我的理由是以下几个点：

1. 市场环境变了，将更加面向用户价值；
2. 付费渠道更加完善：
3. AI帮助开发者更容易成为超级个体。

一、市场环境变了

从2022年上半年开始，我们这些在toB/toG市场的从业者就已经可以感受到不一样——市场环境和之前十年已经不一样。到了今年，市场情况的变化已经可以让所有人都感觉到了异常，大多数人都认为“大环境”不好，但我认为这才是一个健康市场的开始。

以往的市场

以我所在的数字文旅行业的发展为例，讲讲前面十年在toG或者toB（大B）行业企业的众生相。这里先申明，是toG/toB行业，toC的逻辑不在这一章节讨论范围。

从1999年开始国家提出西部大发展战略，到后面多年的持续投入，西部整体经济得到了很大发展，而且高速、物流等基础建设已经达到一定水平，下一步就是在西部发展市场和消费。在这个大背景下，旅游行业，特别是景区的发展就非常顺理成章，因为从某种角度上说景区旅游是很简单：发掘地方特色文化价值和山水风光，围起来卖票（实际当然没这么简单）。这个行业绿色环保、解决本地就业、拉动东部富裕消费者到中西部消费。

我进入数字文旅行业是在2015年初，更准确地说当时这个行业是叫做“智慧旅游”，2014年也被称为“智慧旅游元年”。之所以产生这个行业，宏观上说是因为时代发展需要，但是我觉得真正推动这个行业产生的三件事：

• 前面说的中西部大发展，基础设施完成之后需要建立市场和消费，旅游是其中一个很好的切入点；
• 国家在政策层面对智旅行业进行规范化管理，包括2007的首批5A景区评选，对景区的建设和管理运营有了明确监管条例；
• IBM提出“智慧地球”，包括在斯德哥尔摩搞了“智慧城市”，智慧系列席卷全球，所有行业都希望结合数字化降本增效，规范管理。

智慧旅游，从分类上来说属于智慧地球——智慧城市——之下的第三级分类，平行的分类包括智慧医疗、智慧教育、智慧交通等等。到了2016年，这个行业又迎来了新一波刺激——全域旅游。所以现在回顾，从2015年到2021年这段时间，形成整个行业繁荣的因素中，监管、评级等政策性项目建设占比非常大。

具体来说，这一时期很多项目、很多产品都没有充分经历过市场竞争，没有很好达到客户价值。我们行业内有句玩笑话叫“交钥匙工程”，这和房地产行业不一样，这个交钥匙指的是交付完成之后就锁柜子里了，只有在领导视察或者节假日等特殊日子才会打开使用。这一时期如果你从事的是销售、售前工程师或者产品经理，那学习政策是必修课，公司内部也经常会请一些专家来做政策解读。因为研究透了政策，你就知道了钱从哪里（什么政策）来，要怎么样（符合政策方向）把钱赚过来。对于企业来说，顺着这个方向有时候只要做好两件事——搞定关键人决策、搞定专家评审，基本上就把项目拿下了。至于交付的产品是否好用，整体实施是否良好，那并不重要，因为拍板的人并不是使用的人。

这一时期，就好比煤矿不仅有煤，而且还很好挖，他们轻松给你挖好堆放着了，等着你来运（去卖）。

现在的市场

但是就近几年来看，市场环境变化很快。

最显眼的是全球都在经历经济低潮期，国内的地产行业和外贸出口都有下滑，加上城投债等影响，都间接影响到了很多政策性投资——煤矿老板也要自己下场挖煤了，对于卖煤的人（企业）来说，最直接的表象就是今年新增项目量急剧下降。而后续如果要拿到好的单子，企业就不是像以前那样只要搞定几个关键人就可以了，你能帮你的客户赚钱，你的客户才会选择你。也就是说，运煤的人要有能帮助煤矿主一起挖煤的能力，他才能把煤运走。

这看上去很残酷吧，但我觉得这才是健康的商业本质啊！

企业赚取利润的手段就是输出“客户需要的价值”，而你的客户也一样，他们（如果是景区）也是给游客提供价值才能收益的，所以你要体现价值，最好就是帮助你的客户赚钱，让你客户的客户感受到你输出的价值。健康的商业模式里，企业需要面向客户价值。只有最终用户——游客觉得有价值，那么企业才能赚到钱，而不是仅仅靠搞定少部分人就把钱赚了。

对于企业来说，也会越来越健康，会将销售和产研做的更加平衡。还记得在多年前，在当时的公司里面，就有销售在公开场合说产品是什么不重要，就是一堆垃圾我也能卖出去。所以那些年，销售天然是比产研“高人一等”的，我深有体会。

面向用户价值

过往的传统企业并不是完全面向用户价值的，说的更直白一些，他们更多是面向领导或者面向投资人。

近一年在独立开发者圈子里混，看到的却是另一番景象：他们的产品体量不大，但在用户需求上非常聚焦，几乎就是专注解决一个用户痛点。这样的产品也就是我认为的面向用户价值的产品。独立开发者不可能搞定一两个决策人就可以将产品卖出去，他们向来是输出用户价值来交换收益的，所以他们天然就是帮客户赚钱（或解决痛点）的人。

在新的时代，独立开发者应该是最不需要悲观的人群。温室里的花朵才需要风调雨顺，野百合没那么依赖春天！

二、付费渠道更加完善

我的记忆中，在App Store出来之前软件开发者收费的渠道是很少的。Windows上各种破解软件，而且最关键的是大家的付费意愿很低，使用破解版好像“天经地义”，难道让我到邮局给开发者汇款吗？

而现在，App Store应该依然是独立开发者最赚钱的收费渠道。但除此之外，很多专业软件的付费渠道也很完善了，国内包括支付宝（小明的knife4j已经接通了支付宝购买）、微信支付和银联支付，国外包括Stripe、PayPal等，都可以为开发者建立完善的收费渠道。SaaS服务也越来越多，

因为收费渠道日趋完善，国内的软件使用者付费意愿也在显著提升。我现在几乎已经没有盗版软件，系统是Mac和Ubuntu，Office用的是398元/年的365版本，连Typora（付费）、IDEA（开源开发者license）和Adobe产品等也都不再是盗版。

在付费机制上，对独立开发者同样是利好！

三、AI赋能超级个体

有个今年新开的播客叫《硬地骇客》，在这方面已经做了很好的总结，大家可以去小宇宙上听听。

下面我就贴一下它上面记录的可以帮助独立开发者成为更强个体的工具和服务，还是免费的：

• Resend: 介绍了Resend作为一个邮件解决方案。
• Paddle: 提到了Paddle作为一个订阅支付方案。
• Unicorn: 提到了Unicorn Platform，适用于制作宣传页面。
• Jamstack: 讨论了Jamstack的概念和生态。
• SupaBase: 介绍了SupaBase作为一个综合解决方案。
• Unicorn: 提到了Unicorn Planform，适用于制作宣传页面。
• 图片: 在讲述营销和设计工具时提到了canva，一个设计SaaS工具。
• Notion: 介绍了Notion作为一个在线文档工具。
• Product Hunt: 提到了Product Hunt作为宣传软文的平台。
• CDN: 讨论了选择CDN服务商的问题。

除此之外，ChatGPT和Copilot在代码层面带来的生产力提升已经无需赘述。Midjourney在产品设计上也帮了我很多忙，在产品思考阶段就帮助我把使用场景给描绘出来了，人家还以为我请了模特拍摄的。

AI和SaaS工具的兴起，使得之前我们需要的很多能力可以通过服务获得，这不是一个独立开发者的好时代吗！

但是我并不是独立开发者的拥趸，一个人可以走的很快，但是一群人才能走的更远。

对于微小规模的团队来说，尽量保证大家是多面手，最简洁的配置应该是这样的：

• 3人：1前端+1后端+1市场
• 3人：1全栈+1产品+1市场
• 2人：最小的配置是1全栈+1产品兼市场。

四、独立开发团队需要注意什么

好了，上面说了为什么现在是独立开发者（团队）的好时代，主要是三点：

• 接下来的市场环境对面向用户价值的开发者会更友好；
• 付费渠道更加完善，用户付费意愿比以前高；
• AI和SaaS帮助开发者补齐能力，更容易成为超级开发者。

但是真正去做一个独立开发者（团队），依然还是困难重重，这里给大家提几点我觉得可以提高成功率的方法。

01 需求向左，技术向右

独立开发者由于团队配置上比较简约，所以很多时候没有一个完善的市场调研、种草和推广团队，也就是说，我们不太可能去做一个全新的产品，然后自己去培育市场，那往往需要大量的市场推广经费。更理智的做法是找到一个已经存在的市场，找到这个市场现有的产品，研究它们的优势与不足，看看是否可以用我们自己对产品的看法，结合新技术，实现对现有市场产品的明显提升。

我虽然不是独立开发者，但是带的也是一个创新团队。我们最近做的新产品就是瞄准了一个已经存在二十多年的市场，结合AI以及我们自己对这个行业用户的理解，创造了一个新的产品。目前从早期市场探索来说，反响非常不错。对我们来说，寻找一个已经存在的市场，就意味着我知道新产品的使用场景是什么（或者创新点可以在哪里体现），客户是谁，盈利模式是怎么样的等等。产品的成功率比我们去做一个全新市场的产品要高很多，毕竟乔布斯只有一个。

02 简洁才是硬道理

如果你的整个产品盈利模式里面，影响因素非常多，那么搞砸的几率也会高很多。比如下面这个公式，我们需要去考虑m、n、3个x和2个y。如此负责的公司带来的危险有两个：

• 因素越多，失败几率越大。如果m或其他的因素为0，那么我们的失败就已经注定；
• 因素越多，我们的精力会越分散，好了，到最后我们每件事情都只能做到60分，竞争力永远处于孱弱状态。

$$
R = mn(x1+x2+x3)* \frac{y1}{y2}
$$

更好的方式是把收益模式做的更简单，虽然只有一个因素是不可能的，但也要做的尽量少，比如两个，就像下面这个公式所示。

$$
R = x*y
$$

大家有没有发现，阿里云、华为云、腾讯云等等，卖的主要产品其实就是“水电”业务——云资源、计算资源等等，收益模式都是很简单的。他们不会直接去做行业领域的项目，要搞定客户，要深耕行业知识，要刺探竞对的动向，要…，这些事情更多是他们的生态合作伙伴去做的。

所以，对于独立开发者（团队）来说，收益模式尽可能简化，是可以给成功多一些机会的。

03 正确心态

做独立开发者的心态很重要，有要服务意识。

不要认为客户在无病呻吟，你的最终目标是帮他们赚钱，然后你分一杯羹，这才是一个长久、正向、健康的生态，也是我们应该有的心态。

另外就是给自己一个限度，可以是一年、两年甚至三个月，做到什么程度，你可以继续，否则就退出。成功往往是需要坚持的，所以最好心里要有准备，坚持打一个一年或两年的硬战。

04 运营：要精细不要花活

运营环节可能是很多开发者没有很深入去思考过的，容易无感，但却很重要，有时候也会很“烦人”。

我的工作给我带来了两个这方面的经历：

• 我有两年的运营总监工作经历，而且有一款到目前已经历经四年的需要运营的产品，我们有完善的运营团队，所以我知道运营对于产品的健康发展有多重要。甚至我们很多后续的业务，也是运营团队争取来的；
• 我负责过年使用人数过千万的应用，以前我分享过一些截图，里面说的是我们的团队经常在凌晨被叫起来，然后紧急忙活。也许你们会认为这是产品设计不够灵活或系统不够稳健引起的，但真实情况是，一旦你的产品年活跃用户过千万，各种突发状况都会发生。也许某一个用户的安卓版手机无法正常使用你的小程序，就会让你疲于应付，而在没遇到他之前，你真的不可能知道这会发生问题。只能说大规模基数之下，什么怪异的情况都可能会发生。

所以，在独立开发者（团队）的产品投放之后，就需要关注运营。哪怕我们把运营缩减为仅仅是客服，如果我们自己没时间，也可以采用AI客服，或者直接找兼职大学生，总之，要把运营当回事儿。

05 去杠杆，做自己擅长的事情

最后一点就是别去做杠杆，咱们要记住自己是手艺人，不是玩资本的（至少不是现在）。我们量力而为，始终记得第一要务是创造用户价值，然后精简团队，不去做杠杆。你服务的是最终用户，而不是投资人。

踏踏实实做产品，服务用户，而不是去疯狂追热点，一会儿O2O，一会儿P2P，一会儿区块链，一会儿元宇宙，这会儿又开始大模型了，但是企业和开发者都有自己的基因属性，能这么随意切换的企业几乎没有，除了玩资本的。

我们还是踏实做好自己擅长的事情，这个社会对于真正能输出用户价值的人肯定会有好的回报的！

面对如今的市场形势，你是去找风口？首先风口不多，然后风停了之后怎么办？我自己的选择是练就自己的翅膀，而不是一味去找风口。