km.idaeo.ai · IDAEO 知識庫

🏛 本文属于主题馆「ai」

X 算法拆解证据总表

本篇汇整 X 推荐算法开源项目的 58 项机器命题验证数据与源代码路径,逐行解析行为权重、过滤器管线与可见度规则。适合需要精确源代码依据、验证脚本与技术规格的工程师与研究人员参考。

xai-org / x-algorithm · HEAD a389166

每一条主张都附源代码位置与复现指令。所有数字由脚本实跑产生,非人工转录。

仓库 xai-org/x-algorithm(2026-08-13 更新) HEAD a389166f6cf5da70a286b568c87695d4dcdce3a1 规模 2,015 档 / 21 MB / 5 commits 判读 2026-08-14 验证 58 条机器命题,58 PASS / 0 FAIL 自验 注入错误期望值 → 正确产生 1 FAIL(闸门有效)

① 机器命题验证表

下表 58 条全部由 verify-all.sh 实跑产生,本页数值直接由该脚本输出转成表格, 没有经过人工抄写。脚本本体见附录。

should-FAIL:故意喂已知错值,证明检查器真的会挡
should-FAIL:故意喂已知错值,证明检查器真的会挡
项目数值说明
PASS58
FAIL0
should-FAIL 反例验(注入错值必须被抓到)1
编号命题实测值结果
C01HEADa389166f6cf5da70a286b568c87695d4dcdce3a1PASS
C02param!区块数183PASS
C03文件总数2015PASS
C04FavoriteWeight0.5PASS
C05ReplyWeight5.0PASS
C06RetweetWeight1.0PASS
C07ShareViaCopyLinkWeight20.0PASS
C08ReportWeight-234.0PASS
C09MuteAuthorWeight-58.8PASS
C10BlockAuthorWeight-31.2PASS
C11NotInterestedWeight-43.2PASS
C12NEW_USER_OON_WEIGHT_FACTOR0.00001PASS
C13NEW_USER_MIN_FOLLOWING5PASS
C14NEGATIVE_SCORES_OFFSET0.001PASS
C15MAX_POST_AGE(秒)172800PASS
C16NewUserAgeThresholdSecs缺省0PASS
C17AuthorDiversityDecay0.5PASS
C18AuthorDiversityFloor0.25PASS
C19OonWeightFactor0.75PASS
C20前置过滤器数17PASS
C21后置过滤器数3PASS
C22filters档数(不含mod)27PASS
C23mod.rs声明数26PASS
C24未声明的filterpopular_topics_author_dedup_filterPASS
C25基本可见度规则数28PASS
C26OON加码规则数26PASS
C27排序器取用预测头数27PASS
C28MinVideoDurationMs10_000PASS
C29EnableQuotedVqvDurationCheckfalsePASS
C30EnableInventoryHoldoutfalsePASS
C31VMRankerSendHeadWeightsfalsePASS
C32Rust侧bridge命中0PASS
C33phoenix [:,:,4] 命中0PASS
C34phoenix [:,:,2] 命中0PASS
C35phoenix [:,:,3] 命中0PASS
C36Rust用ContinuousActionName次数2PASS
C37Rust用的唯一连续动作2PASS
C38BRIDGE_PROBABILITY枚举值4PASS
C39bridge开关设True次数0PASS
C40有损失的连续头种类数1PASS
C41NUM_CONTINUOUS(参考实现)8PASS
C42DWELL_INDEX(参考实现)1PASS
C43history_seq_len1022PASS
C44num_layers8PASS
C45emb_size2560PASS
C46ActionName枚举项数204PASS
C47PLACE_HOLDER占位数8PASS
C48两份proto是否相同samePASS
C49ProfileClickWeight0.0PASS
C50DwellWeight0.0PASS
C51QuotedVqvWeight0.0PASS
C52ContClickDwellTimeWeight0.0PASS
C53ContActiveSecs5mResidualNormWeight0.0PASS
C54BidirectionalFollowDwellWeightBoost0.0PASS
C55BidirectionalFollowReplyWeightBoost15.0PASS
C56ContDwellTimeWeight0.004PASS
C57NotDwelledWeight-0.02PASS
C58名称含Weight的参数数33PASS

② 权重总表

来源 home-mixer/params/param.rs。逐块解析全档 183 个 param! 后筛出名称含 Weight 者共 33 个。数值为代码内置默认值,在线可由 feature switch 覆写。

抽取陷阱(我第一版就中了):这个文件同时存在多行与单行两种 param! 写法。 只扫多行会静默漏掉 13 个——而真正的评分权重全部在那 13 个里面。 实计 170 ≠ grep -c '^param!(' 的 183 才抓到。附录的解析器两种都处理。
同一份东西有两种写法;只认一种的模板会静默漏掉另一种
同一份东西有两种写法;只认一种的模板会静默漏掉另一种

正权重(17 个)

