iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
AI Engineering

30 天打造 ResearchForge:從 AI 報告生成器到可追溯的研究工程系統 系列

ResearchForge 最初只是我想做的一個 AI 報告生成器,但在實際開發後,我逐漸發現,真正困難的不是讓 AI「寫得像研究報告」,而是如何找到正確文獻、取得全文、解析不同格式、判斷證據是否足以支持主張,並讓每一句結論都能追溯來源。這 30 天將從專案最早期開始,完整記錄 ResearchForge 如何一步步從報告生成工具,演化成包含學術搜尋、全文取得、Evidence Card、證據整合、引用追蹤、Evidence Admission 與泛化測試的 AI 研究工程系統。

參賽天數 11 天 | 共 11 篇文章 | 0 人訂閱 訂閱系列文 RSS系列文
DAY 1

# Day 01|從報告生成器開始:成品出現了,研究還沒有

按下「生成」之後,畫面先出現等待中的灰色區塊,再換成有標題、章節與結論的報告。這是 ResearchForge 最初版本已經寫進程式的互動。可是,沿著按鈕往下讀...

2026-08-30 ‧ 由 yuz1ove 分享
DAY 2

# Day 02|模板先完成,證據仍然缺席

選了「完整報告」並要求資料來源,文獻探討先寫著「本報告蒐集並整理」相關資料,旁邊卻又提醒需要補充來源。這些文字同時存在於早期模板裡:一邊描述已做過的工作,一邊承...

2026-08-31 ‧ 由 yuz1ove 分享
DAY 3

# Day 03|有利的參考資料,證據仍可能不成立

「尚未接受任何來源,匯出內容不會包含可驗證引用。」 這是 ResearchForge 早期引用功能裡的一則提醒。 但沿著當時的下載程式繼續往下看,會發現一件有些...

2026-09-01 ‧ 由 yuz1ove 分享
DAY 4

# Day 04|搜尋開始成為一條流程:API 回應只是第一站

沿著早期搜尋程式讀下去時,看到同一個 ok 出現在不同層。單一學術資料服務的查詢失敗,會留下 ok: false;包住整段搜尋意圖流程的結果,則會回傳 ok:...

2026-09-02 ‧ 由 yuz1ove 分享
DAY 5

# Day 05|資料先過關:Accepted Source 如何建立單向流水線

我在 2026 年 6 月回頭檢查最早的 Evidence Card 時,看到一句比「沒有引用」更危險的話:來源 1 可支持「某篇文章標題」相關論點。 這句話不...

2026-09-03 ‧ 由 yuz1ove 分享
DAY 6

# Day 06|搜尋題目不是一個字串:Query Expansion 如何不搜歪

做 ResearchForge 到現在,我越來越確定一件事: 研究報告最早出錯的地方,往往不是 AI 開始寫文章的時候,而是搜尋的第一秒。 假設今天我輸入一個題...

2026-09-04 ‧ 由 yuz1ove 分享
DAY 7

#Day 07|三個學術 Provider,如何翻成同一種資料語言

我原本以為,替 ResearchForge 多接一個學術資料來源,只是多寫一次 API 呼叫。直到我把 2026 年 6 月 26 日的三種回應放在一起讀,才發...

2026-09-05 ‧ 由 yuz1ove 分享
DAY 8

# Day 08|DOI、作者與年份:去重其實在辨認研究

我在固定資料測試裡放了兩筆來源:一筆來自 Crossref,另一筆標示 Semantic Scholar;題名、網址與資料完整度不同,卻有同一個 DOI。去重後...

2026-09-06 ‧ 由 yuz1ove 分享
DAY 9

# Day 09|每個字都對,題目卻變了:離題結果為何最難除錯

Day 08把重複紀錄整理成較穩定的研究單位後,搜尋清單看起來更可信了。但下一層問題更棘手:清單裡有資料,題名也看得到使用者輸入的字,整體卻沒有牢牢回答原來的研...

2026-09-07 ‧ 由 yuz1ove 分享
DAY 10

# Day 10|從摘要到可主張證據:Evidence Card 的真正工作

Day 09 把搜尋結果留在「值得審查的候選」位置;接下來還有一道更容易被介面外觀掩蓋的問題:來源通過入口後,卡片已經出現在畫面上,是否就代表 Writer 有...

2026-09-08 ‧ 由 yuz1ove 分享