← 返回文章列表
June 25, 2026
5 分鐘閱讀

researcher:面向人類與 AI 智慧體的可搜尋量化研究檔案庫

researcher:面向人類與 AI 智慧體的可搜尋量化研究檔案庫
#researcher
#quant
#arxiv
#meilisearch
#mcp
#ai-agents
#research
#algotrading

量化研究無處不在,卻又無處可尋。你需要的論文在 arXiv 上。參考實現在 GitHub 上。直覺藏在某人 2019 年寫的一篇部落格裡。真正的入場/離場邏輯是 TradingView 上一段獲得 400 個贊、卻毫無文件的 Pine 指令碼。四套語料、四個搜尋框、四套約定,零交叉引用。當你試圖判斷一個想法是否值得花一週時間做回測時,這種碎片化才是真正的成本 —— 不是閱讀本身,而是尋找

於是我們自己動手做了一個。researcher.marketmaker.cc 是一個面向量化交易研究的精選檔案庫與搜尋引擎。它把通常散落在 arXiv、GitHub、量化部落格和 TradingView 上的材料匯聚到一處,對全部內容建立全文索引,而且 —— 這是我們最看重的一點 —— 通過模型上下文協議(MCP)端點和一個公開的 REST API 把整個語料庫開放給 AI 智慧體。它是一個研究底座:人類可以用鍵盤瀏覽,智慧體可以用工具呼叫查詢,二者背後是完全相同的索引。

本文將帶你瞭解裡面有什麼、它是怎麼搭建的,以及為什麼它在我們的 AI 智慧體技術棧中處於現在這個位置。

語料庫裡有什麼

四個資料孤島 —— 論文、程式碼倉庫、文章和圖表指令碼 —— 匯聚成單一索引

researcher 統一了四個主要資料集,每個都有自己的全文索引。下面的數字截至 2026-06-12,而且會變動 —— arXiv 流水線每天執行,索引從源頭重建,所以數量會持續增長。

資料集 來源 文件數 你搜索的內容
論文 arXiv q-fin(1997–2026) 約 18,647 標題、摘要、作者(按類別過濾)
程式碼 GitHub 倉庫 約 12,957 名稱、描述、主題(按語言、星標數過濾)
文章 量化部落格 約 4,633 標題、描述(按來源、日期過濾)
策略 TradingView Pine 指令碼 約 15,180 標題、描述、標籤(按類別過濾)

這四個可搜尋索引加起來略超過 51,000 篇文件。論文索引是單個語料庫中最大的,也是我們投入最多精力的:它是完整的 arXiv 量化金融資料洪流(q-fin.*),可追溯到 1997 年,而非人工挑選的子集。早期該站點只提供數百篇精選論文;當前的索引是完整的 q-fin 語料庫,並在其之上合併了精選的來源出處資訊,因此一篇同時被某個特定量化部落格引用過的論文會攜帶相應的出處歸屬。

除了這四個搜尋索引,面向人類的站點還疊加了更多內容:我們自己撰寫的研究筆記和每日摘要、一個量化站點作者目錄、一個索引相關 YouTube 頻道的影片板塊,以及一個基金目錄。這四個索引是可搜尋的主幹;其餘一切都是圍繞它的精選內容。

單一真實來源

一個規範的資料集核心,並行地為搜尋索引和應用檢視供給資料 —— 單一真實來源

早期悄悄給我們帶來麻煩、如今我們竭力防範的,是數量不一致。首頁顯示一個數字,搜尋返回另一個,API 又是第三個。曾經有那麼一刻,首頁宣稱有 719 篇論文,而搜尋返回了超過 18,000 篇。對於一個研究工具而言,沒有什麼比一個連自己有多大都說不一致的語料庫更能腐蝕信任了。

解決辦法是讓每一個介面都從同一個地方讀取資料。對於論文語料庫,Meilisearch 就是真實來源。應用打包裡不存在論文的第二份副本;首頁上的數字、/papers 頁面上的數字、API 返回的數字,以及你實際搜尋到的文件,全都是同一個索引。語料庫本身由一個離線的攝取步驟構建:它取出精選論文集,與 arXiv 資料洪流求並集(按 arXiv id 去重,併合並來源出處陣列),按最新優先排序,寫出一個約 25 MB 的單一檔案供索引器消費。該檔案大約有 15,000–18,000 條記錄,並且刻意打包進客戶端 —— 這種規模的語料庫根本不應該傳送到瀏覽器裡。

