C#无法直接构建知识图谱，需组合文本解析、规则/轻量模型识别实体关系，再导出nodes.json和edges.json；应避免高成本NLP库，优先词典+正则，调用HanLP/Flair服务，注意隐含关系、跨句指代、否定条件三类漏边，并规范导出字段名与路径。
怎么用 C# 从纯文本里抽实体和关系
不能直接“构建知识图谱”——C# 本身没有内置的 NLP 或图谱推理能力，得靠组合：先做基础文本解析，再用规则或轻量模型识别实体和关系，最后导出为 nodes.json 和 edges.json 这类结构化数据。别指望 File.ReadAllText 后调个方法就出来三元组。
常见错误是把“知识图谱”当黑盒目标，结果卡在第一步：连人名、地名都分不准。真实场景中，90% 的文本没标注、没句法树、甚至没标点，必须接受“低精度但可调试”的起点。
- 优先用基于词典+正则的硬匹配（比如识别
公司名：后的冒号后内容），不是所有项目都适合上spaCy或StanfordNLP - 避免直接喂整篇长文给 NER 模型——切句比切段更稳，用
Regex.Split(text, @"[。！？；\n]+")比text.Split('\n')更靠谱 - 中文需额外处理：
“张三，李四，王五”是三人并列，不是“张三，李四”和“李四，王五”两个关系，得加去重逻辑
C# 里哪些 NLP 库真能跑起来
别碰 ML.NET 的 TextClassification 做实体识别——它不支持细粒度标签（如 PER/ORG/LOC），训练成本高且效果弱于专用 NER 工具。真正可用的只有两类：
-
Stanford.NLP.CoreNLP（Java 依赖，需JVM+IKVM，Windows 上容易崩在java.lang.UnsatisfiedLinkError） -
SharpNLP（已停更，仅支持英文，Tokenizer对中文完全失效） - 推荐折中方案：起一个本地
Flair或HanLPHTTP 服务，C# 用HttpClient调用，传{"text": "xxx"}，收{"entities": [...], "relations": [...]}
性能上，单次请求平均 120–300ms，吞吐量取决于你愿不愿意开连接池和批量接口。别让 HttpClient 在循环里 new——那是 SocketException: Too many open files 的直通车。
关系抽取最容易漏掉的三种情况
关系不是靠“主谓宾”语法树就能稳抓的。C# 做规则匹配时，这三类文本结构最常导致漏边：
- 隐含关系：文本写
“腾讯收购了搜狗”，但没出现“收购方”/“被收购方”字样，需预置动词映射表：new Dictionary<string string> { {"收购", "acquired"}, {"投资", "invested_in"} }</string> - 跨句指代：前句
“马化腾出席发布会。”，后句“他宣布新战略。”，不解决共指消解，"他"就永远是孤节点 - 否定与条件：
“除非监管批准，否则不合并”这种句子，硬抽会得到错误的(A, merged_with, B)边，得先过滤含"除非"、"未获"、"暂缓"的句子
没做这三步，导出的图谱里会出现大量虚假连接，后期查证成本远高于前期加规则。
导出知识图谱结构时路径和格式怎么设
别直接写 JsonConvert.SerializeObject(graph) 就完事。图谱消费端（比如 Neo4j、Gephi 或前端 vis.js）对字段名极其敏感：
- 节点必须含
"id"（字符串或数字均可，但全局唯一），不能叫"nodeId"或"uid"，否则cypher LOAD CSV会跳过整行 - 关系必须含
"source"和"target"（对应节点的id值），不是"from"/"to"，也不是索引下标 - 文件路径别用
@"C:\data\nodes.json"——部署到 Linux 容器时路径炸裂，统一走Path.Combine(AppContext.BaseDirectory, "output", "nodes.json")
多写一行验证逻辑：if (node.id == null) throw new InvalidOperationException("node.id is required");，比后期在图数据库里 debug 三元组缺失快十倍。
