開源 – Page 56 – InferNews

ARI 用 RAG 修復韓國朝鮮古籍殘字

2026 年 7 月 28 日

遇到人名、地名殘缺的古籍，單靠上下文往往會估錯。ARI把檢索到的史料一併交畀模型判斷，明顯更適合做歷史文獻修復。

最值得留意的，不是模型把缺字補回來本身，而是它專門處理古籍修復最棘手的一類內容：人名、地名等 Named Entities。ARI 屬於一個結合 Retrieval-Augmented Generation（RAG）的文獻修復框架，針對朝鮮王朝實錄與承政院日記這類韓文漢字史料，補足只靠局部語境時經常失準的缺口。

現有做法多數依賴 masked language modeling，擅長根據前後文猜測一般字詞，但一遇到需要外部史實支持的專名就容易失手。ARI 的取向很清楚：先用 BM25 從歷史語料找出前 20 份相關文本，再以字串相似度 0.8 過濾重複內容，將這些外部證據交給模型一併生成，修正通用 LLM 容易出現的幻覺。

模型部分不是從零開始，而是建基於 Qwen3 32B 與 Qwen3 8B 微調成 ARI-32B 和 ARI-8B，並加入 25% named entity-prioritized masking 訓練策略，把學習重點放在知識密集片段。論文亦指出，對漢字材料而言，詞彙層面的 BM25 檢索比 embedding-based retrieval 更有效，這一點頗有說服力，因為表意文字的字形與字詞對應關係本身就影響檢索效果。

適合歷史文獻整理、數位人文研究與古籍校勘團隊參考
主要強項在於修復需要外部知識支撐的 Named Entities
ARI-32B 與 ARI-8B 同步提供，前者追求表現，後者較重視運算成本
論文結果顯示，它在 named entity 與隨機遮罩字元修復都勝過多個基線與通用模型

把它視為一個已有公開模型與方法說明的研究項目。對需要先驗證效果的人來說，現階段較合理的路線會是先查看論文設定與模型頁面，再判斷是否足以接入自己的古籍修復工作流。

項目主頁 · GitHub · Paper

Categories: 開源, RAG, Embedding, 模型, Qwen, 語音, Dataset 數據集

CrossView 用 3D 數值控制鏡頭：LTX-Video 跨視角生成

2026 年 7 月 28 日

同一段影片想換個拍攝角度，通常最難是保住人物一致性與空間感。這個 IC-LoRA 用深度 warp 加原片雙參考，讓跨視角生成更可控。

想將一段現成影片改成另一個鏡頭角度，又唔想主體變樣或空間關係散掉，這正是此模型處理的問題。它明確基於 Lightricks/LTX-2.3，屬於 LTX-Video 2.3 22B 的 IC-LoRA 微調，重點不是純文字改鏡頭，而是用輸入影片加相機偏移數值，重建同一場景的新視角。

頁面提供的做法幾清楚：模型同時接收兩段參考影片，一段是由 CrossViewWarp ComfyUI node 產生的 depth-warp 影片，用來保留幾何結構；另一段是原始影片，用來維持主體 identity。這種雙參考分工，反映它優先解決「換角度後仍要似原片」的取捨，比單靠 prompt 描述鏡頭更穩定。

它與同作者的 CrossView Prompt LoRA 差異亦很直接：後者由文字提示選鏡頭角度，這個版本改為輸入 azimuth / elevation / distance 等數值，所以鏡頭控制更精確。頁面亦提到可以在 3D orbit picker 加 keyframes，逐幀插值相機姿態，代表不只可做固定新視角，也可做繞拍式 camera move。

基礎模型已標明為 Lightricks/LTX-2.3，授權為 Apache-2.0。
主要檔案是 LTX2.3-22B_IC-LoRA-CrossView-Warp_v0.9_18000.safetensors。
依賴 ComfyUI-CrossViewWarp 與 Depth Anything V2 節點提供 depth 輸入。
示例包含固定視角偏移與 keyframed 軌道鏡頭，並說明輸出來自真實影片而非合成訓練片段。