另外三個資料集(程式碼、文章、Pine 指令碼)在服務端從各自的 JSON 檔案讀取,並從同樣的檔案建立索引,遷移到 “以 Meili 為來源” 是計劃中的下一步。貫穿始終的規則是:在服務端讀取資料,絕不把數兆位元組的資料集 import 進客戶端打包,並讓索引和展示的數字來自同一個源頭。這樣,資料不同步在結構上就變得不可能了。

搜尋:全文、容錯、分面

全文、容錯、分面搜尋:一束查詢光線進入索引,返回一個經過排序、帶高亮的結果列表

搜尋引擎是 Meilisearch,與應用執行在同一臺伺服器上並繫結到 localhost —— 它不對外公開。我們把它用作全文搜尋引擎,而非向量儲存。沒有嵌入向量,沒有語義相似度的魔法。對於 “幫我找出提到這個概念的論文和倉庫” 這類需求,針對標題、摘要、描述、作者和標籤的容錯詞法搜尋快速、可預測,並且在除錯上遠比嵌入索引來得方便。每個索引都儲存完整的原始文件外加一個新增的 _id,因此一次搜尋就能返回完全填充好的記錄,應用可以直接渲染 —— 無需為命中結果二次請求來補全資料。

幾個在實踐中很重要的細節:

  • 容錯與相關性排序是 Meilisearch 免費附送的。搜尋 momentm 仍能找到 momentum(動量)相關的論文;結果是經過排序的,而不僅僅是過濾。

  • 分面過濾。 論文按 arXiv categoryq-fin.PMq-fin.TR 等)過濾,倉庫按 languagestars 過濾,文章按 sourcedate 過濾,Pine 指令碼按 category 過濾。/papers 頁面根據索引即時的分面分布來構建其類別下拉選單,因此過濾選項始終反映語料庫中實際存在的內容。

  • camelCase 拆分。 Meilisearch 在空白和標點處分詞,但不在 camelCase 處分詞。這意味著一個直接命名為 TradingAgents 的倉庫會是單個詞元,用自然查詢 “trading agents” 無法觸及。在索引時我們派生出一個 name_split 欄位 —— TradingAgentsTradingAgents Trading Agentsai-hedge-fundai-hedge-fund ai hedge fund —— 並把它加入可搜尋屬性。原始詞元被排在最前,使得精確名稱匹配仍然排名最高,而派生欄位從不返回給客戶端。這是個小細節,卻決定了你能不能找到那個旗艦倉庫。

  • 瀏覽 = 最新優先。 空查詢不是錯誤;它是瀏覽路徑。在 /papers 上,空查詢按 published 降序排列,因此該頁面同時也是一個倒序時間排列的最新 q-fin 研究資訊流。

  • 一個用於聚合的旁路索引。 有些數字 Meilisearch 在查詢時無法低成本地計算 —— 所有倉庫的總星標數、Python 檔案總數、notebook 總數。與其在每次頁面載入時掃描整個語料庫,索引器在建立索引時一次性把這些總和寫入一個小型的 researcher_meta 索引,每個資料集對應一篇文件。stats 端點直接讀回它們。只在重新建索引時才變化的計數,也只在重新建索引時計算。

  • 一個真正可用的分頁上限。 論文索引把 Meilisearch 的 maxTotalHits 提升到 50,000,並將 published 標記為可排序,因此你可以在約 1.8 萬篇文件的語料庫中深度翻頁,並把整個語料按最新優先排序 —— 而不僅限於相關性命中的第一頁。

索引器是冪等的:它在每個索引不存在時建立它,重新應用設定,並以 2,000 篇為一批、以 _id 為鍵 upsert 每篇文件(論文的 _id 由 arXiv id 派生,倉庫和文章由 URL 的雜湊派生)。因為整個索引都可以從原始檔重建,所以無需管理備份 —— 回滾就是重新建一次索引。重新執行它在構造上就是安全的。

智慧體可訪問:MCP 與公開 API

自主 AI 智慧體節點通過一個 MCP 與公開 API 介面接入一箇中央研究語料庫

下面這部分把 researcher 與我們所做的其他事情聯絡了起來。語料庫不只是一個帶搜尋框的網站 —— 它是一個 AI 智慧體可以呼叫的工具

MCP 端點

