关于人工智能:LLMs-诸神之战LangChain-以奥德赛之名

4次阅读

共计 3385 个字符，预计需要花费 9 分钟才能阅读完成。

LLMs 一出，谁与争锋？

毫无疑问，大语言模型（LLM）掀起了新一轮的技术浪潮，成为寰球各科技公司争相布局的畛域。诚然，技术浪潮源起于 ChatGPT，不过要提及 LLMs 的技术倒退的低潮，谷歌、微软等巨头在其中的作用不可漠视，它们早早地踏入 AI 的技术角斗场中，频频出招，势要在战斗中一争高下，摘取搜寻之王的桂冠。

而这场大规模的 AI 之战恰好为 LLMs 技术冲破奏响了序曲。LangChain 的退出则成为此番技术演进的新高潮点，它凭借其开源个性及弱小的包容性，成为 LLMs 当之无愧的【奥德赛】。

LLMs 优良的对话能力已是共识，但其内存无限、容易“胡言乱语”也是不争的事实。比方你要问 ChatGPT：“《荒野大镖客：救赎》游戏中设置了几种级别的难度？“，ChatGPT 会自信地答复：”没有难度设置“。但实际上，这个游戏中共设置了 3 种难度级别。LLMs 是依据权重生成答案，因而无奈验证信息的可靠性或提供信息起源。

那么，如何让 LLMs 好好地答复问题并总结数据？如何让 LLMs 提供答案起源？如何让 LLMs 记住 token 限度范畴外的对话？

这个时候，LangChain 就能够大展身手了。LangChain 是一个将不同计算形式、常识与 LLMs 相结合的框架，可进一步施展 LLMs 的理论作用。能够这样了解，只有纯熟应用 LangChain，你就能够搭建业余畛域的聊天机器人和特定的计算 Agent 等。

不过，在 LLMs 变聪慧的过程中，以 Milvus 为代表的向量数据库扮演着怎么的角色呢？或者，咱们把 Milvus 看成 LLMs 的超强记忆外挂更为适合。

LLMs 一次只能解决肯定数量的 token（约 4 个字符），这就意味着 LLMs 无奈剖析长篇文档或文档集。想要解决这个问题，咱们能够将所有文档存储在数据库中，搜寻时仅搜寻与输出问题相干的文档，并将这些文档输出其中，向 LLMs 发问以生成最终答案。

Milvus 向量数据库能够完满地承接这一工作，它能够利用语义搜寻（semantic search）更快地检索到相关性更强的文档。

首先，须要将待剖析的所有文档中的文本转化为 embedding 向量。在这一步中，能够应用原始的 LLMs 生成 embedding 向量，这样不仅操作不便，还能在检索过程中保留 LLMs 的“思维过程”。将所有数据转化成 embedding 向量后，再将这些原始文本的 embedding 向量和原数据存储在 Milvus 中。在查问时，能够用同样的模型将问题转化为 embedding 向量，搜寻相似性高的相干问题，而后将这个相干问题作为发问，输出 LLMs 中并生成答案。

尽管这个流程看起来简略，但实现整个流水线（pipeline）的搭建须要大量工夫和精力。但好消息是，LangChain 可能帮忙咱们轻松实现搭建，并且还为向量数据库提供了向量存储接口（VectorStore Wrapper）。

以下代码集成了 Milvus 和 LangChain：

class VectorStore(ABC):
    """Interface for vector stores."""    @abstractmethoddef add_texts(
        self,
        texts: Iterable[str],
        metadatas: Optional[List[dict]] = None,
kwargs:Any,
    ) ->List[str]:
"""Run more texts through the embeddings and add to the vectorstore."""    @abstractmethoddefsimilarity_search(self, query:str, k:int =4,kwargs: Any) -> List[Document]:
        """Return docs most similar to query."""def max_marginal_relevance_search(self, query: str, k: int = 4, fetch_k: int = 20) -> List[Document]:
        """Return docs selected using the maximal marginal relevance."""raise NotImplementedError

    @classmethod    @abstractmethoddef from_texts(cls: Type[VST],
        texts: List[str],
        embedding: Embeddings,
        metadatas: Optional[List[dict]] = None,
        **kwargs: Any,
    ) -> VST:
        """Return VectorStore initialized from texts and embeddings."""

为了将 Milvus 集成到 LangChain 中，咱们须要实现几个要害函数：add_texts()

、similarity_search()、max_marginal_relevance_search() 和 from_text()。

总体而言 Milvus VectorStore 遵循一个简略的流程。首先它先接管一组文档。在大多数 LLMs 我的项目中，文档是一种数据类，蕴含原始文本和所有相干元数据。文档的元数据通常为 JSON 格局，不便存储在 Milvus 中。VectorStore 会应用你提供的 emebdding 函数将接管到的文档转化为 embedding 向量。在大多数生产零碎中，这些 embedding 函数通常是第三方的 LLMs 服务，如 OpenAI、Cohere 等。当然，如果可能提供一个函数，容许输出文本后返回向量，那也能够应用本人的模型。在 pipeline 的这个步骤中，Milvus 负责接管 embedding、原始文本和元数据，并将它们存储在一个汇合（collection）中。随着汇合中的文档数据越来越多，Milvus 会为所有存储的 embedding 创立索引，从而放慢搜寻的速度。

Pipeline 的最初一步就是检索相干数据。当用户发送一个问题时，文本和用于过滤的元数据被发送到 Milvus VectorStore。Milvus 会应用同样的 embedding 函数将问题转化为 embedding 向量并执行相似性搜寻。Milvus 作为 VectorStore 提供两种类型的搜寻，一种是默认的、依照未修改的程序返回对象，另一种是应用最大边缘相干算法（MMR）排序的搜寻。

不过，将 Milvus 集成到 LangChain 中确实存在一些问题，最次要的是 Milvus 无奈解决 JSON 文件。目前，只有两种解决办法：

在现有的 Milvus collection 上创立一个 VectorStore。

基于上传至 Milvus 的第一个文档创立一个 VectorStore。

Collection schema 在 collection 创立时确定，因而所有后续新增的数据都须要合乎 schema。不合乎 schema 的数据都无奈上传。

同样，如果在 collection 创立后向文档增加了任何新的元数据，这些新增的元数据都将被疏忽。这些毛病不利于零碎实用于多种场景。咱们须要花很多额定精力来清理输出数据和创立新的 collection。不过好消息是，Milvus 2.3 版本行将反对存储 JSON 格局的文件，可能更进一步简化集成工作，感兴趣的敌人能够试用 Milvus 2.3 测试版！

操作进行到这里，咱们便能够搭建出一个 LLMs 知识库。在集成了 Milvus 后，LangChain 还新增了 Retriever，用于连贯内部存储。当然，因为开发工夫较短，本我的项目还有以下优化空间：