這個項目目前仍是 PoC，它較偏向 ComfyUI 工作流驗證，而不是通用本地大語言模型部署。

模型

Categories: 開源, ComfyUI, AI productions, 視覺模型, 視頻模型, Video, 3D, LTX

Ollama 3.25 把開源模型帶回你部機

2026 年 7 月 27 日

想喺自己電腦跑開源大模型，又唔想先砌一大堆環境，Ollama 正正係針對呢個卡位。它將模型執行、管理同串接應用壓縮成一條較順手的路。

想將開源模型放返本地處理，又要兼顧聊天、程式整合同 agent 工作流，Ollama 幾乎係目前最直接的一條路。它屬於模型執行與管理工具，核心作用係將本地大語言模型的下載、啟動、呼叫同整合收斂到同一套介面，令 Mac、Windows、Linux 甚至 Docker 部署都比較一致。

它吸引人的地方不只是可以對話，而係可以直接接去 Claude Code、OpenClaw、Codex、Copilot 等現有工具鏈。換句話說，Ollama 唔係只提供一個聊天殼，而係充當本地模型服務層；你可以用 CLI 跑模型、經 REST API 調用，亦可以配合 ollama-python、ollama-js，或者再接 Open WebUI、LibreChat、Lobe Chat、NextChat、Perplexica 呢類前端與應用。

同類做法入面，Ollama 的取向好清楚：它唔著重花巧介面，而係先處理「點樣穩定喺本地把模型跑起來，再供其他程式使用」呢件事。背後支援 llama.cpp，意味住它承接咗本地推理生態的成熟基礎；代價亦存在，本地效能仍然受你部機的記憶體、GPU 與模型大小限制，追求大型模型或高併發時，就未必有雲端服務咁輕鬆。

安裝路徑完整，覆蓋 macOS、Windows、Linux 同 Docker，理解上可以當成一個本地 AI 服務。
既可直接 run 模型聊天，亦可透過 REST API、Python、JavaScript 接入現有項目。
跟 Claude Code、OpenClaw、Codex、Copilot 等整合，適合做本地 agent 與開發工作流。
配合 Open WebUI、LibreChat、Lobe Chat、NextChat 等，可快速補上可視化操作層。

較受惠的一群，會係想保留資料喺本地的開發者、需要快速測試開源模型的團隊，以及想把 AI 能力嵌入內部工具的人。就產品定位而言，Ollama 最有價值的地方，係將「本地跑模型」由零散步驟變成可重用的基礎設施。

項目主頁 · GitHub

Categories: 開源, Agentic, API, Mac, Linux, Ollama, Python

TBSM 想把一步生成變得更實用

2026 年 7 月 27 日

想要快，但又唔想靠冗長採樣或額外教師模型，TBSM正正瞄準呢個矛盾。它用一步生成處理影像與 text-to-image，取向相當鮮明。

TBSM one-step samples across handwritten digits, fashion items, CIFAR-10, ImageNet, and text-to-image generation.

生成模型一路追求更快出圖，但速度一提升，訓練往往就變得更複雜。TBSM 把焦點放在one-step generation，而且唔係靠 adversarial critic、teacher queries，亦唔需要 batch-wide all-pairs field 去撐住整個流程；它屬於生成模型方法，處理的是怎樣用較直接的監督，把一次生成做得可訓練又可擴展。

這個項目的判斷重點，在於它不只是講快，而係試圖避開幾條常見路線的代價：GANs 容易受 adversarial min-max objective 影響，AR / Diffusion 要逐步解碼或反覆採樣，Drifting Models 會受 batch 規模拖高成本，diffusion distillation 又常常連帶額外模型、loss 或訓練技巧。TBSM 用 three-body scattering 連到 distributional energy，目標是把分佈層面的學習，壓成 sample-level supervision，令一步生成唔使再背住咁重的系統負擔。

它已展示多種資料與輸出空間，包括 handwritten digits、fashion items、CIFAR-10、ImageNet，以及 1024×1024 的 text-to-image。這代表它較像研究型項目而唔係即裝即用產品：你會先從 paper、示意圖與 quick start 去理解訓練與生成流程，再按資料集或任務類型測試效果，較適合有模型訓練環境的研究團隊、影像生成項目，或者想研究 one-step generation 取捨的人。