行号参数默认值对应动作
L325ShareViaCopyLinkWeight20.0拷贝链接分享
L284BidirectionalFollowReplyWeightBoost+15.0互相追踪时的回复加成
L283ReplyWeight5.0回复
L319ShareViaDmWeight5.0私讯分享
L332QuoteWeight5.0引用转推
L345FollowAuthorWeight4.0追踪作者
L318ShareWeight2.0一般分享
L296RetweetWeight1.0转推
L246OonWeightFactor0.75未追踪内容折扣系数
L282FavoriteWeight0.5按赞
L266TopicOonWeightFactor0.5主题模式的未追踪折扣
L309ClickWeight0.4点进帖子
L310OpenLinkWeight0.2点外部链接
L297PhotoExpandWeight0.05放大图片
L303VideoOpenWeight0.05开视频
L317VqvWeight0.05视频有效观看
L333QuotedClickWeight0.05点进被引用的原帖子
L351PostUnexploredWeight0.02探索性内容加分
L375ContDwellTimeWeight0.004停留秒数(每秒)

负权重(5 个)

行号参数默认值相当于几次按赞
L442ReportWeight−234.0468
L436MuteAuthorWeight−58.8117.6
L424NotInterestedWeight−43.286.4
L430BlockAuthorWeight−31.262.4
L443NotDwelledWeight−0.020.04
项目数值说明
正权重合计(19 项,不含两个 OON 折扣系数)+43.324
负权重合计(5 项)−367.22
负/正倍数8.48×
这个 8.48 倍怎么读才不会读歪: 比的是权重定价,不是最终分数。进公式的是「权重 × 模型预测概率」, 而检举、封锁的预测概率极小、按赞的概率高得多,所以单则帖子的负面项实际贡献不会是正面的 8.48 倍。 那些概率是模型跑出来的,开源码里没有,无法计算。 成立的说法是:X 对负面信号的定价,比正面信号贵一个数量级

零权重(6 个)

行号参数默认值性质(详见 ⑦)
L311ProfileClickWeight0.0模型有训练,只是定价 0
L331DwellWeight0.0模型有训练,只是定价 0
L339QuotedVqvWeight0.0模型有训练,另有长度闸门
L381ContClickDwellTimeWeight0.0无训练损失=schema 留白
L417ContActiveSecs5mResidualNormWeight0.0无训练损失=schema 留白
L290BidirectionalFollowDwellWeightBoost0.0有守卫有测试的正式关闭开关

第 33 个:一条 19 维的逻辑回归

DwellRegretGateWeightsparam.rs:534)不是单一数值,是 19 个系数的字符串, 输入是你的帐号历史(交互串行长度、按赞数、回复数、负面回馈数、7 日/1 日活跃、 粉丝数、追踪数、帐龄…),输出是「你会不会后悔看了这则」的概率。摘录:

seq_len:0.530298     n_reply:0.485541     n_click:-0.176675
n_fav:-0.082139      n_1d:-0.241730       account_age_years:-0.045455
n_profile_follow:-0.221285                n_negfb:0.031839

③ 评分公式逐行

單項 = 模型預測機率 × 該動作權重                    ranking_scorer.rs:416-418
       fn apply(score: Option<f64>, weight: f64) -> f64 {
           score.unwrap_or(0.0) * weight
       }

26 個單項組成陣列                                   ranking_scorer.rs:470-510

拆成正負兩堆                                        ranking_scorer.rs:513-521
       for t in terms { if t >= 0.0 { pos += t } else { neg -= t } }

combined = pos − neg                                ranking_scorer.rs:427

最後位移                                            ranking_scorer.rs:524-532
       if total_sum == 0.0        → max(combined, 0)
       else if combined < 0.0     → (combined + negative_sum) / total_sum × 0.001
       else                       → combined + 0.001

NEGATIVE_SCORES_OFFSET = 0.001                      params/config.rs:40
negative_sum = −(not_interested+block+mute+report+not_dwelled)   :127
total_sum    = positive_sum + negative_sum                       :128
这段 offset 的实际效果:所有算出来是负分的帖子,被压缩到 0 ~ 0.001 这个极窄区间。 负分帖子之间的排序差异几乎归零,全部沉到最底下挤成一团。 不是「排后面一点」,是「掉出可见范围」。

两个条件加成

机制行为位置
双向追踪回复加成互相追踪时,回复权重 5.0 → 20.0(5.0+15.0)ranking_scorer.rs:186-193
双向追踪停留加成同机制,缺省 0.0(等于关闭)ranking_scorer.rs:215-222
两把钥匙同时转,加成才会发生
两把钥匙同时转,加成才会发生

④ 三段调整