researcher 在 /api/mcp 上通過 Streamable HTTP 暴露了一個模型上下文協議伺服器。任何相容 MCP 的智慧體 —— Claude、我們自己技術棧中的自定義智慧體、任何會說這個協議的東西 —— 都可以連線並對即時語料庫呼叫只讀工具。共有 13 個工具,按資料集分組,遵循一致的 search / get / list 形態:

分組 工具
論文 search_papersget_paperlist_papers
程式碼 search_reposget_repolist_repos
文章 search_articlesget_articlelist_articles_by_site
策略 search_pineget_pine_scriptlist_pine
知識 knowledge_query(優雅的佔位實現,預留給未來的圖譜層)

工具的 schema 是為智慧體而寫,而非為人類。以 search_papers 為例,它把自己描述為針對標題、摘要和作者的容錯、按相關性排序的搜尋,帶一個可選的 category 過濾器(例如 q-fin.PM)和一個結果數量上限 —— 並告訴智慧體在縮小範圍之後呼叫 get_paper 來獲取完整摘要。search 返回緊湊的、片段大小的命中結果,讓智慧體能夠低成本地掃描許多結果;一旦選定某一篇,get 就返回完整記錄。這種兩步式形態讓智慧體的上下文視窗不至於淹沒在它並不需要的摘要裡。

具體來說,一個在調查(比如說)最優執行的智慧體,可以執行 search_papers("optimal execution", category: "q-fin.TR") 來得到一份按相關性排序的標題與片段短名單,執行 search_repos("optimal execution", language: "Python") 來找到按相關性排序、可按星標數過濾的實現,再執行 search_pine("VWAP") 來看看同一個想法如何以一段已釋出的 TradingView 策略呈現出來 —— 針對三個語料庫的三次工具呼叫,而它們在一小時前還是三個不同的網站。然後一次 get_paper 就為那篇看起來有希望的論文取回完整摘要。智慧體始終不離開協議,而且每個結果都是真實、已填充的記錄,而非它還得回頭再取一遍的搜尋結果佔位條目。

公開 REST API

對於非 MCP 的使用者,/api/v1/ 下有一套並行的 REST 介面:papersreposarticlespine,以及一個 stats 聚合介面。它講純 JSON,帶 qcategorylimitoffset 參數,在返回每一頁的同時給出真實的總數和分面分布,並且啟用了 CORS。GET /api/v1/papers?q=optimal+execution&category=q-fin.TR 在任何地方都是一行就能搞定。同一個端點也驅動著站點自己的 /papers 頁面 —— 瀏覽器只是又一個 API 客戶端。

誠實地失敗

一個會撒謊的搜尋後端比一個宕機的更糟糕。對於 Meilisearch 不可達時會發生什麼,我們採取了有意為之的立場。資料層在失敗時丟擲異常,而不是悄悄返回空結果 —— 由呼叫方決定如何處理。對於那些仍保留記憶體副本的資料集,工具會回退到對該副本進行普通的 .filter(),因此站點保持可用。對於論文 —— Meilisearch 就是真實來源、且沒有第二份副本 —— 工具和 API 返回明確的錯誤(API 響應 503),而不是提供陳舊或不完整的資料。每次搜尋呼叫都有一個很短的超時,因此一個卡死的索引不會拖垮某個工具。原則是:大聲地降級,絕不悄悄遞迴錯誤答案。

資料是怎麼進來的

攝取流水線:外部來源經過抽取與歸一化階段,流入一個統一索引

語料庫由一套抓取器流水線供給,它們全都針對免費、公開的來源執行。

  • 論文來自 arXiv Atom API。一個採集器把完整的 q-fin 語料庫拉取成 JSONL,一個構建步驟把它與精選集求並集(按 arXiv id 去重,合併來源出處),結果交給索引器。該採集器還有一個 “擴充這些特定 id” 的模式,用於從外部閱讀清單進行種子初始化。
  • 程式碼是對量化相關 GitHub 倉庫的一次爬取,連同對過濾至關重要的後設資料一起捕獲 —— 星標數、fork 數、主要語言、主題,以及 Python 檔案數和 notebook 數。
  • 文章抓取自量化部落格和聚合站點,其中較好的會在本地映象一份,以便它們在連結失效後仍能存續。首頁會標註我們儲存了哪些文章的本地副本。
  • 策略是帶後設資料的 TradingView Pine 指令碼 —— 作者、類別、標籤、點贊數,以及該條目是否包含程式碼、圖表或分析。
  • 影片索引相關的 YouTube 頻道,使得講座和講解影片能與文字材料並列被發現。

