以下是关于 AI 搜索工程架构的相关内容：
一、可插拔架构 在整个搜索回答的全流程，有很多节点可以做 Hook 埋点，每个 Hook 可以挂载零至多个插件，多个插件构成了 AI 搜索的可插拔架构。一些常用的功能，可以由 AI 搜索平台自身或第三方创作者抽离成标准插件，用在 AI 搜索主流程或者智能体/工作流等辅助流程。比如，自定义一个思维导图摘要插件，用户可以在搜索的步骤中选择这个自定义插件，实现用思维导图输出搜索结果。
二、提升可玩性 可以预置一个 after_answer 钩子，在大模型回答完用户 query 之后，把请求大模型的上下文信息和大模型的回答内容一起发给第三方插件，第三方插件可以把内容整理成文章/思维导图等格式，再同步到第三方笔记软件。
三、自定义智能体 Agent 智能体一般是对一些自定义操作的封装，用于解决某个场景的某类问题。以 ChatGPT 的 GPTs 举例，一个智能体应用由以下几部分自定义操作组成：
四、提升准确度
五、检索增强生成 (RAG) 以 Sana 的企业搜索用例为例，RAG 过程始于应用程序加载和转换无结构文件，转换为 LLM 可查询格式，文件被“分块”成更小的文本块，并作为向量嵌入和存储在数据库中。当用户提出问题时，系统会检索语义上最相关的上下文块，并将其折叠到“元提示”中，与检索到的信息一起馈送给 LLM，然后 LLM 合成答复返回给用户。在生产中，AI 应用程序具有更复杂的应用程序流程，包含多个检索步骤和提示链，不同类型的任务并行执行，然后将结果综合在一起，以生成最终输出。
[title]工具：我做了一个AI搜索引擎[heading1]ThinkAny是如何冷启动的[heading2]AI搜索如何提升可玩性比如，可以预置一个after_answer钩子，在大模型回答完用户query之后，把请求大模型的上下文信息和大模型的回答内容一起发给第三方插件，第三方插件可以把内容整理成文章/思维导图等格式，再同步到第三方笔记软件。在整个搜索回答的全流程，有很多节点可以做Hook埋点，每个Hook可以挂载零至多个插件，多个插件构成了AI搜索的可插拔架构，这套架构让AI搜索的全流程变得高度可定制，可玩性更高。一些常用的功能，可以由AI搜索平台自身或第三方创作者抽离成标准插件，用在AI搜索主流程或者智能体/工作流等辅助流程。比如，自定义一个思维导图摘要插件，输入内容是一段文本，输出内容是基于toc（table of contents）构成的思维导图。用户可以在搜索的步骤中选择这个自定义插件，实现用思维导图输出搜索结果。1.自定义智能体Agent智能体是现阶段ChatBot类产品经常用到的一种辅助产品形态。智能体一般是对一些自定义操作的封装，用于解决某个场景的某类问题。以ChatGPT()的GPTs举例，一个智能体应用由以下几部分自定义操作组成：提示词：描述智能体的作用，定义智能体的回复格式知识库：上传私有文件作为回答参考外挂API：请求第三方API获取实时数据个性化配置：是否联网/是否使用图片生成/是否使用数据分析等AI搜索的智能体也大体如此，外挂API的操作实际上就是挂载自定义信息源做检索。
[title]工具：我做了一个AI搜索引擎[heading1]ThinkAny是如何冷启动的[heading2]AI搜索如何提升准确度很多的信息源（比如谷歌）返回的检索结果，只包含链接+摘要信息。如果要保证足够的信息密度，免不了要获取链接对应的详情页内容（Read Content）。上一步的Reranking让我们可以选择其中最匹配的top_k条数据，而不至于获取全部内容导致context超限。为了保证获取详情内容的效率，我们需要做一定的并行处理。比如通过goroutine或者python的协程并行读取top_k条链接，在一次请求耗时内拿到top_k条链接的全部内容。获取链接详情内容有很多方案，包括网页爬虫/无头浏览器抓取/第三方Reader读取等。ThinkAny目前使用的是jina.ai的Reader方案。做了一个开关，控制是否获取链接详情，为了保证响应速度，线上的版本暂时未开。1.构建上下文内容池Context Pool提高AI搜索的准确度，上下文的控制也是一个非常重要的手段。比如可以构建一个上下文内容池（Context Pool）=历史搜索结果（Search Results）+历史对话消息（Chat Messages）每次搜索后追问，都带上这个Context Pool做意图识别/问题改写，拿到新的检索结果后更新这个Context Pool，并带上最新的Context Pool内容作为上下文请求大模型回答。Context Pool里的Search Results可以根据链接做去重，Chat Messages可以根据相似度匹配做过滤。需要保证Context Pool的内容有较高的信息密度，同时要控制Context Pool的内容长度，不要超过大模型的context极限。对Context Pool的构建和动态更新，是一个非常有挑战性的事情，如果能做好，对搜索结果的准确度提升也能起到非常大的帮助。1.提示词工程Prompt Engineering
设置基线:RAG是当今大多数现代人工智能应用程序的标准架构。让我们以Sana的企业搜索用例为例,了解它在幕后的工作原理。该过程始于应用程序加载和转换无结构文件(如PDF、幻灯片、文本文件)跨越企业数据孤岛,如Google Drive和Notion,转换为LLM可查询格式,通常通过像[Unstructured](https://menlovc.com/portfolio/unstructured/)*这样的数据预处理引擎进行。这些文件现在被"分块"成更小的文本块,以实现更精确的检索,并作为向量嵌入和存储在像[Pinecone](https://menlovc.com/portfolio/pinecone/)*这样的数据库中。当用户向AI应用程序提出问题时(例如,"总结我与公司X会议的所有笔记")，系统会检索语义上最相关的上下文块，并将其折叠到"元提示"中,与检索到的信息一起馈送给LLM。然后,LLM会从检索到的上下文中合成一个整洁的带有项目符号的答复返回给用户。当然,该图仅说明了一个带有一个LLM调用的单一检索步骤。在生产中,AI应用程序具有更复杂的应用程序流程,包含数十甚至数百个检索步骤。这些应用程序通常具有"提示链",其中一个检索步骤的输入馈送到下一步,并且不同类型的任务并行执行多个"提示链"。然后将结果综合在一起,以生成最终输出。[Eve](https://menlovc.com/portfolio/eve/)*法律研究的共同驾驭员,例如,可能会将针对《第七篇》的研究查询分解为专注于预定子主题的独立提示链,如雇主背景、就业历史、《第七篇》、相关案例法和原告案件支持证据。LLMs然后运行每个提示链,为每个生成中间输出,并综合各输出编写最终备忘录。