调整算式与系数位置
同作者衰减(1 − 0.25) × 0.5^k + 0.25,k=该作者第几则。 第 1 则 ×1.0、第 2 则 ×0.625、第 3 则 ×0.4375…楼地板 0.25ranking_scorer.rs:614-616 param.rs:229-238
未追踪折扣没追踪的作者 ×0.75;带主题时更重 ×0.5ranking_scorer.rs:681-698
新用户模式符合条件的新帐号,未追踪内容 ×0.00001 条件:帐龄 < NewUserAgeThresholdSecs 追踪数 ≥ 5ranking_scorer.rs:688-698 config.rs:38-39
不要把 0.00001 写成耸动结论:NewUserAgeThresholdSecs 的默认值是 0param.rs:273)。帐龄不可能小于 0 秒,所以这个机制缺省不生效。 正确说法是:开关存在、力道极端、目前关着。
力道极大的开关,被闩在关的位置
力道极大的开关,被闩在关的位置

三个「盖好了但关着」的开关

开关缺省打开会怎样
NewUserAgeThresholdSecs0 秒新帐号的未追踪内容 ×0.00001,等于只剩同温层
EnableInventoryHoldoutfalse依 (帖子 ID × 用户 ID) 哈希,稳定扣住指定百分比的原创/回复/转推。三个比例缺省皆 0
VMRankerSendHeadWeightsfalse把权重表送给 vm-ranker 重排服务;目前只送预测分数不送权重

⑤ 20 道过滤器

来源 home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs L344–362(前置 17 道)与 L417–421(后置 3 道)。全部无条件注册,没有任何条件式开关。

过滤器依序运行,第一个说不的就结束
过滤器依序运行,第一个说不的就结束
#行号过滤器砍掉什么
1L345DropDuplicatesFilter不同来源捞到的同一则
2L346CoreDataHydrationFilter内文与中继数据加载失败
3L347AgeFilter超过 48 小时MAX_POST_AGE = 172800 秒)
4L348SelfTweetFilter你自己发的
5L349OONRetweetReplyFilter未追踪帐号的转推与回复
6L350OONNsfwSimclustersFilterSimClusters 捞到、作者被标成人内容、且你没追踪
7L351RetweetDeduplicationFilter同一则被重复转推
8L352IneligibleSubscriptionFilter没订阅所以看不到的付费内容
9L353PreviouslySeenPostsFilter已经看过的
10L354PreviouslySeenPostsBackupFilter同上,第二份曝光纪录再挡一次
11L355PreviouslyServedPostsFilter本次工作阶段已送出过的
12L356MutedKeywordFilter命中你的静音关键字
13L357AuthorSocialgraphFilter你封锁或静音的帐号
14L358VideoFilter请求排除视频时挡视频
15L359TopicIdsFilter不在指定主题/在排除主题内
16L360NewUserMinEngagementFilter新帐号的未追踪内容交互数不够
17L361InventoryHoldoutFilter哈希决定性地扣住一定比例(缺省 0%)
18L418VFFilter可见度系统回答 drop 的
19L419AncillaryVFFilter父/引用/转推来源被 drop 的
20L420DedupConversationFilter同一串对话的其他分支
对帐结果:README 宣称的 17+3 道与顺序,与代码逐条完全吻合,零位移。这一项 X 没有美化。

⑥ 54 条可见度规则

来源 visibility-filtering/rules/registry.rs(912 行)。第一条回答 drop 者为准,后面不再评估。

只能往一个方向走的机构:能砍,不能放行
只能往一个方向走的机构:能砍,不能放行
项目数值说明
人人适用 base_home_rules() L101–13228
未追踪内容加码 oon_drops L138–17026
未追踪内容要通过的总数54

基本 28 条依序:作者状态 4 条(停权/停用/抹除/离站)→ 保护帐号 → 你封锁 → 你静音 → 静音转推 → 内容标签 8 条(PDNA、退件、垃圾消息、紧急、仇恨言论、暴力言论、滥用、公民诚信)→ 未广播 → 过期 → 法律下架 2 条 → 敏感内容对注销/未成年/未填年龄 3 条 → 专属内容 → 最后 4 条是插页警示而非直接砍掉。

未追踪多背的 26 条全部只能 drop:DMCA 媒体、地区限制媒体、成人内容 4 种判定、 高召回率的成人与垃圾消息侦测(宁可错杀)、恶意网址、「不要放大」标签等。

⑦ 6 个归零权重的三种性质

分辨方式:看模型有没有被训练去预测这个动作。有训练、只是定价 0 =真杠杆; 连训练损失都没设 =只是留白。

共通机制:没有任何「权重是 0 就跳过」的守卫(唯一例外是 F)。 算式一律 概率 × 权重,0 权重照样计算、照样进 26 项数组,结果恒为 0。 模型仍花算力预测它、管线仍传递它,只是最后乘以零。

第 1 类:模型有训练,只是定价 0 —— 真杠杆

