1. 项目概述一个能记住会议内容的AI助手在团队协作里开会是常态但开完会后的“失忆”也是常态。大家热火朝天地讨论了半天谁负责什么、达成了什么共识、下次要跟进什么当时觉得清清楚楚可一旦散会这些信息就像沙子一样从指缝里溜走。它们可能散落在不同人的笔记里、某段聊天记录里或者干脆就只存在于某个人的模糊记忆中。过不了几天同样的问题会被再次提出“上次不是说让张三负责这个吗”“那个功能的截止日期到底是哪天来着”这种反复的确认和追溯消耗的是整个团队的注意力和效率。我一直在想能不能有一个工具它不只是一个被动的记录员而更像一个拥有“长期记忆”的团队协作者。它能把每次会议的要点结构化地存下来并且在我们需要查询的时候像一位资深同事一样准确地告诉我们过去发生了什么。这就是我动手搭建“AI会议记忆助手”的初衷。它本质上是一个具备持久化记忆能力的AI智能体核心目标就一个让团队的知识和决策沉淀下来并变得随时可查、可用。这个项目非常适合那些经常开会、项目信息迭代快、且团队成员需要频繁回溯历史讨论的群体比如产品研发团队、敏捷开发小组或者远程协作团队。它不是一个复杂的企业级系统而是一个轻量、可快速部署的实用工具用到的技术栈也都是当前非常主流和易得的。接下来我会详细拆解整个项目的设计思路、实现细节以及我在开发过程中踩过的那些坑和总结出的经验。2. 核心设计思路与架构选型2.1 从“聊天”到“记忆”问题本质的再思考最开始我考虑过直接用现成的聊天机器人框架。但很快发现它们大多属于“会话失忆症患者”——每次对话都是全新的开始无法关联历史上下文。这对于会议记录查询的场景是致命的。我们需要的是一个能够持续学习、积累知识的系统。因此核心设计必须围绕“记忆”展开。这里的“记忆”不是指像数据库那样简单的CRUD增删改查而是指语义化存储不仅要存下文字还要理解文字的含义以便后续能通过意思进行查找而不是单纯的关键词匹配。关联性检索当用户提出一个问题时系统要能从所有历史记忆中找出与当前问题最相关的那些片段。上下文理解与生成结合检索到的相关记忆让大语言模型LLM生成一个连贯、准确、有依据的回答。基于这三点我放弃了做一个“聊天机器人”的想法转而设计一个“记忆代理”。它的首要任务是忠实、结构化地记录其次才是基于这些记录进行智能问答。2.2 技术栈的权衡与最终选择技术选型上我遵循了“轻量、高效、低成本”的原则毕竟这是一个偏向于验证想法和个人/小团队使用的工具。后端语言Python。这是自然语言处理领域的绝对主流生态丰富从简单的文本处理到复杂的AI模型调用都有成熟的库支持开发效率极高。记忆存储方案本地JSON文件。你可能觉得这不够“高级”为什么不用向量数据库这里有个很重要的权衡。对于中小型团队初期的会议记录量并不会爆炸式增长。使用本地JSON文件的好处非常明显零依赖、零成本无需部署和维护额外的数据库服务。极简透明数据以纯文本形式存储格式清晰可以直接查看、备份甚至手动修改心理负担小。足够快的开发验证在项目初期核心目标是验证“记忆检索回答”这个流程是否跑得通。JSON文件完全能满足这个阶段的需求。当然这是一个明确的可扩展点当记录条数上万、检索速度成为瓶颈时可以平滑地迁移到像Chroma、Weaviate这类专业的向量数据库。智能检索核心Embedding 相似度计算。这是实现“语义化查找”的关键。我会使用一个嵌入模型将每一条会议记录转换成高维向量可以理解为一段数字“指纹”。当用户提问时同样将问题转换成向量然后计算问题向量与所有记忆向量之间的余弦相似度找出最相似的几条记录。这里我选择了sentence-transformers库中的轻量级模型它可以在CPU上快速运行效果足够好。大语言模型Groq API。这是本项目在“智能”层面的核心。我放弃使用OpenAI GPT系列的原因主要有两个成本和速度。Groq提供了免费的API额度这对于个人项目和小规模试用非常友好。更重要的是它的推理速度极快几乎是实时返回结果这对于一个需要快速响应的问答工具来说体验提升是质的飞跃。Groq支持诸如Llama、Mixtral等强大的开源模型能力完全足够。用户界面Streamlit。用Python快速构建交互式Web应用的不二之选。几乎不需要前端知识用写脚本的方式就能做出一个包含输入框、按钮、表格展示的完整界面极大地降低了开发门槛。整个架构的流程图用最直白的话来描述就是 用户通过网页输入信息 - 系统判断这是新记忆还是问题 - 如果是新记忆就处理并存进JSON文件如果是问题就去JSON文件里翻找相关的旧记忆 - 把找到的记忆和问题一起扔给Groq - Groq快速生成答案 - 把答案显示给用户。3. 分步实现与核心代码解析3.1 环境搭建与依赖管理第一步是创建一个干净的项目环境。我强烈建议使用虚拟环境来隔离依赖。# 创建项目目录并进入 mkdir ai-meeting-memory cd ai-meeting-memory # 创建虚拟环境这里使用venv你也可以用conda python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate接下来创建requirements.txt文件列出所有需要的库。版本号很重要可以避免后续因库更新导致的兼容性问题。streamlit1.29.0 groq0.3.0 sentence-transformers2.2.2 python-dotenv1.0.0 numpy1.24.3然后安装它们pip install -r requirements.txt实操心得永远在项目根目录下放一个requirements.txt。这不仅是为了自己以后复现环境更是团队协作的基石。另外python-dotenv这个库是用来管理环境变量的比如你的Groq API Key千万不要把密钥硬编码在代码里3.2 记忆系统的实现存储与检索这是项目的“大脑”部分我把它封装在了一个MemoryManager类里。1. 记忆的存储结构我决定每条记忆都用一个字典来存储包含内容、时间戳和一个唯一的ID。最终所有记忆组成一个列表保存在JSON文件中。import json import uuid from datetime import datetime from sentence_transformers import SentenceTransformer import numpy as np class MemoryManager: def __init__(self, memory_filemeeting_memory.json, embedding_model_nameall-MiniLM-L6-v2): self.memory_file memory_file # 加载嵌入模型用于将文本转换为向量 self.embedder SentenceTransformer(embedding_model_name) self.memories [] self.memory_embeddings [] # 存储所有记忆的向量用于快速检索 self.load_memory() def load_memory(self): 从JSON文件加载已有记忆 try: with open(self.memory_file, r, encodingutf-8) as f: data json.load(f) self.memories data.get(memories, []) # 如果文件中有存储的向量可以加载但这里为了简单我们每次都重新计算 # 实际上对于大量数据应该将向量持久化存储 self._update_embeddings() except FileNotFoundError: # 如果文件不存在就初始化一个空的结构 self.memories [] self.memory_embeddings [] def _update_embeddings(self): 更新内存中所有记忆的向量表示 if self.memories: texts [m[content] for m in self.memories] self.memory_embeddings self.embedder.encode(texts, convert_to_numpyTrue) else: self.memory_embeddings [] def save_memory(self): 将记忆保存到JSON文件 data {memories: self.memories} with open(self.memory_file, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def add_memory(self, content): 添加一条新的记忆 if not content or not content.strip(): return False new_memory { id: str(uuid.uuid4()), content: content.strip(), timestamp: datetime.now().isoformat() } self.memories.append(new_memory) # 计算新记忆的向量并添加到列表 new_embedding self.embedder.encode([new_memory[content]], convert_to_numpyTrue) if len(self.memory_embeddings) 0: self.memory_embeddings new_embedding else: self.memory_embeddings np.vstack([self.memory_embeddings, new_embedding]) self.save_memory() return True2. 记忆的检索逻辑检索的核心是计算相似度。这里我用了余弦相似度它衡量的是两个向量在方向上的接近程度非常适合文本语义相似度比较。class MemoryManager: # ... 接上面的 __init__, load_memory, add_memory 等方法 ... def search_memories(self, query, top_k3): 根据查询语句检索最相关的top_k条记忆 if not self.memories: return [] # 将查询语句转换为向量 query_embedding self.embedder.encode([query], convert_to_numpyTrue) # 计算查询向量与所有记忆向量的余弦相似度 # 使用点积和模长计算因为向量已经是归一化的sentence-transformers默认输出归一化向量 similarities np.dot(self.memory_embeddings, query_embedding.T).flatten() # 获取相似度最高的top_k个索引 top_indices similarities.argsort()[-top_k:][::-1] # 返回对应的记忆内容 results [] for idx in top_indices: results.append({ content: self.memories[idx][content], timestamp: self.memories[idx][timestamp], similarity: float(similarities[idx]) # 转换为Python float类型以便JSON序列化 }) return results注意事项top_k参数的选择是个平衡艺术。设置太小比如1可能遗漏相关上下文设置太大比如10又会给LLM带来无关信息噪声影响回答质量还可能触及上下文长度限制。经过测试对于会议记录这种相对独立的片段3-5是一个比较理想的区间。3.3 智能问答引擎与Groq LLM的集成记忆检索回来的是原始文本片段我们需要一个“大脑”来消化这些信息并组织成通顺的回答。这就是Groq LLM的工作。首先我们需要安全地管理API密钥。在项目根目录创建一个.env文件GROQ_API_KEYyour_groq_api_key_here然后实现一个GroqChatAgent类来处理与LLM的交互import os from groq import Groq from dotenv import load_dotenv load_dotenv() # 加载.env文件中的环境变量 class GroqChatAgent: def __init__(self, modelmixtral-8x7b-32768): # Groq上可用的一个强大模型 api_key os.getenv(GROQ_API_KEY) if not api_key: raise ValueError(请在 .env 文件中设置 GROQ_API_KEY) self.client Groq(api_keyapi_key) self.model model def generate_response(self, user_question, relevant_memories): 基于用户问题和相关记忆生成回答 if not relevant_memories: # 如果没有相关记忆就告诉用户不知道 return 目前我的记忆里还没有相关信息。你可以先添加一些会议记录。 # 构建一个清晰的提示词Prompt这是获得好答案的关键 memories_text \n.join([f- {mem[content]} for mem in relevant_memories]) system_prompt 你是一个专业的会议记忆助手。你的任务是严格基于用户提供的“相关历史记录”来回答问题。 如果答案明确在记录中请直接、简洁地给出答案并可以引用记录内容。 如果记录中的信息不足以完全回答问题请基于已有信息进行回答并说明哪些部分不确定。 如果记录内容与问题完全无关请直接说无法根据现有记忆回答。 请勿捏造记录中不存在的信息。 user_prompt f 用户问题{user_question} 相关历史记录 {memories_text} 请根据以上记录回答问题 try: chat_completion self.client.chat.completions.create( messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], modelself.model, temperature0.1, # 温度设低让输出更确定、更基于事实 max_tokens500 ) return chat_completion.choices[0].message.content except Exception as e: return f调用AI模型时出错{str(e)}核心技巧提示词工程是LLM应用的核心。我在这里设计的system_prompt有几个关键点1) 明确AI的角色2) 强调“严格基于”提供的历史记录这是为了防止幻觉3) 给出了不同情况下的回答策略。temperature参数设置为较低的0.1是为了让输出更加稳定和可预测减少“胡言乱语”的可能。3.4 构建用户界面Streamlit应用集成最后用Streamlit把前后端逻辑串起来形成一个完整的应用。代码结构非常直观。import streamlit as st from memory_manager import MemoryManager from groq_agent import GroqChatAgent # 初始化管理器和代理使用Streamlit的缓存机制避免重复初始化 st.cache_resource def get_memory_manager(): return MemoryManager() st.cache_resource def get_groq_agent(): return GroqChatAgent() def main(): st.title( AI会议记忆助手) st.markdown(记录会议要点随时智能问答。) manager get_memory_manager() agent get_groq_agent() # 侧边栏用于查看和清空记忆 with st.sidebar: st.header(记忆库) if st.button(清空所有记忆, typesecondary): manager.memories [] manager.memory_embeddings [] manager.save_memory() st.rerun() # 清空后刷新界面 if manager.memories: st.subheader(f已存储 {len(manager.memories)} 条记录) for i, mem in enumerate(reversed(manager.memories[-10:])): # 显示最近10条 with st.expander(f记录 {len(manager.memories)-i}: {mem[timestamp][:10]}): st.write(mem[content]) else: st.info(记忆库为空。) # 主界面输入区域 tab1, tab2 st.tabs([ 添加新记录, ❓ 查询记忆]) with tab1: st.subheader(添加新的会议记录或要点) new_note st.text_area(输入内容, placeholder例如张三负责用户登录模块的开发下周五前完成原型设计。, height100) if st.button(保存到记忆库, typeprimary): if new_note: with st.spinner(正在保存...): if manager.add_memory(new_note): st.success(记录已保存) st.rerun() else: st.error(保存失败内容可能为空。) else: st.warning(请输入内容再保存。) with tab2: st.subheader(向助手提问) question st.text_input(你的问题, placeholder例如谁负责登录模块) if st.button(获取答案, typeprimary): if question: with st.spinner(正在检索记忆并思考...): # 1. 检索相关记忆 relevant_mems manager.search_memories(question, top_k3) # 2. 生成回答 answer agent.generate_response(question, relevant_mems) # 显示答案 st.markdown(### 答案) st.write(answer) # 显示用于生成答案的参考记忆增强可信度 if relevant_mems: st.markdown(### 参考的记忆片段) for mem in relevant_mems: st.caption(f相似度{mem[similarity]:.3f} - {mem[timestamp][:10]}) st.text(mem[content]) else: st.info(请输入一个问题。) if __name__ __main__: main()这个界面虽然简单但功能完整左侧可以查看和清空记忆主区域分两个标签页分别用于“记录”和“问答”并且在回答时还会展示它参考了哪些原始记录让整个过程透明可信。4. 部署、优化与踩坑实录4.1 本地运行与简单部署在本地运行非常简单在项目根目录下执行streamlit run app.pyStreamlit会自动在浏览器打开一个本地页面。如果你想与团队成员共享可以考虑以下几种轻量级部署方式Streamlit Community Cloud这是最省事的方法。将代码推送到GitHub仓库然后在 share.streamlit.io 上关联仓库即可一键部署。注意免费版有资源限制且需要将.env中的密钥设置为Streamlit的Secrets。Railway / Render这些是优秀的PaaS平台提供简单的Git部署和免费额度非常适合此类应用。Docker化部署编写一个Dockerfile可以部署在任何支持Docker的VPS或云服务上灵活性最高。4.2 性能优化与扩展思考项目跑起来后我针对几个方面做了优化和未来规划检索速度当记忆条数超过1000条时每次检索都计算所有向量的相似度会变慢。解决方案是引入向量数据库如ChromaDB或Qdrant它们为向量相似性搜索做了极致优化。记忆结构化目前记忆是纯文本。可以引入一个“信息提取”步骤在保存前用LLM自动提取“人物”、“任务”、“截止日期”、“项目”等实体并打上标签这样后续可以支持更精准的过滤查询如“显示所有分配给张三的任务”。记忆总结与压缩长期积累后记忆会变得冗长。可以定期如每周用LLM对记忆进行自动总结生成周报并将详细记忆归档保持活跃记忆库的简洁。多模态支持结合Whisper等语音转文本工具可以直接上传会议录音自动生成文字记录并存入记忆库。4.3 开发中遇到的典型问题与解决方案Groq API Key集成问题问题最初把API Key直接写在代码里提交到GitHub后导致密钥泄露测试Key被刷爆。解决立即使用python-dotenv将密钥放入.env文件并将.env添加到.gitignore中。在Streamlit Cloud部署时则使用其提供的“Secrets”管理功能。模型版本过时或不可用错误问题Groq的模型更新较快有时代码中指定的模型名会失效返回model not found错误。解决首先去Groq官方文档查看当前可用的模型列表。其次在代码中增加错误处理当模型不可用时可以优雅地降级到另一个备用模型如llama3-8b-8192并提示用户。Python缩进和导入错误问题在组织多个类到不同文件如memory_manager.py,groq_agent.py时经常出现循环导入或相对导入错误。解决保持简单的项目结构。对于小项目所有类可以放在一个app.py里。如果分文件确保入口文件app.py在根目录并使用绝对导入from modules.memory_manager import MemoryManager。使用__init__.py文件来明确包结构。记忆检索结果不相关问题有时用户问“项目进度”却检索到了关于“项目预算”的记录虽然都有“项目”这个词但语义不匹配。解决这主要是嵌入模型和检索策略的问题。我尝试了以下方法更换嵌入模型从all-MiniLM-L6-v2换成了针对句子对匹配任务优化过的all-mpnet-base-v2效果有提升但模型更大。优化查询在将用户问题转换成向量前先用一个简单的规则或小模型对问题进行“重写”或“扩展”。例如将“谁做后端”扩展为“寻找关于人员分工、后端开发、职责分配的记忆”。混合检索结合关键词检索如BM25和向量检索取长补短。关键词检索能保证字面匹配向量检索保证语义匹配。LLM回答出现“幻觉”问题即使提供了相关记忆LLM有时还是会编造一些记忆中没有的细节。解决这是提示词工程的重点。我在system_prompt中非常强硬地规定了“严格基于提供的历史记录”和“请勿捏造信息”。同时将temperature参数调低增加“如果记录中信息不足请说明”的指令。在UI中展示“参考的记忆片段”也让用户能自行判断答案的可信度。这个项目从构思到实现是一个典型的“用合适的技术解决具体问题”的过程。它没有追求技术的炫酷而是紧紧围绕“记忆”这个核心需求选择了一条最务实、最快速的实现路径。看到它能够准确回答“上次会议决定谁来做演示”这样的问题时那种创造出一个有用工具的满足感是最大的收获。未来我会在此基础上继续迭代比如尝试接入实时语音转录让它真正成为会议中的“隐形书记员”。
