与知识库对话

以下是关于 AI 搜索工程架构的相关内容：一、可插拔架构在整个搜索回答的全流程，有很多节点可以做 Hook 埋点，每个 Hook 可以挂载零至多个插件，多个插件构成了 AI 搜索的可插拔架构。一些常用的功能，可以由 AI 搜索平台自身或第三方创作者抽离成标准插件，用在 AI 搜索主流程或者智能体/工作流等辅助流程。比如，自定义一个思维导图摘要插件，用户可以在搜索的步骤中选择这个自定义插件，实现用思维导图输出搜索结果。二、提升可玩性可以预置一个 after_answer 钩子，在大模型回答完用户 query 之后，把请求大模型的上下文信息和大模型的回答内容一起发给第三方插件，第三方插件可以把内容整理成文章/思维导图等格式，再同步到第三方笔记软件。三、自定义智能体 Agent 智能体一般是对一些自定义操作的封装，用于解决某个场景的某类问题。以 ChatGPT 的 GPTs 举例，一个智能体应用由以下几部分自定义操作组成： 1. 提示词：描述智能体的作用，定义智能体的回复格式。 2. 知识库：上传私有文件作为回答参考。 3. 外挂 API：请求第三方 API 获取实时数据。 4. 个性化配置：是否联网/是否使用图片生成/是否使用数据分析等。四、提升准确度 1. 为获取足够信息密度，需获取链接详情页内容。通过上一步的 Reranking 选择最匹配的 top_k 条数据，避免获取全部内容导致 context 超限。为保证获取详情内容的效率，可做并行处理，如通过 goroutine 或者 python 的协程并行读取 top_k 条链接。获取链接详情内容有多种方案，如网页爬虫、无头浏览器抓取、第三方 Reader 读取等。 2. 构建上下文内容池 Context Pool，将历史搜索结果和历史对话消息组成 Context Pool。每次搜索后追问，都带上这个 Context Pool 做意图识别/问题改写，拿到新的检索结果后更新这个 Context Pool，并带上最新的 Context Pool 内容作为上下文请求大模型回答。需要保证 Context Pool 的内容有较高的信息密度，同时控制其内容长度，不要超过大模型的 context 极限。五、检索增强生成以 Sana 的企业搜索用例为例，RAG 过程始于应用程序加载和转换无结构文件，转换为 LLM 可查询格式，文件被“分块”成更小的文本块，并作为向量嵌入和存储在数据库中。当用户提出问题时，系统会检索语义上最相关的上下文块，并将其折叠到“元提示”中，与检索到的信息一起馈送给 LLM，然后 LLM 合成答复返回给用户。在生产中，AI 应用程序具有更复杂的应用程序流程，包含多个检索步骤和提示链，不同类型的任务并行执行，然后将结果综合在一起，以生成最终输出。