核心賣點是一跳生成，不靠多步採樣換品質
設計上避開 adversarial critic、teacher model 同 batch 全配對成本
已展示多個資料集與 text-to-image，覆蓋面比純玩具示範更廣
現階段更接近研究實驗框架，部署前要先消化方法與訓練設定

它吸引人的地方，在於把「生成速度」同「訓練系統複雜度」一齊拉入取捨表，而不只是追某個指標。現有資訊未見完整效能數字與部署細節，表示讀者現階段應把它看成值得追蹤的生成模型研究方向：概念清晰、定位明確，但要判斷是否適合生產環境，仍然要等更完整的評測與開源內容。

GitHub

Categories: 開源, Qwen, Image, txt2img

JoyAI-Image 想做懂空間的影像模型

2026 年 7 月 27 日

JoyAI-Image唔只想生圖，仲想令模型真正理解畫面入面物件點擺位、點互相關聯。對要做指令修圖、排版生圖同多視角內容的人，呢個方向幾有參考價值。

Repository image for jd-opensource/JoyAI-Image

改圖最怕模型聽得明文字，卻改壞原本場景結構；生圖亦常見字排得唔準、物件關係走位。JoyAI-Image就係朝住呢個痛點落手，定位屬於多模態基礎模型，把影像理解、text-to-image 生成同指令式編輯放入同一個模型家族，重點處理空間理解不足帶來的失真與失控。

唔係把理解模型同生成模型鬆散拼埋，而係用 8B Multimodal Large Language Model (MLLM) 配 16B Multimodal Diffusion Transformer (MMDiT)，強調理解、生成、編輯之間的閉環協作。換句話說，模型唔只讀圖後再畫圖，仲會利用視角變換等生成結果反過來補強空間推理，呢點令它在 grounded generation、關係定位同可控編輯上有更鮮明方向。

現有公開內容顯示，部署路線算完整，已提供 Hugging Face 權重、Diffusers 版本、ComfyUI 原生支援，同埋可直接參考的 workflow；另外亦有 Spatial Edit 同 General Edit 示範空間。對內容製作、電商視覺、設計流程或者研究多模態編輯的人，較值得留意的是它不只處理單次修圖，仲想處理長文字排版、版面忠實度、多視角生成，以及「指定物件移去指定位置」呢類容易出錯的操作。

JoyAI Image Edit Plus in ComfyUI - How Does it Compare?

Watch this video on YouTube

把理解、生成、編輯整合到同一條多模態流程
核心賣點係較強的 spatial intelligence，而不只是畫面更靚
已有 Diffusers 與 ComfyUI 兩條使用路線，測試門檻較研究原型低
延伸到 OpenSpatial data engine 同 OpenSpatial-3M dataset，反映它連資料與訓練配方都一併公開

效能方面，儲存庫描述集中在能力展示與訓練設計，現階段較適合把它理解成一個方向清晰、工具鏈逐步成熟的開源影像模型項目。最吸引之處唔係單一指標，而係它把空間理解當成生成與編輯的核心能力，對需要更穩定版面、關係同位置控制的工作流，確實比單講畫質更實用。

GitHub · 模型

Categories: 開源, ComfyUI, 模型, 視覺模型, 多模態模型, Qwen, Image, txt2img, Dataset 數據集

FinanceComplexQA 點評：金融長文件問答基準

2026 年 7 月 26 日

想測試模型是否真係讀得懂財務文件，FinanceComplexQA比一般抽句式問答更貼近難題。它把中英雙語、推理、多步計算與文件依據綁在同一個基準內。

金融問答最容易失真的位置，不是模型識唔識術語，而是它會否真正在整份參考文件入面推理、比對同計數。FinanceComplexQA屬於數據集／Benchmark，焦點不是背答案，而是檢驗 LLMs 和 agents 能否根據完整 reference documents 回答複雜金融問題。