生產環境中的重新建索引通過一條 SSH 隧道連到繫結在 localhost 的 Meilisearch 上執行,因為該引擎從不對網際網路公開。整個迴圈 —— 採集、構建、部署、建索引 —— 都被設計成可冪等地重新執行,而這正是每日定時任務所做的事。

訪問與託管

對一項託管服務的安全、經過認證的訪問:一座發光的伺服器叢集前方有一道認證門

researcher 作為一個小型 Docker Compose 棧執行在我們的 Server 1 上:一個位於 Traefik 之後的 Next.js 容器,以及一個繫結到 localhost 的 Meilisearch 容器。Next.js 應用在服務端讀取其資料集,並通過內部網路與 Meilisearch 通訊。

訪問通過我們的共享身份服務 auth.marketmaker.cc 來把關。令牌是 RS256 的 JWT,對照認證服務的 JWKS 進行校驗 —— 每一次授權決策都會校驗簽名(帶有嚴格的簽發者和演算法檢查,在金鑰端點不可達時按失敗關閉處理),而未經校驗的解碼路徑只用於純裝飾性的 UI,比如在導航欄裡顯示你的郵箱。認證服務簽發按服務劃分的角色;在 researcher 上,admin 角色為內部管理區把關(我們在那裡執行並監控抓取器),而公開首頁完全不需要任何令牌。這套認證架構與我們其他內部工具前置的是同一套,因此一次登入就能貫通整個生態系統。

它在 Marketmaker 技術棧中的位置

研究檔案庫在 Marketmaker 技術棧中的位置:一個為 AI 智慧體和人類研究者供給資料的中央底座

researcher 是基礎設施,而非終點。重點不在於這個網站 —— 而在於我們現在擁有了一個人與智慧體共享的、對整個領域可查詢的檢視。

對作為人類的我們來說,這正是這個部落格很多內容的來源。當我們評測像 VectorBT 這樣的工具,或者剖析像 TradingAgentsFincept Terminal 這樣的框架時,起點往往是在 researcher 上的一次搜尋:這建立在哪些論文之上、還有哪些倉庫解決同一個問題、誰寫過它。檔案庫是漏斗;部落格文章是從中沉澱出來的東西。

對我們的 AI 智慧體來說,它的意義更具結構性。一個可通過 MCP 訪問的研究底座,意味著一個在做策略工作的智慧體不必去即時抓取 arXiv、不必同時應付四個不同的 API、也不必去猜外面有什麼 —— 它對一個已經統一、去重並建好索引的語料庫呼叫 search_paperssearch_repossearch_pine。這與我們的命令與操作(cmdop)以及智慧體工具化的方向一致:給智慧體提供型別化的、只讀的、有良好文件的工具,讓它們作用於真實資料,在後端不可用時大聲失敗,並讓同一套共享後端從完全相同的索引同時服務人類 UI 和機器介面。人類瀏覽,智慧體查詢 —— 但他們看的是同一個檔案庫,而這正是整個理念所在。

結語

researcher 起初是為了解決一個小而惱人的問題 —— 量化研究散落在四個彼此不通氣的地方 —— 後來變成了我們每天都依賴的東西。橫跨論文、程式碼、文章和策略的大約 51,000 篇文件,全都在一個全文搜尋引擎之後,既能被一個拿著瀏覽器的人訪問,也能被一個帶著 MCP 客戶端的智慧體訪問。它刻意地不花哨:用全文搜尋,而非嵌入向量;用單一真實來源,而非巧妙的快取;用會丟擲誠實錯誤的工具,而非那些掩蓋故障的工具。

如果你正在為交易研究構建智慧體,這個經驗可以推廣到我們這個特定語料庫之外:你能給智慧體的最高槓杆之物,不是一個更大的模型,而是一個對它所需資料乾淨、統一、可查詢的檢視 —— 並通過人類所信任的同一套索引暴露出來。這就是 researcher。

免責宣告:本文提供的資訊僅用於教育和參考目的,不構成財務、投資或交易建議。加密貨幣交易涉及重大損失風險。

Authors

Eugen Soloviov
Eugen Soloviov

Trading-systems engineer

Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.

Newsletter

緊跟市場步伐

訂閱我們的時事通訊,獲取獨家 AI 交易見解、市場分析和平台更新。

我們尊重您的隱私。您可以隨時退訂。