参数对应预测头打开的效果
ProfileClickWeightCLIENT_TWEET_CLICK_PROFILE = 30「点作者头像」开始计分。已进 positive_sum:112),调高会同时放大分子与分母
DwellWeightCLIENT_TWEET_RECAP_DWELLED = 11「有没有停留」开始计分。现况是「秒数算钱、有没有停留不算钱」
QuotedVqvWeightCLIENT_QUOTED_TWEET_VIDEO_QUALITY_VIEW = 48被引用帖子的视频有效观看开始计分,但另有长度闸门
QuotedVqv 的双保险:util/candidates_util.rs:42-60 有一个同名函数quoted_vqv_weight(),它是把权重归零的闸:若 EnableQuotedVqvDurationCheck 打开(缺省 false),被引用视频必须 > 10,000 毫秒,否则权重直接改写成 0.0。

第 2 类:连训练损失都没设 —— 只是留白

整个 phoenix/ 训练设置里,只有 DWELL_TIME 一个连续头配了损失函数recsys_model.py:473-479xrecsys.py:566-585, 画廊版面用 tweedie、其余用 mae)。

参数连续头实情
ContClickDwellTimeWeightCLICK_DWELL_TIME = 2无训练损失。但低按赞率惩罚机制已盖好(baseline 0.01/alpha 0.5/floor 0.01/cap 1.0, ranking_scorer.rs:195-213)挂在一个权重 0 的项目上
ContActiveSecs5mResidualNormWeightACTIVE_SECS_5M_RESIDUAL_NORM = 3无训练损失。衡量「你有没有因为这则帖子而多留在 App 里」
这两个还有结构性问题:分子分母不对称。positive_sum:104-122不包含这两个连续项,但它们会进分子的 26 项加总。 而 total_sum 正是负分压缩公式的分母(:524-532)。 一旦调上去,分子变大、分母不变,负分帖子的压缩比例会失真。权重为 0 时看不出来,一调就浮现。

第 3 类:有守卫、有专属测试的正式关闭开关

BidirectionalFollowDwellWeightBoost 是唯一有 != 0.0 短路守卫的 (ranking_scorer.rs:216-221)。测试码里有一个专门验证「设 0 时必须毫无作用」的测试 bidirectional_weight_zero_boost_is_noop(L1288 起), 另一个测试把它设成 2.0 验证加成生效(L1250-1253)。 它的双胞胎兄弟(回复版加成)是开着的,值 15.0。

从 204 到 21

层级数量
动作枚举表登记的动作(含 8 个占位符)204
模型输出头预算 ACTION_TYPE_MAP_LEN(补齐到 64)60
连续头槽位(5 个真值补齐到 8)8
连续头实际有训练损失1
For You 排序器实际取用的预测头26
权重非 0、真正左右排序的21
204 个动作收到 21 个真正左右排序
204 个动作收到 21 个真正左右排序

⑧ BRIDGE_PROBABILITY 专卷

全 repo 不分大小写 grep -rin bridg 共 25 命中。先剔除三类同名杂讯。

命中位置其实是什么
AdActionInfo.bridgeType AdActionInfo.isTwclidBridgedrecsys.proto:1306-1307广告转换归因。twclid=Twitter Click ID。与推荐算法的 bridging 无关
_bridge_ads_s3_env()retrieval_dataset.py:33,50设置 S3 环境变量
smyte_bridgebotmaker/scarecrow_features/Smyte(Twitter 2018 并购的反滥用公司)事件集成层

schema 里有位置

enum ContinuousActionName {                    recsys.proto:437-443
  INVALID_CONTINUOUS_ACTION_NAME = 0;
  DWELL_TIME                     = 1;   → Rust 權重 0.004(開著)
  CLICK_DWELL_TIME               = 2;   → Rust 權重 0.0(關著)
  ACTIVE_SECS_5M_RESIDUAL_NORM   = 3;   → Rust 權重 0.0(關著)
  BRIDGE_PROBABILITY             = 4;   → Rust 連參數都沒有
}

全 repo .rs 档 grep bridge0 命中。排序公式里没有它的项次, 连一个乘以零的位置都没留。

两条接线,都是输入、都关着

路径开关(缺省)做什么
A:主模型concat_history_bridge_prob = False recsys_model.py:534ca[:, :, 0] → clip 0~1 → 接在作者嵌入矢量后(:976-978)→ 过投影矩阵
B:特征前处理enable_bridge_prob = False recsys_feature_prep.py:166cont_actions[:, :, 0] → clip 0~1 → _embed_scalar_times_vector(bridge_p, "hist_bridge_prob_vec")(:756-761) =概率 × 一个 2,560 维可学习矢量,加到历史 token
全 repo 没有任何地方把这两个开关设成 True——不在 configs、不在测试、不在 yaml/json/toml。 对照组 enable_dwell_time一模一样的机制,缺省 True, 且在多个设置档明确带上。同样的水管,一条通水,一条封死。
做好了却从未接上:死码与 BRIDGE_PROBABILITY
做好了却从未接上:死码与 BRIDGE_PROBABILITY

索引矛盾:四条证据解开

两条 bridge 路径都读索引 0,但枚举说 0 是 INVALID、bridge 是 4。

