在人工智能快速演变的领域中,生成式人工智能,尤其是语言模型机器(LLM),已经成为许多应用的基础,从自然语言处理和机器翻译到虚拟助手和内容生成。GPT-3及其后继产品的出现标志着人工智能发展方面的重要里程碑,开启了一种机器不仅能够理解而且能够以惊人的精准度生成类似人类的文本的时代。然而,在这个人工智能革命的表面下隐藏着一个关键的缺失元素,这个元素有潜力解锁更大的人工智能能力:存储层。
关于LLM的客观真理
让我们通过回顾一下LLM的一些要点来设定背景。以下是过去几年中发生的一些重要事件。
LLMs是有史以来最先进的人工智能系统
LLMs及其衍生作品有潜力为许多行业和研究领域带来革命性的变革。例如,它们可以用于创建更自然和引人入胜的用户界面,开发新的教育工具,并提高机器翻译的准确性。它们还可以用于生成新的想法和洞见,并创造新形式的艺术和文学,这为语言学和语言学领域开辟了一个新的方向。
这些模型在基准测试中超越人类水平的速度比以往任何时候都快:
这些系统自信地撒谎
尽管LLMs非常先进,在大多数情况下几乎不可能区分生成的文本与人类回复,但这些系统会出现各种程度的错觉。换句话说,这些系统自信地撒谎,并且由于生成的熟练程度与人类相当,这些谎言相当令人信服。
考虑与ChatGPT的交互:
乍一看,这些结果似乎令人印象深刻,但一旦你点击链接,就会发现它们都指向了 404 页面。这在多个层面上都存在危险:
1. 首先,由于这些链接看起来很有说服力,人们可能会误以为它们是引用而不进行核实。
2. 最好的情况是你会检查第一个链接,发现它是 404 页面后,你也会检查其他链接。
3. 但最糟糕的情况是只有第一个链接存在,你只检查了那个链接。这会让你相信所有的链接都是有效的。
这只是幻觉的一个例子,还有很多其他更微妙的例子,比如简单地捏造事实。
最强大的LLMs仍然是一个黑盒
就个人而言,我不喜欢将"黑盒"这个词用于所有的深度学习,因为大多数这些模型可以很容易地被剖析和修改。事实上,在大多数情况下,最初发布的模型的修改版本更受欢迎且更有用。解释性一直是一个具有挑战性的问题,但这并不足以将这些模型称为黑盒。但对于LLMs来说情况是不同的。最强大的LLMs是闭源的,只能通过API请求进行访问。此外,由于训练成本高昂和专有数据集的原因,没有足够的资源或工程专业知识来复现结果。这符合黑盒的定义。
基于响应与表示的系统
在基于提示的方法中,你依赖LLMs直接从你(或你的用户)的查询中生成响应。使用LLMs生成响应非常强大,而且很容易上手。但当你意识到你无法控制这些系统的任何方面时,情况很快就变得可怕起来。再加上上面讨论的客观事实,这很快就可能成为一场灾难。
使用LLMs进行表示
使用LLMs来代表我们的知识库怎么样?显而易见的方法是使用这些强大的模型来嵌入我们的数据库。你可以通过它们来获取你的非结构化数据的数值表示,以捕捉语义含义。
这些向量在高维空间中捕捉了实体之间的关系。例如,这是一个词嵌入的例子,其中意思相似的单词彼此靠近。
检索增强生成(RAG)
我们拥有构建RAG系统所需的所有要素。在RAG设置中,我们不再使用LLMs从提示中生成响应,而是使用检索器检索相关的表示,并通过提示LLM形成响应,将它们组合在一起。
现在,你可以提供用于生成响应的知识库文档的准确引用。这使得我们能够追溯响应的来源。
领域的变化
通过RAG,我们在回答问题时减少了对LLM的依赖。相反,我们现在拥有一个模块化的系统,其中有不同的部分,每个部分都可以独立运行:
1. 知识库
2. 嵌入模型
3. 检索器
4. 响应生成器(LLM)
这导致了领域的变化,我们从依赖黑盒人工智能转变为由几十年研究支持的模块化组件。
“只要它不好用,就是人工智能;一旦好用了,就是计算机科学。”
总体思路是,我们现在已经改变了问题的领域,检索器成为系统的核心,并且我们现在可以利用计算机科学子领域(例如信息检索、排名等)的研究工作。
听起来我需要花费大量金钱吗?
成本取决于很多因素。现在让我们把注意力转向部署的机器学习系统常见问题,以及这种生成式人工智能方法如何解决这些问题。
1. 可解释性——目前没有一种可靠地解释深度神经网络的方法,但这是一个活跃的研究领域。解释LLMs更加困难。但在RAG的设置中,你可以逐步构建响应,从而获得有关决策原因的洞察。
2. 模块化——与端到端的API可访问模型相比,模块化系统有很多优点。在我们的情况下,我们可以对知识库中的内容进行细粒度控制,并随着时间的推移进行更新,可以配置检索器和排名算法,以及选择将哪些模型用于生成最终响应的信息。
3. 重新训练成本——LLMs(包括本地模型)的最大问题是庞大的数据和基础设施要求。这几乎不可能在有新数据进来时重新训练它们。
例如,让我们考虑一个在训练完成后发生的最新事件的例子(或者更具体地说,数据集的截止日期)。以下是一些关于几天前或几个月前发生的事件的问题,向ChatGPT提问。
对于LLM进行微调的商业子领域中的信息变化速度可能会更快,使得这些模型很快过时。
如果相同的系统依赖于RAG系统,它只需要更新知识库,即通过嵌入模型运行新的事件/信息,其余部分由检索器处理。另一方面,在基于直接响应的系统中,LLM需要重新训练以适应新数据。
因此,事实证明,这种方法不仅提供了更精细的控制和模块化,而且在新信息到来时更新成本更低。
微调与RAG之间的比较
关于在特定领域的数据上微调模型和使用通用模型进行RAG哪种更好的辩论是毫无意义的。当然,在理想情况下,你希望两者兼具。一个对领域具有更好上下文理解的微调模型将提供更好的“通用”响应和上下文词汇。但你需要一个RAG模型来更好地控制和解释响应。
AI本地数据库的需求
现在,很明显需要一个维护良好的知识库。尽管有许多传统的解决方案,但我们需要重新思考这些解决方案以适应人工智能解决方案。以下是主要要求:
1. AI需要大量的数据
2. 模型正在变得多模态。数据需要跟进。
3. 扩展不应该让财务陷入困境。
多模态是下一个前沿,大多数LLM提供商已经计划支持多模态功能,或者正在测试它们。
在考虑到我们不需要在机器学习中再发明另一个子领域的情况下,利用现有工具和接口将是理想的选择。
LanceDB:AI本地的、多模态的、嵌入向量数据库
LanceDB是一个基于持久存储的用于向量搜索的开源数据库,它极大地简化了嵌入向量的检索、过滤和管理。
np.array - OG 向量数据库
关于是否需要向量数据库以及np.array是否足够进行所有向量搜索操作,存在着持续的辩论。
让我们看一个使用np.array来存储向量并查找相似向量的例子。
import numpy as np
import pandas as pd
embeddings = []
ids = []
for i, item in enumerate(data):
embeddings.append(embedding_model(item))
ids.append(i)
df = pd.DataFrame({"id": ids, "embedding": embeddings})
df.to_pickle("./dummy.pkl")
...
df = pd.read_pickle("./dummy.pkl")
embeddings, ids = df["embedding"].to_numpy(), df["id"]
sim = cosine_sim(embeddings[0], embeddings[1])
...
这对于快速原型设计非常有用,但是如何在百万条记录的规模下进行扩展呢?那么在十亿级别下呢?将所有嵌入向量加载到内存中是否在大规模情况下具有高效性?多模态数据又如何处理?
针对AI本地向量数据库的理想解决方案应该是易于设置,并且可以与现有的API进行集成,以便进行快速原型设计,但也能够在无需额外改动的情况下进行扩展。
LanceDB正是采用了这种方法进行设计。它是一个无服务器的解决方案,无需进行设置,只需导入并开始使用。它将数据持久化存储在硬盘中,使得计算和存储可以分离,因此可以在不加载整个数据集到内存中的情况下运行操作。它与Python和Javascript生态系统进行本地集成,可以从相同的代码库中将原型扩展到生产应用中。
计算存储分离
计算存储分离是一种将计算和存储资源在系统中解耦的设计模式。这意味着计算资源不位于与存储资源相同的物理硬件上。计算存储分离有多个好处,包括可扩展性、性能和成本效益。
LanceDB - 嵌入式向量数据库
以下是如何将上面的示例与LanceDB集成:
db = lancedb.connect("db")
embeddings = []
ids = []
for i, item in enumerate(data):
embeddings.append(embedding_model(item))
ids.append(i)
df = pd.DataFrame({"id": ids, "embedding": embeddings})
tbl = db.create_table("tbl", data=df)
...
tbl = db.open_table("tbl")
sim = tbl.search(embedding_model(data)).metric("cosine").to_pandas()
这是你为任何规模打造强大的向量嵌入工作流所需的所有步骤。LanceDB是基于Lance文件格式构建的,它是一个现代的列式数据格式,用于ML和LLMs,并使用Rust实现。