打开本地项目文件夹几十个以日期和数字命名的存档里“A Game of Thrones(83)” 格外显眼。别误会这不是剧集第83集也不是原著第83章而是我为了弄懂这部作品里盘根错节的人物关系迭代到第83版的数据项目存档。很多人说《权力的游戏》最厉害的地方是“猜不到谁下一秒会死”但作为一个常年和数据打交道的作者我始终觉得它真正厉害的地方是把一堆人物关系像棋盘一样摊开让每一个选择都像落子一样产生连锁反应。为了验证这个想法我把原著文本、人物关系、家族领地这些材料揉在一起做了一个关系图谱和推演模拟器。这篇文章就从“为什么一个文学作品会让我想到建图建模”说起记录我从零到一建设这个项目的过程以及那些常规文档里不会写的坑。1. 为什么我非要给“权力的游戏”建一个关系模型1.1 权游的复杂来自关系网络而不是剧情节点如果你只是按时间线看权游很容易陷入“谁登场了、谁死了、谁和谁打起来了”的列表式记忆。但真正让这个故事区别于普通宫廷剧的是人物之间那条看不见的关系网。举个简单的例子一个角色在关键时刻背叛另一个角色表面上看只是一瞬间的决定但往前翻好几季你会发现他们之间早就埋了长线可能是家族旧怨可能是某次联姻的副作用也可能是第三方刻意制造的误会。单看剧情节点这些全是“跳跃”的可一旦把关系边画出来一切又会变得异常顺滑。我最早想做的就是把这种“顺滑感”变成一张可以看得见的图。每个角色是一个节点角色之间的关系是一条边边的正负和粗细代表合作、效忠、仇恨、血缘。听起来很简单但真正动手之后才发现这部作品的复杂程度远超想象主线角色加配角上百人家族之间的联姻、人质、地盘、盟友关系交错在一起光靠人工梳理根本梳理不完。这也是为什么我需要用图模型来做而不是继续靠脑补。1.2 项目目标不是预测剧情而是还原“信息差”做图之前我给自己定了个规矩这项目不预测谁会死也不做“强行剧透”。权游最迷人的地方恰恰是读者和角色之间存在大量的信息差。POV写法让每一章都只能从一个视角去看世界读者知道的事往往比某个角色多也可能比某个角色少。很多悲剧不是因为角色愚蠢而是因为每个人都只拿着拼图的一部分。所以我的目标变成了另一件事用一个关系模型去还原“每个角色在某个时间点掌握了哪些关系”。如果把人物关系图当成一张完整的棋盘那每个角色看到的其实只是棋盘上的一小块。项目要做的不是展示上帝视角而是模拟出不同角色的“局部视角”。这个目标听起来更温和可做起来反而更有意思因为它逼着我去整理每一条关系的“可见时间”和“可见范围”后来还直接推动了模拟器的设计。1.3 83个版本是怎么攒出来的项目文件夹为什么叫“83”因为真的改了83版。第一版特别幼稚就是把所有角色塞进一张静态图连线密密麻麻根本没法看。第二版好一点按家族给节点上了颜色。第三版加了时间轴滑动能看到关系随剧情变化。第四版开始做关系权重第五版调整布局……后来我越来越觉得光“看”还不够得让这张图“动起来”于是又加了事件推演、回合制模拟、可视化交互。每加一个新想法就可能推翻前面不少设计文件名里的数字就这样一路涨到了83。这个过程让我特别有感触做内容项目也好做技术项目也好最不值钱的是“想法”最值钱的是“迭代后的废弃文件”。83这个数字不是用来炫耀勤奋的而是用来提醒我好结构不是一次设计出来的是反复调整出来的。2. 数据清洗与关系抽取最容易劝退人的环节2.1 数据来源与字段设计建模型的第一步是搞数据。我手上没有官方数据库也不可能手动录入几百个角色所以整合了三类公开来源角色列表、章节POV信息、以及由爱好者整理的角色关系表。另外我还从原著文本里跑了一遍实体识别把每个章节里同时出现的人物名抓出来作为“共同出现”的辅助信号。整个项目最后落在三张表上结构大致是表名关键字段说明charactersid, name, aliases, house, alive角色主表aliases用来存别名relationssource_id, target_id, rel_type, weight, reveal_chapter关系边表记录类型、权重和首次出现章节eventsevent_id, event_type, involved_nodes, consequence事件表用于驱动模拟器的事件卡这三张表看着简单实际上是整个项目的骨架。最难的不是设计字段而是把零散的、互相矛盾的文本信息统一进去。同一个角色在不同资料里的名字可能不一样同一个事件有的资料说是阴谋、有的资料说是意外这些冲突必须在清洗阶段就解决否则后面所有算法结果都会被带偏。2.2 处理角色别名同一个人的三个名字权游里角色别名多到离谱有人用全名有人用绰号有人用私生子的家族姓同一个角色在不同章节里常常以完全不同的词出现。如果你不做别名表实体识别会把一个人当成好几个人图里就会冒出一堆幽灵节点。我的办法是建一个aliases表把主ID和所有可能的写法绑定。比如一个私生子角色早期叫“雪诺”后来有了新身份名字也跟着变再比如一些角色有头衔、有外号、有真名这些全都要映射到同一个ID上。清洗完这一层节点数量立刻缩水了差不多三分之一很多原本看起来没关系的角色其实只是被你拆成了两个ID。这里有个小教训别信现成的实体识别结果一定要自己抽检。我当时随机抽了五十组识别结果去人工核对至少五组有合并或拆分错误。比例看着不高但到了图算法阶段一点点噪声都会被放大。2.3 血缘、效忠、敌对三类关系怎么打权重有了节点下一步是给边定权重。我一开始贪心把所有关系都当成平等的一类结果图变得平面化看不出主次。后来我把关系分成三大类血缘、效忠、敌对每一类给不同的权重区间。关系类型权重区间说明血缘8-10父母、子女、兄弟姐妹天然绑定效忠3-5封臣对领主、侍卫对主人、盟友之间敌对6-15有明确冲突事件则高纯言语厌恶则低这个权重设计不是拍脑袋。血缘关系最稳定所以给高基础分效忠关系会随局势变化但不能太低否则体现不出封建体系的力量敌对关系则要拉开方差因为“打过一仗”和“互相看不顺眼”完全不是一回事。权游里敌对关系的破坏力往往大于血缘所以上限给得比血缘还高。这条规则很快就在图里体现出来了一些在剧情里呼风唤雨的家族并不是因为盟友多而是因为敌对关系带来的“被关注度”太高让他们天然处在冲突中心。2.4 代码实现把表变成有向图数据清洗完接数据建模其实只有十几行代码。我用的是 Python 生态里的 NetworkX它非常适合这种中小规模的图计算。import pandas as pd import networkx as nx df pd.read_csv(relations.csv) G nx.DiGraph() for row in df.itertuples(): G.add_edge( row.source_id, row.target_id, rel_typerow.rel_type, weightrow.weight, reveal_chapterrow.reveal_chapter )这里我刻意选了有向图而不是无向图。原因是“效忠”和“敌对”都有方向A效忠B不意味着B也效忠AA恨B也不代表B恨A。如果全用无向边很多关键信息会丢失。当然血缘关系天生是双向的所以我在导数据时会把血缘边同时加两个方向但权重折半避免一条血缘关系被算成两条独立关系。跑完基础统计我有点吃惊节点数一百多边数比预想的多得多平均每个角色和七八个角色有关系。这说明权游的核心角色确实被编织在一张高密度的关系网里这也为后面的中心度分析埋下了伏笔。3. 图算法跑完我发现“权力中心”不是你想的那个人3.1 用PageRank模拟影响力和信息流动如果说建图是搭骨架那跑算法就是第一次给这张图“注入血液”。我最想看的指标是到底谁才是这张关系网里真正的权力中心。单纯数关系数量太粗糙所以我用了PageRank算法——也就是搜索引擎判断网页重要性的那套逻辑。放在故事里它的意思变成了一个角色是否重要取决于他是否被其他重要角色关注、依赖或敌视。pr nx.pagerank(G, alpha0.85, weightweight) top_nodes sorted(pr.items(), keylambda x: x[1], reverseTrue)[:10]跑了之后前十名里确实有几个手握重兵的王位竞争者但真正的榜首却是一个情报总管。这个结果让我一下子明白了什么叫“信息即权力”。他在绝大多数冲突里不是亲自挥剑的人却是几乎所有关键人物都会接触的信息节点。国王需要他王后需要他连流亡者也愿意听他说话。PageRank抓到的不是“谁最能打”而是“谁在关系网上最绕不开”。这个发现给了我很大的冲击我们看剧时容易记住那些站在铁王座前讲话的人但真正维系整张关系网的往往是坐在信息交叉点上的人。权力不只是军队和血统更是连接所有人关系的那条路径。3.2 Louvain社区发现阵营不是按地图画的光看中心度还不够我还想知道如果把关系网自动分成几个派系算法分出来的会和地图上的家族板块一致吗我用 Louvain 社区发现算法跑了一遍结果挺颠覆认知。预期里“每个家族一个cluster”实际跑出来是“跨家族的联盟cluster”。比如某个以北方为核心的家族并不只和自家人聚在一起而是和多个联姻家族、盟友、甚至曾经的敌人因为共同的短期利益被分进同一社区。更妙的是同一个家族内部有时会出现分裂信号家族成员分别被算法分到了不同社区原因是他们效忠的对象不同长期目标也不同。这个结果让我重新理解了“阵营”这个词。地图上的颜色是不变的但人物关系里的“社区”是随权重变化的。你今天和谁联姻明天就会被算法划进谁的阵营。权游讲的根本不是地图边界而是关系边界的持续重构。3.3 最短路径揭示“阴谋捷径”另一个有趣的算法是最短路径。权游里很多阴谋之所以成立是因为两个看似遥远的人之间其实存在着一条极短的“路径”。我做了个小实验随机挑两组看起来势不两立的人计算他们之间的关系最短路径。结果中间往往只隔着一两个关键联系人。这给我一种“六度分隔”照进维斯特洛的感觉。一个在北境边缘的贵族和一个在君临权力中心的人最短路径可能只经过一个到处旅行的情报贩子、一个当过俘虏的骑士、或者一个两边都不得罪的商人。任何两条线之间的桥梁角色都比他的头衔更值得警惕。对于创作者来说这个算法特别有启发如果你想写一场“所有人都没想到”的联合可以先画一张关系图找一找两个阵营之间最短路径上的人让这个中间人成为暗线。权游里那些看似突然的联姻和背叛很多都是借这种“路径捷径”完成的。3.4 一个容易被忽略的边权重陷阱这一节必须单独拿出来写因为我在这个坑里蹲了很久。一开始我偷懒把“两个角色共同出现的章节数”直接当成关系权重同框次数越多边越粗。结果跑出来中心度榜单前排全是“御前会议常驻成员”“跟着主角长途旅行的跟班”这类人因为他们戏份多、同框多但并不掌握真正的权力。这个噪声本质上来自“共同出现”和“真实互动”的区别。两个人出现在同一场婚礼上不代表他们之间有有效关系两个人虽然是陌生人却可能因为一纸婚约被绑在一起。我后来把共同出现权重降为辅助信号把血缘、效忠、敌对这些明确事件作为主权重结果才变得可信。所以给想做类似项目的人一个建议关系数据贵精不贵多别把“共现”当“关系”。先把强关系的边打牢再拿弱关系做补充否则算法会被这种虚高权重直接带偏。4. 从图到模拟器把静态关系变成看得见的权力更迭4.1 模拟器的三个核心规则静态图看久了会腻而且它只能回答“现在谁和谁有关”回答不了“下一步谁和谁决裂”。于是在第50版左右我开始把图改造成模拟器。我的想法是做一个极简回合制推演每个角色不是被剧本推着走而是被关系网络推着走。规则定得很克制一共三条每个角色拥有三个内部状态忠诚倾向、当前影响力、存活状态。每个回合随机抽取一张事件卡事件卡会改变若干条边的权重或触发节点属性变化。每个势力的总影响力等于它在当前关系图中所在连通分量内所有存活角色的影响力之和。这三条规则看着简单但组合起来效果很惊人。随机事件卡保证了故事不会走向唯一的“理性最优解”忠诚倾向和个人恩怨又会把结果越推越偏。权游里很多灾难不正是这样来的吗每个人都按自己的局部理性做选择最后合起来却是全局失控。4.2 回合制推演中的状态更新逻辑模拟器的核心代码并不复杂最麻烦的是每回合都要重新计算一次影响力分布。我用PageRank作为影响力的动态来源事件卡先修改图结构再重新计算PageRank然后把新数值写回节点状态。import random events [betrayal, marriage, assassination, alliance, war] event_probs [0.2, 0.15, 0.2, 0.25, 0.2] for turn in range(20): event random.choices(events, weightsevent_probs)[0] apply_event(G, event, turn) influence nx.pagerank(G, alpha0.85) for node in G.nodes: G.nodes[node][influence] influence[node] record_state(node_states, turn)这么做的好处是每一次事件都不会只影响当事人。一场联姻会合并两个家族的若干条关系边一次暗杀会让所有指向被杀者的边失重。这非常像故事里的“蝴蝶效应”角色A的一封密信最终可能改变角色H的命运只是因为中间隔着一整条关系网。4.3 在83版里我自己跑出的一场小规模混战我不想让这个项目变成一个“预先写好的演示”所以故意把初始关系设置在某卷开篇的节点然后跑20个回合看看随机事件会把局势推向哪里。第一次跑出的结果就很有意思一个边缘家族因为连续抽到两次联姻事件和一次背叛事件迅速成了连接两个敌对阵营的枢纽总影响力一路飙升而另一个开局巨头因为核心角色接连卷入暗杀事件盟友纷纷解除效忠最终从第一梯队滑落。我当然知道这不是剧情预测权游的剧本有创作者的主观设计不可能被随机规则复现。但这个实验让我直观地理解了“权力是流质的”关系网络里没有一个节点的位置是永久固定的一次微小的边权重调整可能让中心迁移。真实故事里的那些“突然反转”放到模拟器里其实只是某些关键边的增删。4.4 可视化交互上踩过的真实坑模拟器跑通了接下来就是让结果能被看见。这一块踩的坑比建模阶段还多。第一版用标准力导向布局节点老是飘来飘去上一秒还看的连线下一秒就被弹开浏览器窗口大小一变布局就像抽风一样重排。后来我不得不给节点设置固定初始位置并锁定拖动后的坐标才让画面稳定下来。节点标签重叠也是个老大难。关系网一密标签就会互相盖住。最后我只能做分层展示默认只显示阵营标签选中某个角色时才展开他的邻居标签。加上边的颜色和图例之后图才开始真正做到“可读”。性能方面超过一百个节点、几百条边的图如果用简单DOM渲染会明显掉帧这个规模最好交给Canvas或WebGL方案处理。推广到任何做可视化项目的朋友先想清楚“用户要读的是关系不是看线条跳舞”。再酷炫的动态效果如果让你看不清节点和边就是负优化。5. 做完之后我重新理解了“权力的游戏”这五个字5.1 叙事不是链状是网状的在建完图、跑完算法、做完模拟器之后再回头看权游我的感受完全不一样了。以前我觉得它的剧情是一条接一条的支线推进现在我知道它是一张密度极高的网。每个角色的动机来自他在网上的位置而不只是他内心的“善恶”。那些被观众吐槽“转变突兀”的角色如果放回关系网里其实早有征兆只是你只盯着他一个人的剧情线没看到他身上那些边的变化。这个认知可以直接迁移到内容创作上。如果你也在写多人物故事建议列一张“信任与仇恨清单”把每个角色和其他人的关系权重都标出来。很多让人记住的情节往往不是孤立事件而是某条边从正变负、从弱变强的瞬间。5.2 “信息差”才是编剧最大的武器除了网络结构这个项目还让我看清了一件事权游最锋利的不是刀剑是信息差。POV结构让每个视点角色都只能看到关系子图的一部分读者跟着某个角色走会误以为自己掌握了全局。可一旦把全局图铺开你会发现真正的冲突往往来自两个角色各自拥有半条信息却没有机会交换。我在模拟器里也做了类似的约束每张事件卡只对特定阵营可见模拟过程中会生成一份“角色感知偏差报告”。报告里经常出现令人毛骨悚然的发现一个角色以为自己的盟友稳如泰山但在全局图上那位盟友已经被另一边的高权重关系拉走了。权游的悲剧感很大程度就来自这种“各自为政的信息孤岛”。对一个写故事的人而言这或许是比“反转”更高级的技巧不是让读者什么都不知道而是让读者知道得比角色多一些、又不完全多。差出的那一点就是悬念和共情的双重来源。5.3 这套建模方法还能用在哪儿项目做完之后我把这套“关系建模”的思路抽离出来发现它远远不限于这部作品。做舆情分析时可以用来观察关键账号之间的传播路径做游戏时可以用来测试角色平衡性看谁天然处在中心位置做小说设定时可以用来检查世界观是否自洽避免出现“明明有深仇大恨的角色突然亲如兄弟”这种设定断裂。我现在手头正在试的一个新项目是把这套图思维用到短篇故事生成上先随机生成一张小规模关系网再让它演算出几条冲突线最后由我改写成文章。效果还不够稳定但方向让我兴奋。说到底一个故事和一张关系网络遵循着同一个逻辑连接产生力量而力量一旦偏离预期的方向就成了冲突。83个版本的迭代没有白费它让我换了一双眼睛看故事也看清楚了那些藏在文本背后、从不明说却始终在运作的关系。
