在本文结束时，您将更好地了解人工智能代理在使复杂任务更易于管理并从各种信息源中释放有价值的见解方面的巨大潜力。如果文章太长，下面是最终架构的预览：
我已经实现了一个带有问题语义搜索的基本聊天机器人，它本质上允许应用程序与特定的文本片段进行对话。您可以在这里查看有用的OpenAI 教程！它出奇地好——我可以与一大段文字谈论它的任何细节！
但问题是……如何才能与多段文本对话？假设你有五本书，并且你有一个问题。你是否向每本“书”问同样的问题，而其中四本却独立地告诉你“我不知道”？这听起来很乏味。
如果有一个问题涉及您收藏中的多本书，并且您想要一个连贯的答案怎么办？目前，我的简单应用程序一次只能与一个知识库交互。因此，询问每一本书都会给我独立的答案，彼此独立！
这里出现的另一个问题是……如果你有很多书怎么办？根据您提出的问题，您如何知道哪些书是相关的？你不能只是为每本书进行用户/人工智能交换。服务器调用太多了。
所以我们的想法是……如何提出一个可能与多个知识库相关的问题并得到一个答案？这可能吗？
让我们看一下下图中基本语义搜索应用的体系结构。
在这里，用户需要有两个输入：问题本身和要询问的相关知识库的名称。这意味着，除了有一个一般性问题之外，您还需要知道哪个知识库可能包含相关信息！如果你知道，那就太好了！但如果您不这样做，那么在不知道要研究哪个知识库的情况下简单地问一个问题不是很好吗？
选择器逻辑非常简单。命名空间与包含文本语料库的“矢量化”版本的数据库相关联。这实质上告诉代码要对哪个数据库执行语义搜索。
但是，如果我们可以根据问题本身“推断”名称空间呢？这可能吗？这听起来很难实现。幸运的是，我们可能有一种方法可以将这项艰苦的工作委托给人工智能！
只需将所有知识库合并在一起，为什么要对它们进行分区？
通常情况下，信息会根据一些共同的主题自然地进行分区。合并所有知识库并对它们执行语义搜索以提供适当的上下文可能有效，也可能无效。这里的问题是，当你把它们全部合并成一个团块时，你的上下文一开始就失去了关于它们被划分的特定主题的连贯性。这意味着，当您将混合上下文提供给大型语言模型 （LLM） 并要求它对其进行总结时，它将为您提供不连贯的输出。没有人想要那样 ?
AI 代理是什么意思？我们可以将这些大型语言模型视为函数，而不是将它们视为聊天机器人！他们有一个输入和一个输出！让我们用一个简单的例子来说明这个概念。
想象一下你有一个addTwoNumbers函数。我们期望它看起来像这样：
const addTwoNumbers = (a, b) => {return a + b}
很简单。但是，如果我们这样做呢？
const addTwoNumebers = async (a, b) => {const aiAgent = new openai("As a calculator agent...")return (await aiAgent.chat(`add ${a} + ${b}`)).toNumber()}
这似乎有点小题大做，但这个示例很好的讲述了这个概念。我们没有为函数编写逻辑;我们只是向 AI 提示提供了几条信息：
system prompt - "As a calculator agent..."
question - "add a and b"
回想一下，我们想委托复杂的逻辑来选择哪些命名空间被赋予一个问 题。我们可以把这个任务交给人工智能！
用 AI 代理替换选择器逻辑！
在上图中，我们可以看到选择器逻辑被人工智能代理取代了！
此时，selector agent系统会提示用户根据输入的消息选择相关的知识库。代理收到一个knowledgebaseConstant，它是每个知识库的信息摘要的集合。通常，您也希望在此处放置知识库的重要关键字，以帮助您selector agent随后选择知识库进行搜索。
由此，您将选择合适的知识库的艰苦工作委托给大型语言模型。想象一下有几百个知识库。只要您能提供其域名的合理摘要，selector agent应该能够直接应付的了！
我向代理提供的原始系统提示如下所示！
const systemPrompt = `You are a selection agent that determines the relevance of knowledge bases to a given question.You will be given a list of knowledge bases, each with a unique namespace and a short description of the type of information they contain.For each question, you will select the relevant knowledge bases based on the keywords, entities, or other relevant criteria. You will then return a list of namespaces that you think are relevant to the question. If you think none of the knowledge bases are relevant, you will return an empty list.Here are the relevant knowledge bases:Knowledge Bases:${namespaceDescriptionMap.map((obj) => {return `- Namespace: "${obj.namespace}"\\\\n Description: "${obj.description}"`;}).join("\\\\n")}Your response should give me a list of the relvant namespaces ONLY.`;
现在让我们看看下图中的新架构！
更多代理！让我们简单介绍一下它们。
在上图中，如果选择器代理认为特定知识库是相关的，则对向量数据库执行语义搜索，然后我们得到实际的相关文本。然后，除了用户给出的原始问题外，该文本还提供给摘要代理。
然后，这些摘要代理将语义搜索中提取的文本片段与原始问题输入进行汇总，就好像代理本身在回答问题一样！
如上图所示，除了用户本身的输入问题外，此最终代理还接收所有已激活的摘要器代理的所有摘要。此代理的输出是返回给用户的信息！
瞧！现在我们创建了一个应用程序，可以提出有关多个主题的问题并提供引用多个知识库的答案！
这仍然是一个“简单”的问答聊天机器人，因为它不会记住您的对话历史记录。为了改变这一点，我们使用questionRefiner代理和缓存来存储对话历史记录。
请参见下图，它在架构中的位置：
代理questionRefiner被放置在管道的开头，其主要任务是根据缓存中存储的对话历史记录来细化用户的输入问题。它有两个主要输入：
用户输入的问题。
对话历史缓存。
代理questionRefiner使用对话历史记录通过添加上下文或根据之前的交流澄清问题来完善用户输入的问题。然后，这个经过提炼的问题将被传递到selector agent后续管道。
根据您的要求，对话历史记录缓存可以是简单的内存存储或更复杂的数据存储系统。
通过将questionRefiner代理集成到架构中，我们现在拥有更先进的 QnA 聊天机器人，它可以引用多个知识库并记住对话历史记录，从而为用户的查询提供上下文感知响应。
我向代理提供的原始系统提示如下所示！
const constructSystemPrompt = (conversationHistory // : { question: string; answer: string }[]) => {return `As a highly skilled AI, your task is to refine the input question considering the conversation history. Follow these steps:1. Analyze the conversation history, identifying relevant information while ignoring irrelevant parts.2. If all conversation history is irrelevant, just preserve the current question.3. Otherwise, craft a concise and well-structured question that incorporates relevant context from the conversation history.If you can create a more accurate meaningful question, return:- the new questionIf the question is irrelevant or you dont know, preserve the question by returning:- the current questionConversation History:${constructConversationHistoryPrompt(conversationHistory)}`};
结论
我们使用了各种人工智能代理来根据对话历史记录选择器逻辑、摘要、聚合和提炼问题。
一个非常灵活的聊天机器人，可以处理多个知识库的问题，同时跟踪以前交互的上下文。当然，这种架构可能不是万能的解决方案，但它是探索和实验的绝佳起点。另外，它非常简单，可以进行调整和构建，以创建更酷的应用程序！
Github：https://github.com/neebs12/Search-across-knowledge-bases-with-Langchain-and-OpenAI
OpenAI 教程：https://platform.openai.com/docs/tutorials
