機器之心發(fā)布

大模型能否預(yù)測未來？UniPat AI 構(gòu)建了一套完整的預(yù)測智能基礎(chǔ)設(shè)施，Echo，包含動態(tài)評測引擎、面向未來事件的訓(xùn)練范式和預(yù)測專用模型 EchoZ-1.0。在其公開的 General AI Prediction Leaderboard 上，EchoZ-1.0 穩(wěn)居第一，并在與 Polymarket 人類交易市場的直接對比中展現(xiàn)出顯著優(yōu)勢。

• 官網(wǎng)鏈接：https://echo.unipat.ai/
• 博客鏈接：https://unipat.ai/blog/Echo

一個懸而未決的驗證問題

過去一年，預(yù)測能力越來越受到模型廠商的重視。但預(yù)測領(lǐng)域有一個根本性的驗證難題：你說你能預(yù)測未來，怎么證明？發(fā)布時的 demo 無法追溯，事后公布的案例存在選擇性偏差，通用基準測試衡量的是語言理解和推理能力，跟真實預(yù)測是兩碼事。

UniPat AI 近日發(fā)布的 Echo 系統(tǒng)，試圖用一套完整的基礎(chǔ)設(shè)施來回答這個問題。Echo 由三個緊密耦合的組件構(gòu)成：

• 一個持續(xù)運轉(zhuǎn)的動態(tài)評測引擎，
• 一套面向未來事件的后訓(xùn)練流程（Train-on-Future），
• 一個未來可能的 AI 原生預(yù)測 API。

核心模型EchoZ-1.0是第一個在 Train-on-Future 范式下端到端訓(xùn)練的大語言模型。

在 General AI Prediction Leaderboard 上（2026 年 3 月數(shù)據(jù)），EchoZ-1.0 以 Elo 1034.2 排名第一，領(lǐng)先 Google 的 Gemini-3.1-Pro（1032.2）和 Anthropic 的 Claude-Opus-4.6（1017.2）。排行榜涵蓋 12 個模型，覆蓋政治、經(jīng)濟、體育、科技、加密貨幣等 7 個領(lǐng)域，活躍題目超過 1000 道。

EchoZ在排名魯棒性測試中穩(wěn)定第一

排名本身只是一個快照，排名的穩(wěn)定性更值得關(guān)注。

博客中披露了一組 σ 參數(shù)敏感性測試：調(diào)整 Elo 框架中的 σ 參數(shù)（控制 Brier Score 差異向勝率的轉(zhuǎn)化強度）從 0.01 到 0.50 共 9 個取值，重新計算全部模型排名。這個參數(shù)簡單來說，就是控制“模型之間表現(xiàn)差距”會被放大到什么程度。

EchoZ 在全部 9 個分組均保持第一，是唯一排名未發(fā)生任何波動的模型。作為對比，GPT-5.2 的排名在第 2 到第 9 之間波動過 8 個位次。

更有說服力的一個細節(jié)是，EchoZ 的競爭對手不僅有頂級大模型，還有預(yù)測市場上真實投入資金的人類交易者的聚合判斷，EchoZ 的 Elo 分數(shù)顯著高于這條基線。與此同時，Echo 官網(wǎng)公開了所有預(yù)測問題、模型輸出的概率分布和最終結(jié)算結(jié)果，任何人都可以回溯驗證。

三個層面的可驗證性疊加在一起（動態(tài)排行榜、實盤市場對照、全量數(shù)據(jù)公開），構(gòu)成了 Echo 與此前各種 "AI 預(yù)測" 最根本的區(qū)別。

那么，EchoZ 對人類預(yù)測者的實際優(yōu)勢有多大？Unipat AI 給出了一組分層對比：將 EchoZ 與人類市場在同一預(yù)測批次中的同一問題上進行比較，基于 Brier Score 計算勝率，按領(lǐng)域、預(yù)測期限和市場不確定性三個維度展開：

• 政治與治理領(lǐng)域：EchoZ 勝率 63.2%
• 長期預(yù)測（7 天以上）：EchoZ 勝率 59.3%
• 市場不確定區(qū)間（人類信心 55%-70%）：EchoZ 勝率 57.9%

一個值得注意的規(guī)律是：人類預(yù)測者越猶豫的場景（高不確定性、長時間跨度、復(fù)雜政治博弈）EchoZ 的優(yōu)勢反而越明顯。這暗示模型在信息整合和概率校準上的系統(tǒng)性優(yōu)勢，恰好在人類直覺最不可靠的區(qū)域得到了最大程度的釋放。

一個持續(xù)生長的評測引擎

構(gòu)建評測基準本身并不新鮮，但 Echo 的做法有一個關(guān)鍵差異：它構(gòu)建的不是一個靜態(tài)的題庫，而是一個能夠自動出題、自動結(jié)算、持續(xù)更新排名的動態(tài)系統(tǒng)。

為什么 "動態(tài)" 這件事很重要？

