Updated 超音数设计思路 (markdown)

超音数设计思路.md

@@ -72,4 +72,11 @@ Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得
 
 ### Chat Plugin
 
-超音数的主链路主要涉及两个步骤：1、LLM解析语义，生成逻辑SQL，提交semantic layer；2、semantic layer生成物理SQL，提交底层OLAP引擎执行。
+超音数的主链路主要涉及两个步骤：1、LLM解析语义，生成逻辑SQL，提交semantic layer；2、semantic layer生成物理SQL，提交底层OLAP引擎执行。但是，既然已经有了统一的ChatBI界面，是否能兼容其他的场景，比如文本知识库、数据看板，它们的执行链路是自定义的。这就是Chat Plugin组件的由来。
+
+当前的设计方案是，三方插件可以通过WebPage或者WebService两种方式来注册，后续会当作是一种工具来使用。当用户输入问题时，如何选择出合适的插件工具？经典的方式有以下两种：
+
+1、**向量召回：**插件在注册时可以设定一些示例问题，提前通过LLM向量化存储到向量数据库。解析输入问题时，将输入文本同样经过LLM向量化后，从向量数据库根据相似度来召回，通过最匹配的示例问题找到相对应的插件；
+2、**函数调用：**插件在注册时可以配置函数名称和描述，利用LLM的function call能力来直接根据输入问题选择函数，并找到对应的插件。
+
+两种方式可以结合使用，优先走向量召回流程，如果相似度没有达到配置的阈值，则继续用函数调用来选择。