它修正了只靠 parametric knowledge 或抽取單一段落的評測範式。作者把重點放在 document-grounded complex financial QA，要求答案同問題及原始文件一致，並涵蓋 multi-hop reasoning、numerical calculation、comparison、implicit inference、planning、summarization 同 evidence-grounded verification，對 RAG、Agentic workflow 同長文本閱讀能力都有參考價值。

資料結構本身亦有取捨。FinComplexQA-Pro 收錄 2,026 組獨立 QA，按語言、金融場景與任務分類組織；同一題會以 scene_categories 與 task_categories 兩種視角出現，所以總記錄視圖有 4,052 筆。另有 overall 提供 agent_answer、agent_thinking 及 LLM-as-a-judge 分數，但這些分數只適合做診斷訊號，不能當 ground truth。

支援中文與英文，但兩個子集覆蓋的文件領域不同，schema 亦不完全一致
較適合逐個子目錄讀取 JSONL，而不是一開始合併全部資料
可用 exact match、數值容差、F1、semantic similarity 等方法比對輸出
附有 Reference_documents，方便追查 PDF 與 LaTeX 原文證據

部署和測試的理解方式相當直接：資料主要在 Hugging Face 發佈，研究團隊可先挑單一語言、單一 task category 載入，再把模型輸出對照 gold answer 或文件證據做評估。它較受惠於做金融 RAG、長文件 QA、Agent 評測或雙語研究的團隊；要留意的是金融事實具時效性，而且項目已明確標示僅供研究與評估，不應延伸成投資、會計、法律或財務建議。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, RAG, 多模態模型, 微軟, DeepSeek, 中國, Dataset 數據集

Sana 把高解像生成壓到快 100 倍

2026 年 7 月 26 日

想做高解像圖片或影片生成，又唔想計算成本高得難以落地，Sana 提供了一條幾實際的路。它把訓練、推理到不同變體放在同一套代碼庫，重點放在速度與畫質之間的平衡。

高解像圖片同影片生成最常見的卡位，不是效果做不到，而是算力、延遲同部署成本太難接受。NVlabs/Sana 屬於生成模型代碼庫，集中處理這個矛盾：在維持高解析輸出的前提下，把訓練與推理做得更省、更快，並且一路延伸到圖片、影片、世界模型等多條分支。

這個項目唔係單一模型，而是一個家族。SANA 主打最高到 4K 的 text-to-image，README 直接給出「比 Flux-12B 細 20 倍、快 100 倍」的定位；SANA-1.5 進一步處理訓練期與推理期的 compute scaling；SANA-Sprint 則把重點放在 one/few-step 生成，官方數字提到 H100 上 1024px 圖片可做到 0.1 秒級。取向很清楚：不是一味追最大模型，而是用效率換取更可部署的生成流程。

影片部分同樣值得留意。SANA-Video 與 SANA-Video 2.0 把焦點放在 720p 長序列生成，做法上用 hybrid linear attention 配合 Attention Residuals，目的是減少 full-softmax attention 的成本，同時盡量保住畫質與長序列表達能力。公開資料提到 SANA-Video 2.0 在單張 H100 上，720p/5 秒影片可做到 13.06 秒，VBench 總分 84.30，也強調比 Wan 2.2 14B 有大幅速度優勢，但這類數字仍要連同硬件、步數與設定一齊理解。

同一庫內含 SANA、SANA-1.5、SANA-Sprint、SANA-Video、SANA-WM、SANA-Streaming、Sol-RL
提供完整 training 與 inference pipeline，唔止展示模型效果
可透過官方 demo、Hugging Face、ComfyUI 整合去理解生成表現與部署方向
重點不是極限參數量，而是高解像生成的速度、成本同可擴展性

部署與測試路線相對清晰：已有官方文件、網頁 demo、Hugging Face 集合，亦見到 ComfyUI、SGLang、Replicate 等接點，代表它較適合研究團隊、影像工作流開發者，以及想把高解像生成放進產品流程的人。 SANA-WM 的 2.6B controllable world model、6-DoF camera control，同 Sol-RL 的加速收斂能力，則顯示這個項目不只做靜態出圖，而是朝更完整的生成系統推進。