证据内容
枚举值 2、3、4 从未被当成数组索引使用。全 phoenix [:, :, 2][:, :, 3][:, :, 4]0 命中; 只有 [:, :, 0][:, :, 1] 被读
存在只有 2 格的连续数组(parquet_recsys.py:845 缺省 num_continuous_actions: int = 2grpc_recsys.py:372 写死 2)。 2 格里能用的只有 0 和 1——正好是 bridge 与 dwell。若布局全照枚举编号,2 格装不下 bridge
两个 Rust 生产者 (crates/common/xai-recsys/src/util.rs:725-727crates/serving/xai-recsys-engine/src/util.rs:136-138) 写入连续数组时,唯一用到的枚举值是 ContinuousActionName::DwellTime。 全 repo Rust 档里 ContinuousActionName 只出现这 2 次。 即时服务路径从不写入 bridge,那格恒为 0.0
训练数据路径是逐格照抄history_continuous_actions[base + j] = floats.value(j)(util.rs:1177-1187), 从 parquet 的 continuousActionValuesSeqSeq 字段搬进来,代码完全不解读语意。 谁定义第 0 格是 bridge?产生那份 parquet 的上游——而它不在这个 repo 里
结论:数组语意不完全由公开枚举决定。但在即时服务路径上没有歧义—— 只有 dwell 那格会被填,bridge 那格恒为 0.0。就算把开关打开,也是 0.0 × 学到的矢量,加了等于没加。
项目数值说明
为 bridge 写好的完整接线2
被打开的开关0
训练损失0
排序权重参数0

⑨ Phoenix 模型规格

来源 phoenix/xrex/configs/xrecsys.py。这是实际训练设置,不是示范用的玩具模型。

规格的意思是:要和量它的量具一起看才成立
规格的意思是:要和量它的量具一起看才成立
项目数值意义
history_seq_len1,022一次看你最近 1,022 个行为
candidate_seq_len64一批评分 64 则候选
num_layers88 层 Transformer
emb_size2,560模型宽度
query_heads / kv_heads20 / 4分组查找注意力(GQA)
total_samples1×10^111,000 亿笔训练样本
user_vocab_size100,000,0001 亿用户哈希桶
item_vocab_size100,000,0001 亿帖子哈希桶
author_vocab_size30,000,0003,000 万作者
ip_vocab_size10,000,0001,000 万 IP
emb_learning_rate0.2嵌入层学习率

另有 nano 版emb_size 512 / num_layers 4 / query_heads 4), 搭配仓库附的合成数据产生器,外人可以真的把模型从头训练跑一遍。这是这次开源最实在的一块。

技术选择:JAX/Haiku(hk.Module)而非 PyTorch,自写 CUDA kernel(6 个 .cu) 与 Pallas kernel 做注意力;损失支持 mse/mae/huber/tweedie (tweedie 专门处理「大量为零、偶尔很大」的分布,正合交互数据的形状)。

候选来源与周边组件

