12 lines
7.8 KiB
JSON
12 lines
7.8 KiB
JSON
{
|
||
"ok": true,
|
||
"identity": "user",
|
||
"data": {
|
||
"document": {
|
||
"content": "<title>2026.06.23-日报-莫润麟</title><h3>今日内容</h3><p><b>① 重新梳理博弈论建模思路</b></p><p><b>② 互补性机制变量优化</b></p><p><b>③ 核对当前入库变量问题</b></p><h3>一、重新梳理博弈论建模思路</h3><callout emoji=\"🔎\"><p>重新梳理了博弈论建模的思路:不能直接照搬昨天 Park & van der Schaar 那篇论文的思路。</p><p>当前判断是:</p><blockquote><p>可以借鉴其“<b>基础模型→机制扩展→均衡比较</b>”的研究思路,但不<b>能直接照搬其“一个机制对应一个模型”的方法。</b></p></blockquote><p>原因在于,<b>两者的研究场景存在本质区别。</b></p><ul><li>Park & van der Schaar 更多是在比较不同激励机制方案之间的效果,其<b>机制之间具有一定替代关系</b>;</li><li>而本文研究的公平性、激励性、私有性等规则机制,并不是互斥关系,而是<b>在同一场竞赛中同时存在的平台规则组合。</b></li></ul><p>因此,不能简单拆成:公平性模型,激励性模型、 私有性模型分别独立分析,而要在<b>统一博弈论框架下刻画多个机制的共同作用。</b></p></callout><p></p><blockquote><p>更适合采用:<b>分步引入、联合收束</b>的建模方式。</p></blockquote><h3>分步引入</h3><p><b>先建立最基础的收益函数,说明玩家投入本质上是在权衡收益与成本。</b></p><p>随后逐步加入不同机制:</p><ul><li> 激励性机制:说明奖励价值如何影响投入意愿; </li><li> 私有性机制:说明个人贡献如何转化为个人回报; </li><li> 公平性 / 补偿性机制:说明投入是否能够有效改变结果; </li><li> 后续再结合重点机制筛选结果,进一步补充互动性、互补性或流动性等机制。 </li></ul><callout emoji=\"🔎\"><p>目的是<b>让每个机制影响收益函数的位置和作用路径更加清晰</b>,避免一开始把所有机制混在一起,导致逻辑难以解释。</p></callout><h3>联合收束</h3><p>虽然分析时分步展开,但最终不能把机制彼此割裂。</p><p>因为在真实竞赛中,玩家做投入决策时,会同时考虑:</p><ul><li> 奖励值不值得争; </li><li> 自己能否获得回报; </li><li> 赛局是否还有胜算; </li><li> 投入是否能够有效转化为竞争优势。 </li></ul><callout emoji=\"🔎\"><p>最终需要回到统一收益函数中,刻画多个机制共同作用下的均衡投入。</p><p><b>这样能讲清楚单个机制的作用路径,也能够反映真实游戏规则是同时发挥作用的。</b></p></callout><h4>(二)进一步明确统一收益函数思路</h4><p><b>当前逐渐明确,后续理论部分不应把各机制割裂成独立模型,而应先建立统一的收益(效用)函数。</b></p><p>核心逻辑是:</p><blockquote><p><b>玩家在投入过程中,本质上是在权衡收益与成本,并根据边际收益变化不断调整投入水平。</b></p></blockquote><p>因此,后续可以围绕:</p><ul><li> <b>收益</b></li><li><b> 成本</b></li><li><b> 竞争结果</b></li><li><b> 收益分配</b></li></ul><callout emoji=\"🗯️\"><p><b>建立统一收益函数,再逐步分析不同机制如何改变收益结构和均衡结果。</b></p></callout><h4><b>一阶最优条件(FOC,First-Order Condition)</b></h4><p>进一步补充了一阶最优条件(FOC)相关知识</p><p>FOC 的核心思想是:</p><blockquote><p><b>玩家会持续投入,直到增加一单位投入带来的边际收益,恰好等于增加一单位投入带来的边际成本。</b></p></blockquote><p>即:<b><u>边际收益 = 边际成本</u></b></p><ul><li>从数学上看<b>,</b><b>FOC 来源于效用(收益)函数最大化过程,对投入变量求导并令导数等于零</b>,得到均衡投入条件。</li></ul><p>进一步理解,玩家是否继续投入,本质上是在不断比较:</p><ul><li><b> 多投入一点能够带来多少额外收益; </b></li><li><b> 多投入一点需要付出多少额外成本</b>。 </li></ul><callout emoji=\"🔎\"><p>当边际收益大于边际成本时,玩家会继续追加投入;</p><p>当边际收益小于边际成本时,玩家会减少投入;</p><p>最终在两者相等的位置形成均衡投入。</p></callout><p><b>对本文的启发</b></p><p>FOC 的价值在于:</p><blockquote><p><b>它能够把“为什么玩家愿意投入”从经验描述转化为数学上的均衡条件</b>。</p></blockquote><p>后续不同规则机制影响综合投入,本质上都可以理解为:</p><ul><li><b> 提高边际收益; </b></li><li><b> 降低边际成本; </b></li><li><b> 或改变投入对结果的转化效率。 </b></li></ul><callout emoji=\"🤔\"><p>因此,机制作用并不是直接决定玩家是否投入,而是通过改变边际收益—边际成本关系,进一步影响玩家的最优投入水平。</p></callout><p></p><p></p><hr/><h3>二、互补性机制优化</h3><p>继续优化互补性机制的定义,将原来以建筑、委派、buff 等“玩法协同”变量为主的口径,调整为更贴近论文主问题的 <b>K-L 投入结构关系</b>。</p><p>当前更关注的问题是:</p><ul><li> 金钱投入 K 与行为投入 L 是互补还是替代; </li><li> 高 K 玩家是否同时表现出高 L; </li><li> 金钱投入是否通过资源、兵力和加速机制带来更多行为机会。 </li></ul><p>阶段判断:</p><blockquote><p>互补性不再主要回答“有没有 buff”,而是回答“金钱投入与行为投入如何共同作用”。</p></blockquote><h4>(一)重新梳理互补性机制链条</h4><p>结合实际玩法,当前元宝和付费更多是缩短等待时间、补充兵力和资源,而不是直接替代行为本身。</p><p>当前更合理的机制链条为:</p><p><b>金钱/元宝投入→ 缩短等待时间、补充兵力资源→ 增加继续行动机会→ 提高行为投入 L→ 推动综合投入</b></p><p>因此,互补性更偏向解释:</p><blockquote><p><b>金钱投入如何放大行为投入,而不是简单替代行为投入。</b></p></blockquote><h4>(二)完成第一版 K-L 结构变量构建</h4><p>基于 5 月统一口径玩家期表,完成第一版 K-L 投入结构变量构建。</p><p>主要包括:</p><ul><li><b> K-L 投入差值; </b></li><li><b> K/L 投入占比; </b></li><li><b> K-L 均衡度; </b></li><li><b> K-L 双高交互强度; </b></li><li><b> 兵力消耗型行为投入; </b></li><li><b> 金钱—兵力消耗交互强度; </b></li><li><b> K-L 投入结构类型</b>。 </li></ul><p>数据检查结果:</p><ul><li> <b>样本量:50,579; </b></li><li><b> activity 数:666; </b></li><li><b> 关键字段缺失率:0; </b></li><li><b> K 与 L 相关系数:0.48; </b></li><li><b> K 与兵力消耗相关系数:0.40; </b></li><li><b> L 与兵力消耗相关系数:0.94。 </b></li></ul><p>K-L 类型分布显示:</p><ul><li> 双高互补型玩家占比(17.08%)明显高于高 K 低 L 型和低 K 高 L 型。 </li></ul><p>初步结果更支持:</p><blockquote><p>金钱投入与行为投入存在互补关系,而不是简单的替代关系。</p></blockquote><h4>(三)明确变量使用边界</h4><p>由于综合投入 Y 本身由 K 与 L 构成,<b>因此 K-L 派生变量不适合直接进入预测主模型,以避免同源泄漏</b>。</p><p>这些变量更适合用于:</p><ul><li> K/L 子模型; </li><li> 玩家类型划分; </li><li> 替代关系检验; </li><li> 机制细化和论文解释。 </li></ul><p>建筑、委派、buff 等变量暂不废弃,后续更适合作为辅助解释变量,用于说明 K-L 互补关系为何产生</p><p></p>",
|
||
"document_id": "G1q2ddC9uo1d3LxWS2KcoFqenJg",
|
||
"revision_id": 250
|
||
}
|
||
}
|
||
}
|