項目主頁 · GitHub

Categories: 開源, ComfyUI, AI productions, 世界模型, 模型訓練, NVIDIA, Stable Diffusion, Video, Image, txt2img

SoulX-Singer 把零樣本歌聲合成

2026 年 7 月 26 日

想快速試一把未見過的歌手聲線，SoulX-Singer提供咗幾近成品級嘅路線。它唔只唱得準，連跨語言同改詞後的人聲一致性都放埋入同一套流程。

做歌聲生成，最難往往唔係「唱到」，而係未見過的聲線仍然要自然、準音、像本人。SoulX-Singer正是朝住呢個矛盾而來的開源模型項目，重點放在 zero-shot singing voice synthesis：唔使為每位歌手再微調，都可以用參考聲線配合旋律或樂譜生成歌聲。

它的定位幾清楚：一邊照顧創作控制，一邊盡量保住音色身份。你可以用 melody-conditioned 的 F0 contour 控制音高走向，亦可以用 score-conditioned 的 MIDI notes 對齊節奏與音符；對於需要改詞、換語言、保留同一把聲去做 demo、作曲草稿或虛擬歌手內容的人，這種控制方式比只靠文字描述更實際。README 亦提供 Hugging Face 模型與線上示範，部署理解上屬於下載預訓練權重後做推理的典型流程。

同類做法常見取捨，是控制愈細，聲線就愈易散；複製音色愈強，跨語言和改詞後又可能變得生硬。SoulX-Singer把 timbre 與 content 盡量拆開處理，目標是讓 Cantonese、Mandarin、English 之間仍能維持歌手辨識度，這點比單純追求「像真」更有產品意味。項目另外還有從 SoulX-Singer 微調而來的 SoulX-Singer-SVC，處理 singing voice conversion，直接由原始歌聲音訊轉換成目標歌手風格，連歌詞或 MIDI 標註都可省去。

支援 F0 contour 與 MIDI 兩種控制，適合作曲草稿與精修流程
主打 zero-shot，未見過的歌手聲線都可生成，減少逐人微調成本
42,000+ 小時對齊人聲資料覆蓋 Mandarin、English、Cantonese
可做改詞編修與跨語言合成，同時維持音色一致性
另設 SoulX-Singer-SVC，補上 audio-to-audio 轉換場景

現有資料未完整列出量化指標細節，但項目已公開技術報告、arXiv 與示範頁，代表它不只停在概念展示。對音樂 AI 團隊、虛擬歌手內容製作、語音與歌聲研究者而言，SoulX-Singer吸引之處在於它把可控性、跨語言與免微調三件事放入同一條生成鏈，而限制則仍要留意倫理風險、聲線授權，以及最終作品是否需要後期混音補足細節。

GitHub · 模型

Categories: 開源, 模型, Audio, 聲效, 音樂

Color Pass-Through 重新做色彩校準

2026 年 7 月 26 日

想令手機畫面更接近眼前真景，難處往往唔係相機或螢幕單獨夠唔夠準，而係兩者夾埋之後會一路累積偏差。Color Pass-Through就係針對呢個落差，將整條 camera-display 路徑一齊學起來。

想像你透過手機或頭戴裝置睇現場畫面，明明場景喺眼前，畫面顏色同亮度卻總有一層隔膜。Color Pass-Through 針對的正正係呢種 camera-display 不一致：它屬於影像處理研究項目，以端到端方式學習固定裝置上的 camera-display 路徑，目標唔係單獨校正相機或螢幕，而係令人經過裝置觀看時，感知上更接近真實場景。

作者明確反對傳統 ICC workflow 呢種兩段式校準範式。舊做法會先分開處理相機同顯示器，再靠預先定義的中介色彩空間接駁，誤差容易逐步累積；Color Pass-Through 改為直接學完整投影路徑，並為每位觀察者做 one-step calibration。呢個取向的好處係更貼近人眼最終見到的結果，代價就係它依賴特定 device pair，同時帶有 observer-specific 設定，泛化方式同傳統標準化流程唔一樣。