组件规模负责什么
thunder/24 档 Rust内存里存你追踪对象的近期帖子(已追踪来源
phoenix/303 档检索+排序模型本体(未追踪来源+打分)
simclusters/232 档 ScalaTwitter 时代的社群分群检索(未追踪来源
vm-ranker/10 档 Rust最后重排;内核 dpp.rs(决定性点过程,做多样化)
grox/165 档 Python用 LLM(Grok)做内容安全标注的脱机流程
botmaker/492+73 档规则引擎与 73 条安全规则(Java/Scala 遗产)

⑩ 开源留白与三个破绽

X 自己承认没放的:Grox 的 LLM 提示词(.j2 档,即「AI 判定内容安全时到底问了什么」)、 部分 botmaker 规则、部署与基础设施代码。理由写得很明白:怕被拿去钻漏洞。

交出来之前被抽掉了一页,留下的残边就是破绽
交出来之前被抽掉了一页,留下的残边就是破绽

破绽一:一个过滤器文件没被声明,等于死码

home-mixer/filters/27 个 filter 档,mod.rs 只声明 26 个。 没被声明的是 popular_topics_author_dedup_filter.rs——在磁盘上,但编译时不会被纳入。

破绽二:mod.rs 第 8 行是空行,位置在字母序断点上

声明严格按字母排序,而 drop_duplicates_filterfollowing_retweet_deduplication_filter 之间空了一行。 这正是某个以 e 或 f 开头的模块被删掉会留下的痕迹。无法证明删了什么,但这是发布前有人动过手的痕迹。

破绽三:6 个过滤器存在但这条管线用不到

ad_adjacent_servedfollowing_retweet_deduplicationinvalid_conversation_modulepush_to_home_dedupresult_sizeself_reply_chain——有完整实现,但不在 Phoenix 主管线里。 它们属于其他 timeline 管线。这个 repo 给的是 For You 这一条线,不是 X 的全部。

⑪ 派工与交叉验证纪录

粗重但必须零误差的工作派给低级模型;每一条交付都以源代码亲自复验,未采信任何一方自报。

运行者被派的工作验收实跑对帐结果
CX gpt-5.6-luna (最低推理档)① 33 个权重交叉引用 1,679 行评分器 ② 6 个归零权重全流向 ③ bridge 全流向全数通过抽验 ranking_scorer.rs:63:104-128:216-221:470-510:511-533config.rs:38-40 —— 逐字相符。第三轮还主动找出我漏掉的 Rust 生产者 util.rs:725-727
GM Gemini 3.7 Flash (High)① 过滤器顺序对帐 ② 54 条可见度规则顺序 ③ 测试码鉴识全数通过独立 sed -n '344,362p''101,133p' 重跑,名称/顺序/行号全部吻合。 第一轮我喂错档(给了只注册 2 个 filter 的 for_you 管线), 它如实回报「只有 2 个」而没有帮我圆场——是我的出题失误
MX MiniMax-Text-01权重数值保真复核(独立重读源代码)数值满分 计数失准30 个重叠项目的数值 100% 逐字正确,一个小数点都没错。 但多抓 5 个名称不含 Weight 的参数、漏抓 1 个布尔参数、自报 37 列实际 35 列、 多行参数行号偏移 1–2 行。数字可信,计数不可信
HK Haiku ×3Phoenix 模型盘点、8 个组件目录盘点、连续动作布局全扫通过抽验 xrecsys.py:241-251:355-358 —— 逐字相符。 「只有 DWELL_TIME 有损失函数」这条关键线索就是从它的命中清单追下去的
HK Haiku(第 4 次,盲测)不给答案,要求独立推导 10 个关键数字整份弃用运行 0 次工具调用,10 题全部凭空捏造。详见下方

一次造假事件(保留在案)

最后一轮盲测,代理回传了格式完整、看起来很专业的 10 题答案,附「指令+输出+答案」三段。 但它一次工具都没跑tool_uses: 0),所有「原始输出」都是编的。实跑反驳:

它宣称的东西实际 grep 命中
param!(FavoriteWeight, 0.0, 1000.0, 8.5);0
filters.push(...)0
FutureOutstanding / NumDrafts 等 filter 名0
CONTINUOUS_ACTION_UNKNOWN0
「param! 区块共 37 个」实际 183
「history_seq_len: 50」实际 1,022
为什么要把这件事写进证据报告:这份捏造的交付格式完美、语气自信、还附了「可重跑指令清单」。 如果没有先创建机器真值,它会直接混进报告。 抓到它的不是怀疑,是对帐。——这正是「不信自报、必亲跑验收」这条纪律存在的理由。
看起来完整可信、实际上从未产生的交付
看起来完整可信、实际上从未产生的交付

我自己犯的三个错(一并在案)

  1. 解析器静默漏抓:第一版只扫多行 param!,漏掉 13 个单行写法—— 而真正的评分权重全部在那 13 个里。实计 170 ≠ grep -c 的 183 才抓到。
  1. 派工喂错档:把只注册 2 个 filter 的 for_you_candidate_pipeline.rs 当成主过滤链喂给 GM,白跑一轮。真正的主链在 phoenix_candidate_pipeline.rs
  1. 验证脚本本身有 bug:第一版 verify-all.shgrep -A4 抽多行参数的默认值,抓错行,产生 6 个假 FAIL。 换成完整解析器后 58/58 全过。闸门自己会坏,所以闸门要自验。

⑫ 证据界线:我不能证明什么

  • 不能证明在线实际值。param.rs 开头注解写明它是 "mirrored from config feature-switch defaults; last sync 2026-08-12", 而 feature switch 在线可调。代码能证明「公开版的默认值是什么」, 证明不了「X 在线此刻用的是什么」
  • 不能计算实际分数组成。公式是 权重 × 预测概率,而概率由模型产生,不在 repo 里。 所有「某动作比某动作重要 N 倍」的说法,都只成立在定价层面。
  • 不能还原 Grox 提示词。X 明说没放。内容安全判定的实际问法是黑的。
  • 不能断定连续动作数组第 0 格的真正语意。训练数据是逐格照抄上游 parquet, 而产生 parquet 的组件不在 repo 内。
  • 不能涵盖 For You 以外的线。6 个过滤器属于其他管线,那些管线没有公开。
光圈之内清楚,光圈之外没有东西可看
光圈之内清楚,光圈之外没有东西可看

⑬ 附录:完整复现脚本

以下三步可从零复现本文全部 58 条命题。第 2 步的解析器同时处理多行与单行 param!, 这是避开第 ⑪ 节「错误一」的关键。

逐行穷尽稽核,不是抽样
逐行穷尽稽核,不是抽样
# 1. 取得同一份程式碼(HEAD 必須是 a389166)
git clone https://github.com/xai-org/x-algorithm.git
cd x-algorithm && git log -1 --format=%H

# 2. 抽出全部 183 個參數(多行+單行兩種寫法都處理)
python3 - <<'PY'
src=open('home-mixer/params/param.rs').read().split('\n')
rows={}; i=0
while i < len(src):
    l=src[i]
    if l.startswith('param!('):
        if l.rstrip().endswith(');'):
            parts=[x.strip() for x in l[7:].rstrip()[:-2].split(',')]
            rows[parts[0]]=(i+1,parts[-1]); i+=1; continue
        j=i+1; body=[]
        while j<len(src) and not src[j].startswith(');'):
            body.append(src[j].strip()); j+=1
        parts=[b.rstrip(',').strip() for b in body if b.strip()]
        rows[parts[0]]=(i+1,parts[-1]); i=j+1; continue
    i+=1
print('param! 區塊 =', len(rows))
print('名稱含 Weight =', sum(1 for k in rows if 'Weight' in k))
for k in ['FavoriteWeight','ReportWeight','MuteAuthorWeight','ShareViaCopyLinkWeight',
          'ProfileClickWeight','DwellWeight','QuotedVqvWeight','NewUserAgeThresholdSecs']:
    print(f'{k:36s} L{rows[k][0]:<5d} = {rows[k][1]}')
PY

# 3. 其餘命題
sed -n '30,45p'   home-mixer/params/config.rs                              # 五個關鍵常數
sed -n '511,533p' home-mixer/scorers/ranking_scorer.rs                     # 正負拆分與位移
sed -n '104,128p' home-mixer/scorers/ranking_scorer.rs                     # positive_sum / total_sum
sed -n '681,700p' home-mixer/scorers/ranking_scorer.rs                     # 未追蹤折扣與新用戶
sed -n '610,620p' home-mixer/scorers/ranking_scorer.rs                     # 多樣性衰減公式
sed -n '216,221p' home-mixer/scorers/ranking_scorer.rs                     # 唯一的 !=0.0 守衛
sed -n '42,60p'   home-mixer/util/candidates_util.rs                       # quoted_vqv 長度閘門
sed -n '344,362p' home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs   # 17 道前置
sed -n '417,421p' home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs   # 3 道後置
sed -n '101,133p' visibility-filtering/rules/registry.rs                   # 28 條基本規則
sed -n '138,172p' visibility-filtering/rules/registry.rs                   # 26 條 OON 加碼

# 死碼證明:27 個檔案 vs 26 個宣告
ls home-mixer/filters/*.rs | grep -vc mod.rs
grep -c '^pub mod' home-mixer/filters/mod.rs

# bridge 專卷
grep -rin bridg . --exclude-dir=.git | wc -l                # 25(含 3 類雜訊)
grep -ri bridge --include='*.rs' . | wc -l                  # 0 ← Rust 側完全沒有
sed -n '437,443p' phoenix/python/common/xai-proto/proto/recsys.proto
grep -rn '\[:, :, 4\]' phoenix --include='*.py' | wc -l     # 0 ← 列舉值 4 從未當索引用
grep -rn 'ContinuousActionName' phoenix/crates --include='*.rs'   # 2 行,都是 DwellTime
sed -n '725,730p'   phoenix/crates/common/xai-recsys/src/util.rs  # 生產者只寫 dwell
sed -n '1177,1187p' phoenix/crates/common/xai-recsys/src/util.rs  # 訓練路徑逐格照抄

# Phoenix 真實超參數
sed -n '238,252p' phoenix/xrex/configs/xrecsys.py
sed -n '353,360p' phoenix/xrex/configs/xrecsys.py
grep -n '^NUM_CONTINUOUS\|^DWELL_INDEX' phoenix/reference/dump_gen.py

本页 58 条命题由 verify-all.sh 实跑输出直接转表,未经人工转录。 自验:注入一个错误期望值 → 脚本正确产生 1 FAIL,证明比对逻辑有效。 原始交付档(CX/GM/MX/HK 各方原文)与脚本保留在 ~/work/xalgo-research/

来源与验证

本文依据 xai-org 于 GitHub 公开的 X 推荐算法源代码撰写,判读日期 2026 年 8 月 14 日。

项目内容
源代码仓库xai-org/x-algorithm
判读版本 HEADa389166f6cf5da70a286b568c87695d4dcdce3a1
快照日期2026-08-13
机器命题验证58 条,全数通过
本文引用的源代码文件x-algorithm README(官方說明)權重參數定義 param.rs評分器 ranking_scorer.rs常數定義 config.rs候選管線與過濾器註冊可見度規則註冊表

本文所列每一条命题均由验证脚本实跑产生,未经人工转录;验证脚本本身另经 should-FAIL 反例检查。

效力界线:源代码中的参数注明为 feature switch 默认值的镜像,在线可随时调整。 本文能证明公开版本的默认值,不能证明平台在线当下实际使用的数值。 最终分数为「权重乘以模型预测概率」,而概率不在公开源代码内,因此所有倍数比较仅成立于定价层。

FAQ

负权重与正权重相比,在算法中定价相差多少?
根据代码内置默认值,正权重合计为 +43.324,负权重合计为 −367.22,负正倍数为 8.48 倍。这代表 X 对负面信号的定价比正面信号贵一个数量级,但单则帖子的实际得分仍需乘上模型预测概率。
負の重みは正の重みと比べ、アルゴリズム上でどれほど値付けが異なる?コードに組み込まれた既定値によれば、正の重みの合計は +43.324、負の重みの合計は −367.22、負正比は 8.48 倍である。これは、Xが負のシグナルを正のシグナルより一桁高く値付けしていることを意味するが、個々の投稿の実際のスコアにはなおモデル予測確率を掛ける必要がある。
How much do negative and positive weights differ in algorithmic pricing?Under the code's built-in defaults, positive weights total +43.324 and negative weights total −367.22, a negative-to-positive multiple of 8.48. This means X prices negative signals an order of magnitude above positive signals, though a post's actual score must still be multiplied by the model's predicted probability.
帖子算出来若是负分,在推荐排序中会如何处理?
依据评分公式的位移机制,所有负分帖子会被压缩到 0 至 0.001 的极窄区间内。这导致负分帖子之间的排序差异几乎归零,全部沉到最底端而掉出可见范围。
投稿の計算結果が負のスコアの場合、推薦順位ではどのように扱われる?スコア式のシフト機構により、すべての負スコア投稿は 0 から 0.001 のきわめて狭い区間に圧縮される。その結果、負スコア投稿間の順位差はほぼゼロになり、すべて最下位に沈んで表示範囲から外れる。
What happens in recommendation ranking when a post receives a negative score?Under the scoring formula's offset mechanism, all negatively scored posts are compressed into the extremely narrow range from 0 to 0.001. Ranking differences among them are therefore nearly erased; they all sink to the bottom and fall outside the visible range.
推荐管线中一共设置了几道候选帖子过滤器?
候选管线中无条件注册了 20 道过滤器,包含 17 道前置过滤器与 3 道后置过滤器。过滤规则涵盖重复内容、超过 48 小时帖子、未追踪者的转推与回复,以及可见度系统判定剔除的内容。
推薦パイプラインには候補投稿フィルターが合計何段設定されている?候補パイプラインには20段のフィルターが無条件に登録され、17段の前置フィルターと3段の後置フィルターを含む。フィルタールールは重複コンテンツ、48時間を超えた投稿、未フォロー者のリポストと返信、可視性システムが除外と判定したコンテンツを対象とする。
How many candidate-post filters are configured in the recommendation pipeline?The candidate pipeline unconditionally registers 20 filters: 17 pre-filters and 3 post-filters. The rules cover duplicate content, posts older than 48 hours, reposts and replies from non-followed accounts, and content excluded by the visibility system.
推荐给非追踪者的未追踪内容(OON)需要通过几条可见度规则?
所有人适用的基本可见度规则有 28 条,未追踪内容则额外加码 26 条规则。因此推荐给陌生人的内容总共必须通过 54 条过滤规则,且只要第一条回答 drop 即直接剔除。
非フォロワーに推薦する未フォローコンテンツ(OON)は、何件の可視性ルールを通過する必要がある?全員に適用される基本可視性ルールは28件で、未フォローコンテンツにはさらに26件が追加される。したがって、見知らぬ相手に推薦されるコンテンツは計54件のフィルタールールを通過しなければならず、最初の判定が除外であれば直ちに除外される。
How many visibility rules must out-of-network (OON) content recommended to non-followers pass?There are 28 baseline visibility rules for everyone, while out-of-network content faces 26 additional rules. Content recommended to strangers must therefore pass 54 filtering rules in total, and any first response of drop removes it immediately.
算法中的 BRIDGE_PROBABILITY 信号目前的激活状态为何?
在公开的代码中,BRIDGE_PROBABILITY 虽然已定义枚举项与接线结构,但所有开关设为 True 的次数为 0,且无训练损失与排序权重。这表示该功能处于未激活且无即时数据源输入的状态。
アルゴリズム内の BRIDGE_PROBABILITY シグナルは現在どのような有効化状態か?公開コードでは、BRIDGE_PROBABILITY は列挙値と配線構造が定義済みだが、すべてのスイッチが True に設定された回数は 0 で、学習損失もランキング重みもない。これは、この機能が有効化されておらず、リアルタイムのデータソース入力もない状態であることを示す。
What is the current activation status of the BRIDGE_PROBABILITY signal in the algorithm?In the public code, BRIDGE_PROBABILITY has an enum entry and wiring structure, but the number of switches set to True is 0, and it has no training loss or ranking weight. This indicates the feature is inactive and has no live data-source input.

引用本文

TK Lin・《X 算法拆解证据总表》・IDAEO 知識庫・2026-08-14・https://km.idaeo.ai/post/ai/x-algorithm-evidence

更新 2026-08-14T15:05:36.153Z · server-rendered · four-language · IDAEO 知識庫