在打造基于大語言模型（LLM）+文檔檢索的問答系統中，財經研報類文檔是最具挑戰的場景之一。它包含圖文混排、精細定位需求（頁碼、文件名）、問題措辭高度多樣化等一系列復雜性。
下面的內容是大模型輔助整理的：
本項目圍繞一個目標：給定一個用戶問題，從數百份PDF財經報告中找出相關信息并生成準確答案，并給出其出處（文件名和頁碼），通過逐步優化 chunk 策略、向量檢索和 LLM 提示工程
在train數據集上的得分為0.663，測試集目前為0.29679（排名第三）
更新：加入了文檔來源的大模型輸出和元數據的比對，切換大模型為Qwen3-32B，目前分數：0.36493（排名第一）
評分標準分三部分，總分 1：
維度 權重 說明
文件名匹配度 0.25 答案中的文件名是否與參考答案一致
頁碼匹配度 0.25 答案中頁碼是否準確
答案內容相似度 0.5 使用字符級 Jaccard 相似度度量回答文本差異
🏁 初始方案：頁面粒度chunk（Baseline）
做法：
每一頁作為一個chunk
用FAISS構建向量索引
每次檢索返回最相似的幾頁
問題：
粒度太大，LLM難以定位具體內容
過度信息干擾答案質量
無法定位到確切頁碼和文件名
📉 得分：0.002
🔧 改進一：遞歸Chunk + 直接向量檢索
每頁文本遞歸分塊
每個chunk保留其來源元數據 {filename, page_number}
用文本嵌入直接構建向量索引
📈 得分顯著提升
🧩 頁碼匹配精度優化
一個核心挑戰是：如何讓LLM生成答案時，引用準確的頁碼？
采取的策略：
從文檔解析階段開始，全程保留元數據：
每一段文本、每張圖片都保留 {filename, page_number}
在提示中引導 LLM 輸出來源信息
請用如下格式回答：
{“answer”: “…”, “filename”: “…”, “page”: …}
🔁 檢索優化策略
多路召回：
雙路召回：將檢索向量劃分為兩種策略：全文語義 vs. 精準短句（如問句特征）
重排（Re-ranking）策略：
采用 RRF（Reciprocal Rank Fusion）：
多路召回的結果融合排序
提高相關 chunk 的綜合得分，提升命中率
🔍 LLM輸出頁碼不準的問題
即使檢索相關 chunk 的元數據正確，LLM有時也會：
忽略頁碼
捏造頁碼或文件名
輸出格式錯誤（影響JSON解析）
解決：
構建嚴格提示模板，限制輸出格式
增加后處理邏輯，驗證輸出格式合法性，出錯回退使用 chunk 元數據
引入 _safe_parse() 工具，對返回結果進行強健解析
🧱 持續挑戰
-
格式輸出不穩定
LLM容易輸出錯 JSON，或 hallucinate 來源信息
強化提示模板
后處理校驗修復 -
問題表達方式高度自由
用戶問法與文檔表達方式差距大
優化嵌入模型選擇（支持中文財經語料）
其實分數還可以再高，因為現在的文件名是提取的大模型的回答，只用8B的大模型，會有很多錯誤，比如本來正確的名字輸出為繁體，或者漢字輸出為字母等，所以這個地方需要大模型+元數據同時判斷，還沒有用mineru或者其他的文檔結構化轉換工具，現在分塊方法還是太樸素了，也還沒用引入多模態（表格解析和圖像解析）
)