拿一道具體的預(yù)測題來說："2026 年 3 月 31 日收盤時，全球市值最大的公司是哪家？" 如果模型 A 在 3 月 1 日給出了預(yù)測，模型 B 在 3 月 28 日給出了預(yù)測，兩者的正確率能直接比較嗎？

顯然不能。

越接近結(jié)算時間，可用信息越多，預(yù)測難度越低。這就是現(xiàn)有預(yù)測基準的第一個結(jié)構(gòu)性問題：時序不對稱。第二個問題是題源過于單一：現(xiàn)有基準的題目幾乎全部來自預(yù)測市場，偏向容易結(jié)算的二元問題，大量來自專業(yè)領(lǐng)域和新興話題的預(yù)測需求被遺漏了。

Echo Leaderboard 的架構(gòu)正是圍繞這兩個問題展開的。整套系統(tǒng)可以拆解為四個階段的持續(xù)循環(huán)：

Echo 評測引擎構(gòu)建流程

第一步，數(shù)據(jù)采集。

三條數(shù)據(jù)管道同時運行。

第一條對接 Polymarket 等預(yù)測市場，篩選有明確結(jié)算規(guī)則和高質(zhì)量共識信號的合約。

第二條面向開放域，抓取 Google Trends 等實時趨勢，自動生成關(guān)于尚未發(fā)生事件的預(yù)測問題，由 agent 持續(xù)搜索進展并自動結(jié)算。

第三條來自真實專業(yè)場景：科研、工程、醫(yī)療等領(lǐng)域的專家將自己工作流中有價值的預(yù)測題貢獻到系統(tǒng)中，并在預(yù)定時間點給出權(quán)威判定。

從 Polymarket 上的大眾共識到實驗室里的專家判斷，三條管道覆蓋了一個相當完整的預(yù)測光譜。

第二步，預(yù)測點調(diào)度。

每道題不只做一次預(yù)測。系統(tǒng)使用對數(shù)調(diào)度算法，根據(jù)題目的結(jié)算周期長度分配多個 prediction points（預(yù)測時間點），既保證了生命周期內(nèi)的覆蓋密度，又控制了計算開銷。

第三步，對戰(zhàn)構(gòu)建。

這是解決時序不對稱問題的關(guān)鍵環(huán)節(jié)。評測使用 point-aligned Elo 機制：嚴格只比較 "同一道題、同一預(yù)測時間點" 的結(jié)果。所有參賽模型在完全相同的信息上下文下對決，公平性由此建立。

第四步，Elo 評分更新。

基于 Bradley-Terry MLE 算法計算全局排名。實驗數(shù)據(jù)顯示，這套框架對新加入模型的排名收斂速度是傳統(tǒng) Avg Brier 方法的 2.7 倍。

模型排名收斂速度對比

這四步構(gòu)成一個不斷循環(huán)的閉環(huán)：新題目持續(xù)流入，新的預(yù)測點持續(xù)觸發(fā)，對戰(zhàn)持續(xù)發(fā)生，排行榜持續(xù)更新。用一句話概括：

Echo 造了一把動態(tài)校準的尺子，而這把尺子本身也在不停生長。

Train-on-Future：當推理過程本身成為訓(xùn)練信號

評測引擎解決了 "怎么量" 的問題，接下來要回答的是 "怎么訓(xùn)"。Echo 的訓(xùn)練流程同樣是一套結(jié)構(gòu)化的系統(tǒng)，UniPat 稱之為 Train-on-Future 范式，由三個核心機制組成。

在展開之前，有必要先理解傳統(tǒng)路徑（Train-on-Past）為什么走不通。用歷史事件的已知結(jié)果來訓(xùn)練預(yù)測模型，面臨兩個很難繞過的困難。第一個是工程悖論：互聯(lián)網(wǎng)內(nèi)容持續(xù)更新，用過去的事件做訓(xùn)練題時，模型在搜索網(wǎng)頁的過程中幾乎必然會撞上包含答案的信息，數(shù)據(jù)泄露在工程實現(xiàn)上極難杜絕。第二個是結(jié)果導(dǎo)向偏差：現(xiàn)實事件充滿隨機性，一個邏輯嚴密的分析可能因為黑天鵝事件而給出 "錯誤" 答案，一個粗糙的猜測可能碰巧命中。直接用最終結(jié)果做訓(xùn)練信號，模型很容易過擬合到噪聲上。

Train-on-Future 的三個機制分別瞄準了這些問題：

機制一：動態(tài)問題合成。與使用歷史題庫不同，Echo 通過一條自動化管道，持續(xù)從實時數(shù)據(jù)流中生成關(guān)于未來事件的高信息量預(yù)測問題。因為每道題都關(guān)乎尚未發(fā)生的事件，訓(xùn)練天然不存在數(shù)據(jù)泄露的問題。

