Jev 用於 arXiv 大規模文獻篩選：開發者稱 5 分鐘精篩 3.6 萬篇論文，自建系統 Parallax 已上線

根據 V2EX 用戶 Zilize 於該平臺「分享創造」板塊發布的貼文，一名開發者將上半年自建的 arXiv 文獻檢索管線遷移至 Jev 模型，重構為名為 Parallax 的系統，並宣稱可在約 5 分鐘內完成 3.6 萬篇論文的精篩。貼文發布約 10 小時內累積約 520 次瀏覽。系統已開放註冊試用，網址為 parallax.ink。

開發者自述的動機與遷移過程

依貼文內容，作者從事人工智慧領域研究時感受到論文數量爆發式成長帶來的檢索壓力。其指出通用 Agent 透過黑盒式網頁搜尋 API 進行檢索時存在兩項限制：只能取得 top-k 結果，難以窮舉，也難以回答某領域共有多少篇論文這類問題；搜尋結果包含整個網際網路的相關條目，噪音大，需額外清理。

作者稱今年上半年以「vibe coding」方式自建了一套管線，流程為 arXiv 元資料抓取、向量化、關鍵詞或語意召回、LLM 精篩，但成本高、精篩速度慢。九月中旬 Jev 發布後，作者判斷其適合用於召回後的文獻精篩與分類，於是將系統遷移至 Jev。

Jev 為一不輸出文字、只回傳選項與機率的模型，其技術定位與宣稱的數據輪廓，本臺先前已綜合掘金長文整理於Jev 模型工程定位與數據輪廓整理，該模型上架 Hacker News 首日的訊源對照可參見Jev 登頂 HN 的官方數據與爭議整理。

系統設計：以集合運算重寫檢索底層

作者在貼文中說明，最初設想沿用推薦系統的漏鬥式結構（召回、粗篩、精篩），但論文檢索有兩項需求不符：一是擴增，論文存在引用關係，常透過早期文章的引用進行擴增檢索；二是補充，初次檢索後需複核是否有誤納或遺漏。

為處理多路召回的合併去重與假陽性剔除，作者以集合代數介面重寫整套檢索底層架構。檢索的基本單元為論文集合，支援聯集、差集等運算，並引入數個功能性物件：虛擬根（以虛擬物件表示檢索起點，如全庫論文或 arXiv 每日公告，避免大規模條目持久化）、規則過濾（分類標籤、時間窗口、embedding 相似度、關鍵詞等條件）、AI 精篩（呼叫 Jev 或 LLM 進行條件判定，目前判定閾值硬編碼為 0.5）、AI 分類（利用 Jev 的多標籤機率判定介面，分類不設互斥性）。

前端以 ReactFlow 將整個檢索系統視覺化為節點圖。典型工作流為：多路召回後以聯集算子合併去重，產生較大候選集，交給 AI 精篩節點呼叫 Jev，再進行主題分類。作者稱在 DeepSeek-Flash 模型實測中，Agent 面對更大規模需求時會在複核過程發現疏漏、構建彌補用的新集合，形成如電路圖般複雜的工作流。

宣稱的效益與未經獨立驗證的部分

作者主張，相較於通用 Agent 以文字檔或結構化標記語言記帳的方式，建立在資料庫與索引上的集合記帳能處理更大規模任務，且將大規模處理交給確定性程式，可對抗模型幻覺與上下文壓縮造成的記憶細節丟失。

「5 分鐘篩 3.6 萬篇論文」此一數字僅見於貼文標題與作者自述，貼文內未附具體的基準測試方法、硬體配置、API 呼叫成本明細或可複現的實驗紀錄。作者雖以「性能和成本」為題開啟段落，來源節錄至該段起始處為止，後續具體數據未包含在可得內容中。本臺未對系統進行實測，上述效能宣稱暫無法獨立核實。

可核實資訊邊界

截至目前，可確認的事實包括：V2EX 上存在該篇貼文及其所述的系統設計細節；Parallax 網站已開放註冊。至於精篩速度、成本改善幅度、與其他檢索方案的對照數據，均屬開發者單方面說法。作者也在貼文末段自述，節點圖工作流的思路在 ComfyUI 等低代碼工具普及後「應該在很多人的腦海中浮現過類似想法」，此段為個人觀點陳述，非可驗證事實。