AryanDadhich26/Incident-Memory-Assistant

# 故障响应记忆助手 这是一个真正具备“记忆”能力的故障响应系统。大多数告警工具只能告诉你哪里出了问题，却无法告诉你你的团队是否曾经遇到过完全相同的问题，或者上次是如何解决的。这些知识通常只存在于某个人的脑海中，或者深埋在没人会在“救火”时打开的 wiki 页面里。这个项目正是为了填补这一空白。 ## 功能介绍 当告警传入时，系统会将告警文本转换为 embedding 向量，在包含已解决历史故障的数据库中进行语义相似度搜索以找到最接近的匹配项，并调用 LLM 生成一份简短实用的简报：可能发生了什么、记录中最相似的故障，以及建议的首选处理步骤。这份简报会在几秒钟内发送到 Slack。 一旦故障被真正解决，其解决方案就会被记录回该系统中。它同样会被转换为 embedding 向量并添加到记忆中。因此，下次发生类似情况时，这条故障记录也会成为被检索内容的一部分。系统的每一次使用都会让它变得更加智能。 ## 为什么使用语义搜索而不是关键字匹配 关键字搜索无法将“checkout service 容器不断崩溃并显示 OOMKilled 状态”和“search-api pod 因内存溢出错误反复重启”联系起来。这是同一个底层问题，但几乎没有共用的词汇。而 Embeddings 技术可以捕捉到这种关联。这实际上经过了直接测试：一条与任何已存储故障措辞完全不同的全新 OOM 类型告警，依然正确地将对应的历史故障排在了匹配度最高的位置。 ## 架构 新告警 -> Webhook -> 文本 Embedding 提取 (HuggingFace, BAAI/bge-small-en-v1.5) -> 基于 cosine similarity (余弦相似度) 搜索历史故障 (Postgres + pgvector) -> 保留最匹配的记录 -> LLM 撰写简报 (Groq, Llama 3.3 70B) -> 发布到 Slack 已解决故障 -> Webhook -> 文本 Embedding 提取 -> 回写至 incidents 表 -> 在 Slack 中进行确认 这两个流程共享同一个 Webhook 入口，通过事件类型字段进行路由，因此只需管理一个 URL，而不是两个。 ## 技术栈 - 使用 n8n 进行编排 - 启用了 pgvector 扩展的 PostgreSQL（托管于 Supabase）作为向量记忆存储 - HuggingFace Inference API 用于生成 Embeddings - Groq 用于实现极速的 LLM 推理 - Slack 用于消息分发和确认 ## 关于构建过程的说明 这并不是一个一帆风顺、线性推进的构建过程，我认为有必要坦诚这一点。最困难的环节不在于编写 embedding 调用或 Postgres 查询，而是一个奇怪的 bug：相似度搜索会同时跨越多个层级悄无声息地返回零行数据，且没有任何错误提示。这段查询在单独测试时是正常的，单独配合 WHERE 子句是正常的，单独进行 SELECT 运算也是正常的，但一旦加上 ORDER BY 就会失败。 最终，使用 EXPLAIN ANALYZE 追踪到了原因，证明 Postgres 其实正确地返回了数据行。真正的问题出在 SQL 编辑器 UI 中存在过期的结果缓存，根本不是查询语句的问题。这种有条理的、每次只改变一个变量的排查方法，以及学会不要盲目相信一个显示“无数据”的 UI、而是去检查底层引擎的做法，最终成为了构建这个项目最有价值的心得。 ## 设置 1. 创建一个启用 pgvector 扩展的 Postgres 数据库 2. 运行 `db/schema.sql` 以创建 incidents 表 3. 将 `workflow/incident-memory-assistant.json` 导入 n8n 4. 添加你自己的 HuggingFace、Groq、Postgres 和 Slack 凭据 5. 为触发器设置一个 webhook 密钥标头，用于基础认证 6. 向 webhook 发送一条测试告警，并观察它是否成功送达 Slack

标签：LLM, Slack, Unmanaged PE, 人工智能, 向量检索, 测试用例, 用户模式Hook绕过, 运维