第二大脑：将会议记录转化为可查询的知识图谱

解释了代理系统如何从会议记录中提取实体，并将它们存储在Cosmos DB中，从而实现自然语言检索与知识图谱探索。

1390 词

The Problem

Nearly every organization depends on meetings to move work forward — planning discussions, calls with clients, sprint retrospectives, workshops for discovery. Each of these generates a steady flow of decisions, action items, risks, and commitments. And almost without exception, that information simply evaporates afterward.

The transcript gets dropped into a shared drive somewhere. Action items sit in someone's notebook for a while, then fade from memory. Weeks later, someone asks what was actually decided about a particular approach, and nobody can give a clear answer.

This isn't really a storage issue — the data exists somewhere. The real problem is that meeting content is unstructured, scattered across tools, and effectively invisible to any kind of search.

所需的是一种能够大规模处理会议记录、自动提取结构化知识，并允许人们用通俗英语查询这些知识的系统——同时还要构建一个会随着每次会议添加而不断丰富的动态关系图。这个系统被命名为Second Brain。

愿景：每个项目都拥有动态知识图谱

其基本理念很简单。每当有会议记录被上传时，系统就会对其进行分析，确定谁讨论了哪个项目、做出了哪些决策、出现了哪些风险，以及谁负责执行相应的后续行动。所有这些信息都会被存储到Azure Cosmos DB中。之后，你就可以用自然语言提出问题，从而获得带有引用信息的分点式答案。

随着更多转录文本的积累，一个知识图谱会自然而然地形成——这是一个不断发展的网络，将每段记录的对话中的人物、决策、行动和风险相互关联起来。

解决方案界面

该系统提供了一个交互式用户界面，允许用户上传转录文本、浏览提取出的实体、用自然语言提问，并以可视化方式查看生成的知识图谱。

组件详解

1. Extract_Entities_Tool — 并行提取

这个工具承担着核心任务。给定一段原始文本，它会将转录内容按段落分割成多个块，使用ThreadPoolExecutor同时对每个块进行实体提取，然后根据提取的置信度及出现频率为每个唯一值打分，从而整合各块的结果。

定义了七种实体类型，采用管道分隔的格式，以便语言模型能够一致地遵循。

因此，模型会生成类似 "Review architecture | Owner: Archana | Due: Next sprint" 的输出——应用程序可将其解析为结构化的 {task, owner, due} 字典，以便进行详细渲染并在图中建立连接。

领域术语的自主发现

一个重要的设计决策是完全取消 domain_context 输入参数，转而让模型自行发现领域特定的词汇。用于分块提取的每个提示都包含一个专门的部分，要求模型识别文本中出现的领域术语、缩写和系统名称。

2. Text2SQL_CosmosDB_Tool — 用自然语言进行检索

该组件接收用普通英语写成的问题以及描述Cosmos模式的提示，将其转换为Cosmos SQL查询并执行它，最终从结果中生成带引用来源的答案。难点在于Cosmos DB的NoSQL SQL方言不允许直接在数组字段上使用CONTAINS()函数。因此的解决办法是为该工具提供明确的模式提示，说明应如何查询数组。

3. 作为核心的Cosmos DB

这个数据库处于整个系统的核心位置。它并非用作缓存或日志存储——Cosmos DB实际上就是第二大脑，即那个持久化内存层，在其中所有提取出的知识都会被存储、积累并可供查询。

每份会议提取文档都会将每个实体存储两次：一次以字符串的扁平数组形式，便于基于SQL进行查询；另一次则以结构化对象数组的形式，有助于实现详细的界面渲染以及图边的生成。这种重复存储虽会使每份文档的占用空间略有增加，但可以避免数据从数据库返回后在应用层再进行任何解析操作。

大脑类比——两种记忆模式

人类记忆有两种不同的模式：情景记忆，用于记录事件中实际发生的内容；语义记忆，则用于存储一般性事实与定义——比如缩写的含义、某个人的身份。Cosmos数据模型正是为体现这种区分而设计的，它将特定会议的相关情景记录与不断积累的人名、术语及系统的语义词汇表分开存储。

关键工程决策

系统的设计经历了多项刻意的选择，从放弃手动域配置转而采用自动发现机制，到为满足SQL查询和用户界面展示的需求而对实体信息进行冗余存储，再到将大型语言模型的功能严格限制在信息提取与查询生成层面，而不让其负责格式化处理或业务规则制定。

经验总结

Streamlit的重新运行机制要求对状态进行刻意管理。每次点击按钮都会导致整个脚本从开头重新执行。任何需要在多次交互中保持不变的数据，都必须在触发重新运行的按钮被绘制出来之前写入st.session_state，而非之后。
Cosmos DB的SQL方言并非标准的ANSI SQL。CONTAINS()函数仅适用于字符串，不支持数组，因此需要在模式提示中明确说明使用方式——至少要给出一个错误查询写法的示例。

语言模型无法始终可靠地遵循输出格式要求。即便有明确的生成指令，模型有时也会只返回简短的引言句而非完整答案。正因如此，直接从原始数据构建响应的确定性备用方案并非可有可无的优化手段，而是必要的安全保障。

工具应具备明确且有限的职责范围。人们很容易将格式处理逻辑、业务规则或领域知识直接嵌入工具中，但应抵制这种冲动——一个工具应当仅负责一项任务。

在Streamlit中渲染Pyvis图表时，需要将数据写入临时文件，而非传递内存中的字符串。请使用tempfile.NamedTemporaryFile，并记得之后及时清理该文件。另外需要注意的是，st.components.v1.html预计从2026年6月1日起将被废弃，因此今后应使用st.iframe。

核心设计思路

这类系统真正的智能并非来自语言模型本身，而是源自其背后的内存存储机制。

模型本身完全没有内存，本质上是无状态的。它会读取一段文本并生成一组实体，也会读取一个问题并生成相应的SQL查询。每次调用之间没有任何数据会保留——每一次启动都是全新的开始。

Cosmos DB就是实际存储内存的地方。一旦有内容被保存到“大脑”中，原本从模型中临时提取的信息就会变成持久、结构化且可搜索的记录。领域术语表也在不断扩充，各种关联关系也在持续延伸。知识会随着时间逐步积累。

整个系统运行在已有的基础设施之上——Azure VM、Azure Functions、Azure Cosmos DB以及Azure OpenAI，这些通过AGF Hub实现协同工作。无需引入新服务，也不需要复杂的处理流程。其成功的关键在于精心设计的存储机制、明确划分的各工具职责，以及一个仅需负责读取会议内容、从而免除人们此项工作的语言模型。