长对话里最让人头疼的问题是什么不是模型不聪明而是聊到最后模型把前面说的关键信息忘了、混淆了甚至一本正经地给出和前面矛盾的回答。这个现象有一个专门的称呼LLM context drift上下文漂移。这次我们来看一个思路非常直接的项目作者在 Hacker News 上用一句话概括了全部工作我搭了一个空间节点画布用来修复 LLM 的上下文漂移。这个项目没有走 RAG 或长窗口那套路线而是把上下文从“一长串文本”改造成“一张可以摆放和连接节点的画布”。对话、文档、知识片段都变成节点模型在回答时不再只盯着最后几轮对话而是从画布上按需取用相关信息。本文会拆解 context drift 产生的原因、空间画布的设计思路、通用架构、部署与验证流程、API 接入和批量任务处理最后给出一套可直接参考的排查清单。先说结论如果你正在做长对话、文档问答、知识库整理这类 LLM 应用并且被“聊着聊着就丢信息”折磨过这个方向值得认真试一遍。它不追求让模型记住更多而是让模型更容易找到该记住的内容。1. 核心能力速览从项目标题和关键词能确认的核心信息如下表。由于原项目没有公开完整的参数文档和显存、版本、运行环境相关的细节以通用实践为准。能力项说明项目类型LLM 上下文管理可视化工具面向 context drift 场景核心思路用空间节点画布组织对话上下文替代纯线性文本流关键能力节点编辑、画布布局、上下文按需组装、长对话管理主要解决长对话中早期信息被覆盖、模型回答前后矛盾、上下文超限交互方式可视化画布节点可摆放、分组、连线依赖环境Web 浏览器 LLM API 服务具体技术栈需以项目仓库为准显存需求取决于后端模型纯画布前端几乎不占用 GPU启动方式前端应用 后端 API 服务可分离部署是否支持 API支持画布内容最终需要组装成 LLM 可消费的结构化输入是否支持批量任务可通过导入脚本/任务队列批量处理文档与对话片段适合场景长对话辅助、文档问答、知识库管理、上下文可视化调试这个项目的核心卖点不是“更强的模型”而是一套更贴近人脑工作方式的上下文组织方式。它把 LLM 的单线叙事变成二维空间里的关系网络从根上降低漂移发生的概率。2. 适用场景与使用边界空间节点画布本质上是一个“上下文管理中间层”。它坐在 LLM 前面负责决定哪些信息进入 prompt哪些信息先留着。理解了这一点就能判断它适合什么场景。2.1 适合谁长对话应用开发者需要让模型记住用户早期提到的一堆约束条件。知识库问答团队把不同来源的文档拆成节点再按问题动态组装。Prompt 工程调试者把复杂 prompt 展开成画布直观查看上下文结构。个人知识管理用户类似 Obsidian Canvas 的用法但目标变成让 LLM 读得更准。2.2 不适合什么简单单轮问答杀鸡用牛刀画布维护成本远大于收益。对延迟极其敏感的生产服务画布需要检索和组装上下文比直连 LLM 多一层开销。纯离线场景如果没有本地 LLM 服务画布前端本身没有生成能力。2.3 使用边界涉及版权素材、私有文档、用户隐私时必须确认数据来源合法、使用已获授权。尤其是把画布内容传给第三方 LLM API 时要评估敏感信息泄露风险。如果处理的是人脸、声纹、身份信息等部署环境需要放在可信边界内并做好访问限制。3. 为什么线性对话会漂移问题拆解在理解空间节点画布之前先搞清楚 context drift 为什么会发生。这决定了后面所有设计选择是否站得住脚。3.1 线性窗口的天然缺陷LLM 的上下文窗口是有上限的。当对话超过窗口长度早期内容会被截断或压缩。更隐蔽的问题是即使内容还在窗口内新出现的语义相似的文本也会对模型的注意力产生干扰导致模型“想不起来”前面的准确描述。传统做法通常是三种增大上下文窗口成本线性上涨而且模型对窗口中间部分的注意力本来就偏弱。摘要压缩摘要本身就是一次有损压缩关键数字和约束很容易丢。RAG 切割召回适合事实检索但对话中的逻辑依赖、前后顺序、矛盾修正信息很难用向量相似度找回。3.2 对话结构比对话长度更重要观察一个长对话的典型流程用户先提需求 A中途补充限制 B之后纠正了对 C 的理解最后让模型输出一份总结。线性文本流里这些信息是平铺的。模型只能靠位置去猜测哪些信息重要。一旦中间穿插了大量无关内容关键信息就会被稀释。空间节点画布的思路是把信息按主题切块每个块成为一个节点。节点之间用边表示依赖、补充、矛盾的逻辑关系。模型在生成回答时只需要读取当前任务相关的子图而不是从头到尾扫一遍。3.3 漂移的三种表现从实际使用角度中文用户最容易遇到的漂移问题有三种漂移类型表现画布方案的应对遗忘型漂移模型忘记用户早期指定的格式要求把格式约束做成常驻节点每次组装 prompt 时固定加载覆盖型漂移后出现的相似信息把旧信息冲掉节点不删除历史版本通过版本节点保留全貌矛盾型漂移新回答与旧回答逻辑冲突用依赖边显式标记“后者修正前者”组装时加入提示4. 空间节点画布的设计思路现在进入核心设计。空间画布解决漂移问题靠的是三个机制节点化、空间化、按需组装。4.1 节点化信息最小单元每个节点是一个自包含的信息块。一个节点包含三件事内容文本、代码、图片描述、超链接等。元信息创建时间、来源、标签、向量、重要性权重。位置画布上的二维坐标和尺寸。节点的粒度很关键。太粗节点内部还是会漂移太细画布会被碎片淹没。经验值是一个节点表达一个完整的最小结论、要求或事实。比如“用户要求输出格式为 JSON”是一个节点“模型的回复风格偏好”是另一个节点。4.2 空间化用二维位置承载语义线性的上下文只能靠顺序表示关系画布上可以同时表达多层关系左右位置表示先后顺序或并列关系。上下位置表示抽象层级或从属关系。分组框表示同一个主题域。连线表示依赖、引用、修正、冲突。空间化带来的直接好处是全局可见。用户能一眼看出某个主题的节点是否散落各处、重点是否被边缘化。模型在组装上下文时也能按照空间邻近性和连接关系做局部采样避免长尾干扰。4.3 按需组装动态生成 prompt画布本身不是喂给模型的原始输入它是一张“地图”。真正送到 LLM 的 prompt是在每次请求时动态组装出来的。组装流程可以设计成接收用户问题 - 解析问题意图 - 在画布上定位相关节点 - 沿边扩展关联节点 - 按重要性和时间排序 - 拼装成结构化 prompt - 调用 LLM这个流程和 RAG 很像区别在于关系扩展不是靠向量相似度而是靠画布上的显式连接。显式连接的好处是可控、可解释坏处是需要维护。所以这个工具最好配合一个还不错的本地 LLM 服务让模型辅助完成节点切分和连线。5. 原型系统架构与数据模型把设计落成原型至少需要前端画布、后端服务、LLM 接入三块。下面给出通用架构实际项目路径、端口和依赖名需要按仓库说明替换。5.1 前端画布前端不需要从零写。可以借用成熟的开源图编辑库比如 React Flow、Canvas 类组件库或者直接基于 Obsidian Canvas 的功能思路做定制。关键交互功能创建节点。拖拽节点。连接节点。分组与折叠。画布缩放与鹰眼导航。5.2 后端服务后端负责节点存储、关系管理、上下文组装、LLM 代理。一个最小后端接口设计如下接口方法功能/api/nodesGET获取全部节点/api/nodesPOST新增节点/api/nodes/:idPATCH更新节点内容或位置/api/edgesPOST新增节点连线/api/context/buildPOST根据问题组装上下文/api/chatPOST组装上下文后调用 LLM 并返回回答5.3 数据模型节点和边用 JSON 存储示例结构如下。{ node_id: node_001, type: requirement, content: 用户要求所有回复使用 Markdown 表格输出, meta: { created_at: 2025-01-01T10:00:00Z, source: user_message, importance: 0.9 }, position: { x: 120, y: 240 } }边的结构{ edge_id: edge_001, source: node_001, target: node_002, relation: supports }relation 字段建议支持这些枚举值supports支持/补充。depends_on依赖。contradicts与...矛盾。revises修正/覆盖。example_of举例。5.4 Python 伪代码示例下面是一段上下文组装的 Python 伪代码展示如何把画布节点变成 prompt。实际项目需要用具体框架替换 HTTP 层和存储层。def build_context(canvas_id, question, max_chars6000): nodes load_all_nodes(canvas_id) target_nodes locate_nodes_by_semantics(nodes, question) selected set() for node in target_nodes: selected.add(node) for edge in load_edges_from(node): if edge.relation in (supports, depends_on, revises): selected.add(edge.target) selected prune_by_importance(selected, max_charsmax_chars) ordered topological_sort(selected) return assemble_prompt(ordered)这段伪代码已经体现了空间画布解决漂移的关键点初始化时只选相关节点再沿关系边扩展最后做重要性裁剪和排序。6. 环境准备与启动部署由于原项目没有给出精确的启动命令这里给一套通用部署流程。你拿到真实仓库后按仓库 README 替换路径、端口和脚本名即可。6.1 前置环境清单Node.js 18 或更高版本用于前端画布。Python 3.10 或更高版本用于后端服务。可用的 LLM 服务OpenAI 兼容接口、本地 Ollama、vLLM 服务均可。磁盘空间代码和依赖按项目大小预留纯前端项目通常不足 1GB后端依赖另算。6.2 前端启动模板cd spatial-canvas-frontend npm install npm run dev启动后浏览器访问http://127.0.0.1:5173如果端口被占用按终端提示切换端口。6.3 后端启动模板cd spatial-canvas-backend python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python app.py --host 127.0.0.1 --port 80006.4 配置 LLM 服务后端需要知道 LLM 服务的地址。典型配置用环境变量不要写死在源码里。# .env 示例实际变量名以项目为准 LLM_API_BASEhttp://127.0.0.1:11434/v1 LLM_API_KEYlocal-test-key LLM_MODELllama3.1 CONTEXT_MAX_CHARS8000如果使用 OpenAI 兼容接口直接指向本地 Ollama、LM Studio、vLLM 都可以。注意不要把敏感的 API Key 提交到 Git也不要在公网裸奔。6.5 一键启动脚本模板方便日常开发可以写一个启动脚本。#!/bin/bash # start-dev.sh 模板路径按实际项目修改 npm --prefix ./frontend run dev uvicorn backend.main:app --host 127.0.0.1 --port 8000 wait7. 功能测试与效果验证部署完成后按照下面的顺序验证核心功能。7.1 节点创建与画布编辑测试目的确认画布可以正常创建、拖拽、连接节点。操作步骤打开画布页面。右键创建三个节点。分别输入“用户要求 JSON 输出”“核心字段是 name 和 age”“错误示例age 是字符串”。用连线把三个节点连接起来后一个节点标记为 revises。预期结果节点能保存拖动后刷新画布位置不丢失连线方向正确。如果节点位置不保存优先检查后端存储接口是否正常工作。7.2 上下文组装测试测试目的确认后端能根据问题把画布节点组装成有序的上下文。请求示例curl -X POST http://127.0.0.1:8000/api/context/build \ -H Content-Type: application/json \ -d { canvas_id: demo_canvas, question: 请输出用户要求的 JSON 字段 }预期输出返回一段按依赖顺序排好的上下文文本并且包含“输出格式必须为 JSON”“字段为 name 和 age”“age 不是字符串”这三条信息。如果遗漏了 revises 节点说明扩展边的逻辑只包含了 supports需要在后端补上 revises 关系。7.3 漂移对比测试这是最重要的测试。设计一个对比实验对照组用普通对话模式连续提问长度逐渐增加观察模型是否忘记最初约束。实验组把同样信息放入画布每次追问前先调用 build_context 组装。测试脚本逻辑可以这样写questions [ 第一条限制不要使用 markdown 表格, 第二条限制语气要正式, 现在总结一下输出风格上我要求什么 ] # 对照组直接把 questions 拼接进同一个 session # 实验组把每条限制做成节点每次调用前组装判断标准实验组应该稳定回答出“不要使用 markdown 表格、语气正式”对照组在经历大量无关对话后可能出现遗漏。7.4 长文本与多轮稳定性测试准备一份大约 5000 字的中文文档拆成 20 个节点随机分布在画布上然后用 20 轮追问验证信息召回率。每轮记录模型回答是否包含对应节点内容。组装耗时。输入 token 数。这个测试可以暴露画布工具在高负载下是否真的比线性上下文更稳定。8. 接口 API 调用与批量任务空间画布的价值长期看要靠 API 生态放大。只有能对接外部工具它才能从“demo”变成“基础设施”。8.1 核心接口请求示例创建一个节点的请求curl -X POST http://127.0.0.1:8000/api/nodes \ -H Content-Type: application/json \ -d { canvas_id: demo_canvas, content: 用户要求每次回答先给结论, type: requirement, position: {x: 10, y: 20} }调用 LLM 生成回答curl -X POST http://127.0.0.1:8000/api/chat \ -H Content-Type: application/json \ -d { canvas_id: demo_canvas, question: 我最早提的格式要求是什么 }返回结构建议保持统一{ reply: 用户要求每次回答先给结论。, context_nodes: [ { node_id: node_001, content: 用户要求每次回答先给结论 } ], usage: { prompt_tokens: 1200, completion_tokens: 30 } }返回 context_nodes 非常重要它让用户能审计模型到底看了哪些内容这一步对排查漂移问题非常关键。8.2 批量导入文本批量任务场景比如把一批 Markdown 文档导入画布并切成节点需要设计一个导入脚本。import json import requests BASE_URL http://127.0.0.1:8000 def import_markdown(path, canvas_id): with open(path, r, encodingutf-8) as f: blocks split_markdown_blocks(f.read()) for i, block in enumerate(blocks): payload { canvas_id: canvas_id, content: block[text], type: document_block, position: {x: i * 200, y: (i % 5) * 100} } resp requests.post(f{BASE_URL}/api/nodes, jsonpayload, timeout10) print(resp.status_code, block[title])批量任务的工程化要求每个节点带上 source 字段记录原始文档路径。处理失败后记录到 error.log不中断整体流程。增量导入时用文档 hash 判断是否重复避免画布内容无限膨胀。8.3 批量任务失败重试画布工具处理长文档时最容易失败的情况是节点切分后内容错乱。常见原因有两种一种是文档编码不是 UTF-8一种是分隔符太简单导致代码块被切断。解决思路是给导入脚本增加校验。导入完成后后端对每个节点做合法检查包含节点大小阈值和文本编码检测发现异常就丢弃或回退。9. 资源占用与性能观察资源占用没有统一的答案取决于后端 LLM 服务和前端画布的数据量。但还是有一些通用观察方法。9.1 前端画布性能画布节点数量超过 1000 个时浏览器渲染会成为瓶颈。建议观察拖动节点时 FPS 是否下降。初始化加载是否出现白屏。浏览器 DevTools Performance 面板是否有长任务。如果卡顿优先考虑节点懒渲染方案只渲染视野范围内的节点。9.2 后端组装性能上下文组装耗时主要花在节点检索和排序上。节点数量在万级别以下用普通内存遍历即可超过十万需要引入索引。建议后端记录每次组装的耗时context build time: 23ms selected nodes: 12 prompt chars: 4560如果组装时间持续上升优先检查是不是每次把全部节点都加载到了内存里。9.3 LLM 推理资源显存占用由后端 LLM 决定。以 7B 量化模型为例常见情况下 8GB 显存可以运行但这只是参考值。实际占用必须按模型版本、量化精度和并发数测试。观察方法后端是 Ollama看ollama ps。后端是 vLLM看/metrics接口。后端是 API 服务看返回的 usage 字段。空间画布本身不会显著增加显存开销。它的成本更多是组装的延迟和 token 的消耗。10. 常见问题与排查方法问题现象可能原因排查方式解决方案画布页面打不开端口被占用或前端服务未启动检查终端日志执行lsof -i:5173换端口或用CtrlC结束残留进程节点新建后刷新丢失后端存储接口未启动或写入失败打开浏览器 Network 面板看 POST 请求状态码启动后端服务确认数据库文件可写上下文组装缺少关键节点边的 relation 类型未覆盖 revises打印 build_context 中选择的节点列表扩展关系遍历逻辑组装后的 prompt 超出上下文窗口节点裁剪策略失效查看 usage.prompt_tokens检查 max_chars降低重要性权重阈值或优先裁剪低权重节点LLM 返回内容互相矛盾只加载了局部节点且没有加载冲突节点检查 context_nodes 是否包含 revises 边目标强制在 prompt 中加入“修正/覆盖”说明批量导入中途失败文档编码不是 UTF-8 或分隔符不匹配查看 error.log定位失败文档增加编码转换预处理API 请求超时后端组装逻辑过慢或 LLM 服务无响应单独压测 LLM 接口耗时增加超时时间或对容器做大文档拆分画面大规模卡顿节点数量过多画布全量渲染Performance 面板确认渲染耗时开启视野裁剪或虚拟滚动11. 最佳实践、合规与下一步把一个画布工具真正用起来有下面几条具体建议。11.1 工程化建议第一次使用小数据集验证20 个节点以内最合适。保存一套最小可运行配置包括示例画布、示例 LLM 服务地址和示例问题集。节点、输入素材、输出结果分目录管理方便回溯。批量任务必须有日志和失败重试。接口服务绑定 127.0.0.1不要直接暴露公网。画布内容定期导出备份JSON 结构适合直接纳入版本管理。11.2 合规提醒项目中如果涉及用户对话、个人文档、企业内部知识要确认数据授权范围。上传到云端 LLM 服务前必须脱敏或确认服务商的隐私协议。涉及人脸、声音、身份信息的材料原则上不要流向未知服务。商用发布前对模型输出做人工复核避免产生不当内容。11.3 下一步可以扩展的方向这套思路如果验证有效可以继续往三个方向扩展在画布上实现节点级 RAG。点击一个节点就能看到它的相似节点减少手动连线的成本。自动冲突检测。每次新增节点时调用 LLM 判断是否与既有节点矛盾如果有自动画出 revises 边。从普通聊天记录反推画布。给定一段长对话自动切分节点并建立关系让用户无需手动整理就能用画布管理旧会话。相比换更大的模型空间节点画布提供的是另一种解法通过改变上下文的结构而不是无脑扩大容量来解决信息遗漏和矛盾问题。值得先在一个真实的迷你长对话场景里跑一次漂移对比测试再决定要不要把这个思路带到生产项目里。