目前公開資訊顯示，項目已放出完整 training and inference pipeline，並提供兩款支援裝置的 pretrained checkpoints，所以較合理的理解方式係：它首先係研究原型，其次先係可重現的程式碼。資料集仲準備公開，Android toy example 亦仍在開發中，部署重點暫時仍然放喺已支援裝置上重現論文結果，而唔係即插即用地套入任何手機。

核心改動係把 camera 與 display coupling，唔再經固定中介色域分開校正
以每位使用者一次校準換取更貼近主觀觀感的色彩與亮度表現
人類評分提升 +2.0 分（5 分制），亮度 4.32/5，色彩 4.03/5
定量結果亦有明顯優勢，PSNR、ΔE、STRESS 在兩款商用手機上都優於列出的基線

同類方法很多時會加強 white balance、ColorChecker mapping，或者在既有 ISP 後面再補一層修正；這個項目則直接把問題重寫成特定裝置、特定觀察者的整體感知重建。對做 AR/VR pass-through、顯示校準、計算攝影研究的人最有參考價值，尤其當重點唔係標準色彩流程有幾完整，而係人眼最後見到的畫面到底似唔似真景。

項目主頁 · GitHub · Paper

Categories: 開源, 香港中文大學, 華為, 模型訓練, 蘋果, Dataset 數據集

ProVisE 用像素答案重做空間評測

2026 年 7 月 26 日

空間理解唔一定適合用文字作答，ProVisE改咗評測入口，令圖像生成模型可以用畫、點、標記去答題。你會更易睇清楚，模型到底係唔識空間，定只係答題格式唔對。

當一條空間題目本來應該用圈選、標記路徑或者遮罩去表達，硬要模型交出座標、選項字母或文字描述，結果往往唔係能力差，而係答題介面同模型表達方式錯位。ProVisE屬於評測框架，處理的正是呢個落差：它唔改原本 benchmark 任務本身，只改回應介面，讓圖像生成模型用像素空間交答案，再轉回 benchmark 可計分的結構化輸出。

現有 spatial benchmarks 多數沿用 text-only interface，假設所有模型都應該以 coordinates、option labels 或 textual descriptions 回答。作者認為這種固定範式會壓縮 regions、paths、affordances 呢類本身偏視覺的判斷，因此提出 Protocolized Visual Evaluation：先由 task-aware router 指派 visual protocol，再用固定 guidance prompt 同 parser 約束輸出，最後仍然交回 original benchmark metric 評分。Text-output VLMs 就維持原本答題空間，兩類模型可以在同一套任務語義下比較。

ZJU-OmniAI/ProVisE 在於把「模型唔識答」同「評測方法逼錯答案格式」分開處理。配套的 SpatialGen-Bench 收錄 470 個 curated samples，涵蓋 14 個 subtasks，同時分成 perception、understanding、reasoning、interaction 四個 capability levels；研究結論亦相當直接，image-generation models 在可把判斷外化成像素標記的任務上有競爭力，但 text-output VLMs 在另外一些題型仍然較穩定，兩者並非誰全面取代誰。

保留原有 benchmark metric，只替換答案介面，方便同既有結果對照
用 visual protocol 限制生成內容，減少任意畫圖帶來的解析歧義
SpatialGen-Bench 把空間能力拆成 14 個 subtasks，唔再只看單一總分
適合研究 VLM、image-generation models、agent 空間理解能力的團隊採用

安裝門檻看來不高，程式環境以 Python 3.10+ 為主，並已公開 code、project page 與 Hugging Face 上的 SpatialGen-Bench。現階段它更像研究與評測項目，不是即插即用產品；重點也不在部署成服務，而是在你想驗證模型空間認知時，能否用更貼近模型輸出形式的方式做比較。對做多模態模型、視覺評測或 Agentic 系統的人來說，ProVisE提供了一個相當清晰的檢查角度。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, 視覺模型, 多模態模型, Image, Python, Dataset 數據集

Page 56 of 119

« Previous 1 … 54 55 56 57 58 … 119 Next »