谁能对此感同身受呢？你排了三十分钟的队，终于到了药房柜台。这时技术人员给了你一个坏消息：你的处方不在保险覆盖范围内。你知道上个月换了计划，但你心里想这处方应该被承保的。当你问为什么时，技术人员耸耸肩回答说：“系统没说原因，只是说不行。”你沮丧地走开，知道接下来要在电话里耗上一个小时。心里琢磨着到底要付10美元还是1,000美元。
为什么药房的技术人员不能告诉你处方为何不被承保呢？很可能因为答案被困在两个不同的世界里。你的病史，即你用过什么药、何时使用，以及当前处方的拒付记录，都锁在SQL数据库中。但那个“为什么”——规则、细则以及通用替代方案——却埋在向量数据库里的一份50页的政策手册PDF中。问题在于，这两个系统互不沟通。
这就是“是什么”与“为什么”的对立。“是什么”是SQL表中的硬数据，而“为什么”，即背景、策略，则是非结构化地存在于文档、演示文稿或网页中。在这种情况下，SQL数据库说“拒付”，但原因却在PDF的第14页。这里概述的“是什么”与“为什么”的问题在许多不同行业中都很常见。而在生成式AI爆发之前，我们解决这种问题的能力是有限的。
但如果你的AI能充当数字图书管理员代理呢？它知道何时编写SQL查询以获取精确数值，何时执行语义搜索以找到特定段落，然后将两者结合成单一的有据可依的见解。在构建数字图书管理员代理之前，我们需要规划该代理需要做什么。在这种情况下，我们的数字图书管理员需要进行六个截然不同的步骤。让我们分解一下：第一步是阅读问题。
所以她需要阅读并理解这个问题。第二步，找出“是什么”和“为什么”。基于问题，她需要去查看并确定问题的哪一部分需要在向量数据库中回答，而哪一部分需要在SQL数据库中回答。第三步是构建查询。
一旦她理解了问题并知道哪部分是“是什么”，哪部分是“为什么”，她就需构建实际的查询，以带回她所需的信息或答案。第四步是执行查询。
所以一旦她知道查询是什么，她就需要在数据库中运行它，以获得她正在寻找的答案。第五步是编译。
所以她在向量数据库中有信息，在SQL数据库中也有信息。她需要将这些放在一起，并传递给第六步，在那里她将回答原始问题。那么当她回答问题或经历所有这些步骤时，她会使用什么工具或技术呢？我认为前三个肯定是大型语言模型（LLM）。这两个——这里指的是执行查询和编译信息——更像是工具。
嗯，你知道的，第一个就像是对数据库运行某些操作。这个只是重新格式化来自数据库的信息，可能会用某种Python代码来做。然后下面这个是肯定也要用到LLM的。让我们回到最初的问题：这种药是否被承保，以及为何承保或不承保？
那么该问题的“是什么”部分是：这种药是否被承保？因此，我们的数字图书管理员需要将其识别为“是什么”，并制定SQL查询以获取该信息。这些信息很可能坐在特定数据库的特定行和列中。“为什么”部分是：为何承保或不承保？而这更可能埋在PDF文档的一段文字里。
所以她需要制定搜索策略，以便从向量数据库中检索该信息。那么我们刚才做了什么？我们解决了一个碎片化的体验——一个沮丧的病人和一个困惑的药房技术人员，通过连接“是什么”（SQL表）与“为什么”和PDF。当你从简单查询转向智能体工作流时，你不仅仅是在检索数据。
你在提供答案。你将孤立的数据存储库转变为能按业务速度运行的推理引擎。