DeepGraph 这个名字第一次出现时很容易让人以为它又是一个“把知识图谱画得更漂亮”的可视化工具。但如果把“选中即问”这四个字拆开看你会发现它真正改变的不是图谱渲染效果而是人和大模型交互的底层路径。过去我们和 AI 协作的典型流程是复制一段文本 → 粘贴到对话框 → 写下“请总结/请解释/请分析” → 等待答案 → 再手动整理成结构化材料。这个流程看起来不复杂但实际操作中非常打断思路。尤其是你正在读一篇长文档、一段日志、一堆报错信息时每一次“复制粘贴提问”都是一次上下文切换而上下文切换恰恰是深度工作中最昂贵的隐性成本。“选中即问”的价值就在这个环节。它把“提问”这个动作直接嵌入到“选中”这个自然操作里让大模型不再是一个等待召唤的对话框而是你阅读和思考过程中的一个随时响应的分析层。这篇文章我会从交互范式、技术实现、场景边界、工作流搭建和常见坑几个角度把 DeepGraph 和“选中即问”这类范式讲透最后给出一个不依赖特定产品也能落地的本地分析流程。1. 这篇文章真正要解决的问题先说判断DeepGraph 这一类“选中即问”工具的核心理念不是把大模型做得更聪明而是把大模型接入工作流的摩擦降到最低。很多人以为多轮对话已经解决了大模型的使用门槛但真实开发场景里对话式交互有一个被低估的问题——它要求你先跳出当前任务去组织一段新的上下文。举个例子你在排查一个线上接口超时问题日志里有十几条链路追踪记录你打算让 AI 帮你分析根因。对话式交互下你得先选中日志、复制、切到聊天窗口、粘贴、写提示词可能还要补充说明背景。这套流程走完你至少需要 30 秒。而“选中即问”模式下你只需要选中文本点击一下“分析根因”结果直接在旁边展开。这 30 秒的差距看起来不大但叠加到一天几十次提问的频率上差距就变成了“愿不愿意每次都问”和“干脆自己看算了”。这才是这类工具真正解决的问题它不是提升单次回答质量而是把“让 AI 参与分析”变成零成本动作从而改变你的工作习惯。这篇文章适合以下几类读者每天需要阅读大量文档、日志、代码片段并且习惯用 AI 辅助理解的人。正在做 RAG 应用、Agent 工具链、浏览器插件或者 IDE 插件想理解“选中即问”交互如何实现的人。对知识图谱、关系抽取、实体链接感兴趣想知道图和 LLM 结合时应该关注什么的人。想在自己的工具链里复刻类似交互但不想被特定商业产品绑定的开发者。读完之后你至少能回答三个问题DeepGraph 这类“选中即问”到底是什么它适合解决什么问题、不适合解决什么问题如果不使用现成产品自己搭一个最小可用的“选中即问”流程需要哪些步骤。2. 核心概念DeepGraph 与“选中即问”交互范式2.1 什么是 DeepGraph从产品和交互模式来看DeepGraph 属于“大模型 图结构化输出”的工具类型。它的定位可以拆成两层理解。第一层是“深度”。大模型收到选中的文本后不是只做一个表层摘要而是对文本做实体识别、关系抽取、情感判断、逻辑梳理等多层次分析。第二层是“图”。分析结果以图结构呈现节点是实体和概念边是实体间的关系而不是一段线性文字。这类工具的核心能力通常包含三点实体识别从文本中抽取关键对象比如人、组织、代码函数、服务、异常类型。关系抽取识别实体之间的语义关系比如“A 调用 B”“C 依赖 D”“E 是 F 的根因”。结构化输出把实体和关系转换为 JSON 或图数据格式后续可以用于可视化、检索、推理。2.2 “选中即问”的本质是交互范式的变化如果只看功能“选中即问”很容易被误解为“快捷的复制粘贴”。但实际上它是从“对话驱动”到“意图驱动”的转变。在传统对话式交互中用户负责把上下文搬运到对话框这本质上是人在适应机器的输入方式。而“选中即问”模式把上下文获取这个环节交给了系统系统通过你在当前页面上选中的内容来推测意图然后主动补齐分析逻辑。用浏览器插件来类比可能更好懂传统对话式 AI 像一个你随时可以呼叫的同事你得先把材料整理好给他他才能帮你分析。而“选中即问”像一个驻场的分析师你只需要把材料用手指指出来他就会告诉你这个材料里有什么、代表什么、值不值得继续深挖。这个变化的工程意义在于交互路径短了AI 参与任务的频率就高了。而任务频率提高之后用户对 AI 的信任建立和 prompt 迭代速度都会明显加快。2.3 DeepGraph 与传统知识图谱工具的区别这里需要做一个关键区分DeepGraph 不等于传统知识图谱平台。传统知识图谱平台解决的是“存量知识的组织与查询”问题你需要先定义本体、完成数据清洗、构建图谱然后才能在上面做问答和推理。整个过程重、慢、依赖专业数据工程师。DeepGraph 这类工具是“生成式图谱”你选中一段文本大模型实时抽取出这次分析需要的实体和关系生成一个临时的、面向当前任务的轻量级图谱。它不追求构建一个长期稳定的知识库而是追求“当次理解”的结构化。这两种模式的适用场景完全不同维度传统知识图谱DeepGraph 生成式图谱数据准备需要本体设计、数据清洗不需要天然处理非结构化文本图谱时效存量知识库相对静态随选随生成面向当前任务构建成本高依赖专业团队低单次推理即可适用问题统一知识体系的查询和推理单篇文档/代码片段的理解与分析准确性可以人工校对依赖模型抽取能力可能有误差理解这个区别之后你就会明白DeepGraph 的目标不是替代 Neo4j 或者 Protege而是把图谱从“基础设施”变成“交互副产品”。3. 适用场景与边界什么适合用 DeepGraph什么不适合3.1 适合的场景从“选中即问”的交互特点看这类工具最适合的是“单点深挖型”的理解任务。所谓单点就是你一次关注的文本范围是有限的比如一段报错日志、一个需求描述、一篇几千字的文章所谓深挖就是你需要的不只是关键词提取而是理清内部关系和因果链条。典型场景包括代码评审选中一段 diff让 AI 分析这个改动会影响哪些模块、是否引入循环依赖、异常传播路径是否安全。日志排查选中一段链路追踪日志让 AI 抽取出调用链上的节点和耗时瓶颈生成依赖关系图。需求理解选中一段产品需求文档抽取角色、流程节点、异常分支输出泳道图式的结构化描述。文档精读选中一篇技术方案抽取架构组件、交互协议、数据流方向生成组件关系图。这些场景的共同点是文本本身有丰富的实体关系单次任务范围可控用户需要的是一目了然的结构化结论。3.2 不适合的场景“选中即问”不是万能入口它有几个明显的边界。第一是跨文本的全局推理。如果你想知道一个仓库里所有服务之间的完整调用关系靠“选中”没法完成因为调用关系分散在几十上百个文件里。这种任务需要的是全量代码扫描和静态分析“选中即问”不适合。第二是精确数据查询。如果想知道某个接口在昨天中午十二点的平均响应时间用“选中即问”去问一段日志文本意义不大这是指标查询系统的工作。第三是需要严格审核的高风险推理。医疗诊断、金融决策、法律意见这类场景虽然能从文本中抽出关系图但任何生成式模型的幻觉问题在高风险领域都是不可接受的。此时图谱只能作为辅助参考不能作为决策依据。所以结论是DeepGraph 的“选中即问”解决的是“即时理解”问题不是“全局知识管理”问题。把它定位成一个理解加速器比定位成知识库底座更准确。4. 工作链路拆解从“选中”到“图谱”经历了什么要自己做类似工具或者评估这类产品时需要理解一个“选中即问”从动作发生到图谱渲染的完整链路。通常包括以下五个环节文本捕获。系统获取当前页面上选中的文本。浏览器场景通过插件 API 读取 DOM selectionIDE 场景通过编辑器 API 读取当前选区桌面场景则可能通过辅助功能接口获取。上下文增强。把选中的文本和当前页面/文件的上下文拼装成一次请求。只把选中的五十个字发给模型往往会因为缺乏上下文导致分析质量差所以一般会截取选区前后若干文本作为补充。分析指令。构造 prompt明确要求模型执行实体抽取、关系识别和结构化输出。这个环节决定了图谱质量的上限。结构化解析。模型输出 JSON 之后用解析器校验字段必要时做类型转换和去重。这一步容易踩坑比如模型输出的 key 不稳定、数组嵌套层级不对。图渲染与交互。把解析后的实体和关系交给前端图可视化组件渲染支持点击节点查看详情和追问。这个链路不算复杂但每个环节都有细节。下面我用一个最小可运行的 Python 示例演示如何搭建一条“选中 - 分析 - 图谱”的本地流程不依赖任何特定商业产品。5. 完整示例用 Python 搭建一个最小版“选中即问”5.1 环境准备本文示例使用 Python 3.10 以上版本需要安装以下依赖pip install openai pyperclip这里用openai库调用兼容 OpenAI API 的大模型服务pyperclip用来读取剪贴板中的选中文本。如果你用的是国产大模型服务只要接口兼容 OpenAI 格式代码基本不用改。为了演示流程先创建一个项目目录mkdir deepgraph-demo cd deepgraph-demo5.2 核心分析函数创建一个analyzer.py文件这个文件负责把一段文本转换成图谱结构的 JSON。# 文件路径deepgraph-demo/analyzer.py import json from openai import OpenAI client OpenAI( base_urlhttps://your-llm-endpoint.example.com/v1, api_keyyour-api-key ) SYSTEM_PROMPT 你是一个文本关系分析引擎。你的任务是从用户提供的文本中抽取关键实体和实体间的关系。 要求 1. 识别文本中的核心实体实体类型包括但不限于人员、组织、系统、组件、概念、事件、代码函数。 2. 识别实体之间的语义关系关系类型包括但不限于调用、依赖、导致、属于、包含、对比。 3. 输出 JSON 格式格式如下 { entities: [ {id: 1, name: 实体名称, type: 实体类型, description: 一句话描述} ], relations: [ {source: 1, target: 2, type: 关系类型, description: 关系说明} ] } 4. 只输出 JSON不要输出任何其他内容。 def analyze_text(text: str) - dict: response client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: text} ], temperature0.2, response_format{type: json_object} ) content response.choices[0].message.content return json.loads(content) if __name__ __main__: sample_text 用户服务调用订单服务时出现超时导致订单创建接口的响应时间从 200ms 上升到 2s。 进一步排查发现订单服务依赖库存服务的分布式锁而库存服务所在节点的 CPU 使用率持续处于 90% 以上。 最终判断根因是库存服务所在节点资源不足间接拖慢了用户服务的下单链路。 graph analyze_text(sample_text) print(json.dumps(graph, ensure_asciiFalse, indent2))这段代码里有几个关键点需要解释。SYSTEM_PROMPT是这个流程的灵魂它规定了输出的 JSON schema界定了实体和关系的类型。实际使用中你可能需要根据业务场景调整实体类型和关系类型比如在代码分析场景增加“函数”“模块”实体在日志分析场景增加“服务”“节点”“指标”实体。response_format{type: json_object}是用来约束模型输出 JSON 格式的参数。如果模型服务不支持这个参数可以去掉但需要在 System Prompt 里额外强调“不要输出 Markdown 代码块”。5.3 从剪贴板读取选中文本上面只是核心分析函数还缺少“选中即问”的入口。这里的入口我们先用剪贴板模拟“选中”动作用户复制文本后脚本自动读取剪贴板内容并分析。创建一个clipboard_ask.py# 文件路径deepgraph-demo/clipboard_ask.py import time import pyperclip from analyzer import analyze_text import json def watch_clipboard(interval: float 2.0): last_text pyperclip.paste() print(已启动剪贴板监听复制一段文本即可触发分析...) print(按 CtrlC 退出。) while True: time.sleep(interval) current_text pyperclip.paste() if current_text ! last_text and len(current_text.strip()) 10: print(\n检测到新的选中内容开始分析...\n) try: result analyze_text(current_text) print(json.dumps(result, ensure_asciiFalse, indent2)) except Exception as e: print(f分析失败: {e}) last_text current_text if __name__ __main__: watch_clipboard()运行方式python clipboard_ask.py此时复制任何一段文本脚本会在两秒内检测到剪贴板变化自动调用大模型分析并输出图谱 JSON。5.4 把图谱渲染成可视化JSON 输出虽然结构化但肉眼不友好。我们可以用 Python 的networkx和matplotlib快速渲染一张简单的关系图。pip install networkx matplotlib创建一个render.py# 文件路径deepgraph-demo/render.py import json import networkx as nx import matplotlib.pyplot as plt def render_graph(graph_data: dict, output_file: str graph.png): G nx.DiGraph() for entity in graph_data.get(entities, []): G.add_node(entity[id], labelentity[name]) for relation in graph_data.get(relations, []): G.add_edge(relation[source], relation[target], labelrelation[type]) pos nx.spring_layout(G, seed42) labels {node: data[label] for node, data in G.nodes(dataTrue)} edge_labels {(u, v): data[label] for u, v, data in G.edges(dataTrue)} plt.figure(figsize(12, 8)) nx.draw_networkx_nodes(G, pos, node_size2000, node_color#4C72B0, alpha0.9) nx.draw_networkx_labels(G, pos, labelslabels, font_size10, font_colorwhite) nx.draw_networkx_edges(G, pos, width1.5, edge_colorgray, arrowsize20) nx.draw_networkx_edge_labels(G, pos, edge_labelsedge_labels, font_size9) plt.axis(off) plt.savefig(output_file, dpi150, bbox_inchestight) print(f图谱已保存到 {output_file}) if __name__ __main__: sample { entities: [ {id: 1, name: 用户服务, type: 服务}, {id: 2, name: 订单服务, type: 服务}, {id: 3, name: 库存服务, type: 服务}, {id: 4, name: 分布式锁, type: 组件}, {id: 5, name: CPU 使用率超 90%, type: 指标} ], relations: [ {source: 1, target: 2, type: 调用}, {source: 2, target: 3, type: 依赖}, {source: 3, target: 4, type: 使用}, {source: 3, target: 5, type: 表现为} ] } render_graph(sample)运行python render.py这个示例的图谱虽然简单但已经展示了“选中 - 分析 - 图渲染”的完整闭环。实际产品中前端会用 D3.js、G6 或 ECharts 做更复杂的交互渲染核心数据结构和这里是一致的。6. 运行结果与验证方式运行python clipboard_ask.py后复制我们在analyzer.py中使用的样例文本。正常情况下你会看到类似下面的 JSON 输出{ entities: [ { id: 1, name: 用户服务, type: 服务, description: 调用订单服务的上游服务 }, { id: 2, name: 订单服务, type: 服务, description: 提供订单创建接口的服务 }, { id: 3, name: 库存服务, type: 服务, description: 持有分布式锁的底层服务 }, { id: 4, name: 分布式锁, type: 组件, description: 库存服务中用于资源控制的组件 } ], relations: [ { source: 1, target: 2, type: 调用, description: 用户服务调用订单服务接口 }, { source: 2, target: 3, type: 依赖, description: 订单服务依赖库存服务 }, { source: 3, target: 4, type: 使用, description: 库存服务使用分布式锁 } ] }验证是否成功的三条标准输出是合法的 JSON解析没有报错。实体数量大于等于 3且实体之间有边连接。关系类型和因果关系与原文一致。比如原文说“库存服务节点 CPU 使用率过高导致订单链路变慢”图谱里就应该有从“CPU 使用率”指向“订单服务响应时间”的“导致”关系。如果运行失败优先看三个方面API Key 是否有权限、网络是否能访问模型服务、System Prompt 是否明确要求只输出 JSON。多数解析错误都出在第三个环节——模型输出了多余的说明文字导致json.loads失败。7. 常见问题与排查方法问题现象可能原因排查方式解决方案JSON 解析失败模型输出了 Markdown 代码块或多于 JSON 的文字打印原始返回的 content 查看在 System Prompt 中强调“只输出 JSON不要输出代码块”并考虑使用response_format{type: json_object}实体抽取过于零散Prompt 中没有约束实体粒度查看实体的类型分布确认是否出现“是”“的”等无意义词在 Prompt 中添加“只能抽取有业务含义的实体忽略修饰词和虚词”实体名称不一致同一个实体被抽成多个不同 ID检查模型输出的 name 字段是否出现“订单服务”和“订单系统”混用在 Prompt 中增加“同一实体只能保留一个规范名称如果指向对象相同合并成一个实体”图谱边数过多关系抽取阈值过低检查是否有大量重复或无意义关系限制关系数量比如“只保留最重要的10条关系按重要程度排序输出”剪贴板监听不生效有些软件会阻止读取剪贴板测试复制后手动粘贴是否正常改用系统级剪贴板 API或为浏览器/IDE 场景开发插件直接读取选区这里最值得提的是第一种问题。即使加了response_format部分模型服务仍可能返回非严格 JSON。防御性做法是在解析前用正则提取 JSON 块import re def extract_json(content: str): match re.search(r\{.*\}, content, re.DOTALL) if match: return json.loads(match.group()) raise ValueError(未找到 JSON 内容)生产级实现里还应该对 JSON Schema 做校验确保entities和relations字段存在且类型正确。8. 最佳实践与工程建议8.1 Prompt 设计是图谱质量的核心很多人以为“选中即问”的难点在可视化或前端交互实际使用下来会发现最容易拉开质量差距的是 Prompt。我建议在 System Prompt 中至少固定三个东西实体类型白名单、关系类型白名单、输出样例。固定实体类型非常关键。如果不限制模型会把“服务”“组件”“人”“事件”混在一起输出图会变得杂乱。一个可行的做法是在 Prompt 里写明本次分析关注哪些类型不相关类型一律不抽取。比如日志分析场景这样写实体类型仅限于服务、节点、接口、组件、异常、指标。不要抽取与这些类型无关的对象。关系类型同理。关系类型越少图谱的可读性越高。类型太多会导致语义重叠比如“导致”“引发”“造成”本来就是一个意思。8.2 上下文窗口裁剪策略选区文本可能只是长文档的一小段但模型需要理解上下文才能准确分析。这是“选中即问”产品设计里最容易被忽视的问题。推荐策略是以选区为中心向前截取 N 个字符、向后截取 M 个字符组装成完整上下文。N 和 M 的取值取决于实际场景代码分析可以取 500 字左右日志分析可以取 1000 字左右具体需要测试调优。需要注意在没有好好裁剪上下文的情况下直接把整份文档塞给模型可能使请求超时、成本暴涨而且选区关系会被淹没在大量无关信息中。8.3 图谱结果的缓存与增量更新“选中即问”虽然强调即时性但高频重复分析同一段文本会产生浪费。工程上可以做两层缓存第一层是文本哈希缓存。对选中文本做哈希如果命中缓存且版本没有变化直接返回历史结果。第二层是会话级缓存。在一次对话会话中如果用户逐步扩大选区可以只重新分析新增的部分而不是全部重新生成。增量更新在技术上比较复杂但很值得做。比如用户第一次选中了前两行日志第二次选中了前十行如果两次结果之间大量实体和关系是重叠的可以用图合并的方式更新而不是整体重新生成。8.4 安全与权限边界在浏览器场景中“选中即问”天然可以访问页面内容这就带来隐私问题。如果页面是内网系统、包含客户数据或敏感代码把选区直接发送到第三方大模型服务存在泄露风险。工程建议如下提供可配置的分析后端允许企业接入私有化部署的大模型服务。对选区内容做脱敏处理比如替换手机号、身份证号、内部域名等敏感信息后再发送。明确在 UI 上提示“当前文本将被发送到模型服务分析”避免用户无感知地泄露数据。对访问权限做控制不同角色可使用的分析能力不同。这些不是锦上添花而是在企业内部落地时必须考虑的问题。8.5 从对话到追问好的“选中即问”工具不会在图生成之后就结束。用户点选图谱中的某个节点后应该能继续提问“这个服务和下游服务之间有什么异常模式”“这个实体的相邻实体有哪些”这就是图结构带来的独特优势——对话式 AI 只能靠用户继续描述问题而图结构天然支持基于邻接关系的探索。实现上可以这样设计用户点击节点后系统把节点信息和相邻关系拼接成一个新的 prompt 片段然后基于这段上下文引导追问。这种“图辅助的主动追问”会让工具从“被动回答”进化为“主动引导”也是 DeepGraph 这类工具最有想象力的部分。8.6 与 RAG 的结合点如果把“选中即问”放在更大的 RAG 体系里看它其实是“查询时上下文构建”的一个特例。传统 RAG 通过向量相似度检索出相关文档片段再把片段拼进 promptDeepGraph 的“选中即问”则让用户直接指定了分析范围省略了检索这一步。两者未来可能融合的方向是用户选中文本后系统不只是分析选区还会自动检索与其相关的历史文档、历史故障记录、历史代码变更合并进图谱生成过程。这样图谱就不再是单篇文本的关系图而是“选区 相关历史”的上下文关系图。这也是我认为“选中即问”从工具走向平台的关键能力。9. 总结与进一步实践方向DeepGraph“选中即问”真正解决的是交互摩擦问题。它把大模型从一个独立的对话窗口嵌入到了阅读、代码审查、日志排查这些具体工作流里让“让 AI 分析一下”的成本无限趋近于零。它的核心价值不是图谱本身而是图谱作为结构化结果带来的下一步操作可能性。如果你准备上手实践我建议按这个顺序走一遍先用本文的 Python 示例跑通“剪贴板 - 分析 - JSON”的最小闭环。设计一个你自己的工作场景调整实体类型和关系类型跑一批真实数据看看抽取质量。尝试接入图可视化组件把 JSON 渲染成可交互的图。加入缓存、脱敏、追问等工程化能力做成一个可分享给团队的小工具。进一步值得深入的方向包括关系抽取的错误修复机制、基于图谱的主动追问策略、以及与结构化数据的融合分析。这些方向单独拿出来都够写几篇深度文章后续我会逐步更新。建议先把本文示例跑通遇到实际问题再回来对照排查表。如果你对这个话题有自己的实践经验和踩坑记录欢迎在评论区交流。