機制二：Automated Rubric Search。這是整個訓(xùn)練范式中最有技術(shù)含量的部分。Echo 的做法是：把訓(xùn)練信號建立在推理過程的質(zhì)量上，而非最終預(yù)測的對錯。但隨之而來的問題是，"好的推理過程" 該如何定義？

舉一個體育預(yù)測領(lǐng)域的具體例子。Echo 的 Rubric 中有一個維度叫做"Precursor and External Catalyst Evaluation"，評估模型是否利用高度相關(guān)的先行信號或外部驅(qū)動因素。得 5 分的標準是：識別具體的近期或即將發(fā)生的催化因素（如關(guān)鍵球員回歸、連續(xù)客場結(jié)束、關(guān)鍵對位變化），并分析這些因素與比賽結(jié)果之間的歷史關(guān)聯(lián)。得 1 分的標準是：僅泛泛提及 “狀態(tài)不錯” 或 “士氣提升” 等模糊因素，而未綁定具體可驗證事件。

另一個維度是"Multi-Factor Causal Synthesis"，評估模型是否將多個獨立因素整合為一個有因果結(jié)構(gòu)的預(yù)測結(jié)論。得 5 分的標準是：明確整合至少三個相互獨立的因素（如傷病情況、近期狀態(tài)、主客場表現(xiàn)、賠率基線），并解釋這些因素如何相互作用（如傷病削弱進攻效率，而主場優(yōu)勢部分對沖該影響），最終形成一個加權(quán)后的整體判斷。得 1 分的標準是：僅基于單一因素（如 “某隊最近連勝”）直接得出結(jié)論，或簡單羅列信息而沒有解釋各因素之間的作用關(guān)系。

總結(jié)來說，這兩個維度分別關(guān)注模型是否能夠在時間維度上引入可量化的前瞻性的關(guān)鍵變化，并在同一時點上將這些變化與既有信息整合為結(jié)構(gòu)化的因果判斷，從而提升預(yù)測的完整性與動態(tài)適應(yīng)能力。

模型按rubrics打分的排名與Elo排名相關(guān)系數(shù)隨rubrics質(zhì)量提升而提升

這些維度高度具體，顯然不是泛泛而談的 "推理質(zhì)量"。但靠人工設(shè)計也走不遠，預(yù)測領(lǐng)域噪聲極高，不同領(lǐng)域的邏輯差異很大。Echo 把這個問題轉(zhuǎn)化成了一個數(shù)據(jù)驅(qū)動的搜索任務(wù)：由 LLM 生成候選評分標準（rubric），每一輪基于上一輪的反饋進行迭代，搜索目標是讓 rubric 產(chǎn)生的模型排名與真實 Elo 排名之間的 Spearman ρ 最大化。搜索按領(lǐng)域獨立進行，政治領(lǐng)域和體育領(lǐng)域各自搜索出 20 個評分維度。實驗數(shù)據(jù)顯示，rubric 的評估質(zhì)量在迭代過程中持續(xù)攀升。

機制三：Map-Reduce Agent 架構(gòu)。訓(xùn)練完成后，EchoZ-1.0 在推理階段采用分布式的 Map-Reduce 流程。Map 階段將一個宏觀預(yù)測問題分解為多個正交子任務(wù)，派出多個 agent 并行完成信息采集和領(lǐng)域推理；Reduce 階段由聚合節(jié)點處理跨源沖突、對齊因果鏈，輸出最終的概率判斷。這個循環(huán)支持多輪自適應(yīng)迭代，直到信息覆蓋度和推理深度趨于穩(wěn)定。

這套訓(xùn)練范式的本質(zhì)可以這樣理解：

不僅考察模型猜對了沒有，也考察模型的分析過程是不是優(yōu)秀。

而 "評價分析過程" 這件事本身，也由這個系統(tǒng)自動完成。

值得留意的下一步

據(jù)了解，UniPat 計劃將 EchoZ-1.0 的預(yù)測能力封裝為一套 AI-native Prediction API 對外開放。從博客已披露的技術(shù)架構(gòu)來看，這套 API 將支持自然語言形式的預(yù)測問題輸入，返回包含概率分布、分層證據(jù)鏈、反事實脆弱性評估和監(jiān)測建議的完整結(jié)構(gòu)化報告，每份報告由多輪 Map-Reduce agent 對實時網(wǎng)絡(luò)證據(jù)循環(huán)檢索和推理后生成。

UniPat 在官網(wǎng)上為 Echo 寫下了這樣一句話："The future is no longer a probability you guess — it is a parameter you integrate."

當預(yù)測從一種直覺判斷變成一個可調(diào)用、可集成的參數(shù)，它能嵌入的決策場景，金融市場、算法交易、企業(yè)戰(zhàn)略，遠比當前看到的要多。UniPat 為 Echo 定義了四個關(guān)鍵詞：General、Evaluable、Trainable，以及 Profitable。而落地的效果，則需要期待 API 的正式上線。