項目	內容
這個作業(yè)屬于哪個課程	2025年春季軟件工程（羅杰、任健）
這個作業(yè)的要求在哪里	[T.16] 團隊項目：Beta 階段發(fā)布說明
我在這個課程的目標是	學習軟件工程的基礎知識，和團隊成員們實踐各種軟件工程的方法與流程，開發(fā)一個讓我們值得驕傲的項目
這個作業(yè)在哪個具體方面幫助我實現(xiàn)目標	Beta階段發(fā)布說明

Beta版本的新功能和特性

B端應用場景MPA-Agent

C端用戶體驗平臺

用戶/租戶登錄與注冊


用戶主頁

租戶下管理的用戶

知識庫



知識庫權限管理


pipeline agent

1.本版本的新功能和特性

實現(xiàn)的新功能與特性

功能/特性	功能簡述
模塊化Pipeline編排	支持文檔上傳 -> 檢索 -> 排序 -> LLM生成的完整流水線配置，用戶可靈活定義流程以適配不同任務
多租戶私有化部署架構	實現(xiàn)企業(yè)級多租戶數(shù)據(jù)隔離與權限管理，支持各部門獨立構建知識庫并共享底層架構資源
智能問答 + 引用追溯機制	每個答案都帶有原始文檔的引用鏈接，提升結果透明度與信任度
低代碼知識庫構建體驗	支持用戶通過拖拽組件構建知識庫與QA流程，不需要用戶了解很多背景知識

這些功能分別能解決什么樣的問題

功能點	對應用戶需求/痛點說明
模塊化Pipeline	企業(yè)和個人用戶需要根據(jù)自身業(yè)務/學習場景靈活定制問答流程；主流平臺流程不可控
多租戶部署	企業(yè)需要對內部不同部門的數(shù)據(jù)進行隔離；滿足數(shù)據(jù)合規(guī)和權限分級管理要求
引用追溯機制	用戶對LLM答案不信任，擔心生成內容虛構；希望能驗證信息來源
低代碼知識構建	C端用戶或非開發(fā)者難以快速構建知識庫和檢索機制；希望“拖一拖就能用”

2.這些功能與特性的應用場景

場景一：大型企業(yè)搭建內部知識助手

某企業(yè)的IT部門希望構建一個內部智能問答系統(tǒng)，服務于上萬名員工的日常知識查詢。他們定制了RAGnarok服務，通過私有化部署和多租戶機制為各個事業(yè)部分別配置知識庫。產品部門上傳了大量產品手冊，行政部門則導入了規(guī)章制度和報銷流程PDF。

為了方便集成，企業(yè)IT架構師調用RAGnarok的MCP接口協(xié)議將問答系統(tǒng)對接到了OA系統(tǒng)。員工在OA中輸入“今年加班換調休政策是什么？”系統(tǒng)通過Pipeline調用文檔檢索和排序模塊，找到匹配文檔，最后由LLM生成可引用回答。

場景二：學生使用RAGnarok查文獻、做題復習

小林是一位考研英語的學生。他常常被閱讀理解的選項迷惑，希望有一個可以解析答案和講解技巧的工具。他注冊了RAGnarok賬號，將歷年真題和閱讀題打包上傳后，構建了自己的“英語題庫知識庫”。

每當遇到難題，小林就在界面中輸入“第15題為什么選B？”系統(tǒng)通過Pipeline流程從題目材料中抽取內容，再由LLM生成答案，解釋為何其他選項錯誤。引用機制讓小林可以看到解析來源。

隨著使用次數(shù)增加，系統(tǒng)會根據(jù)他的答題記錄和知識偏好，智能推薦相似題目。小林省去了整理材料、到處搜索資料的時間，學習效率大幅提升。

場景三：MPA-Agent系統(tǒng)服務多個行業(yè)

一個教育公司希望將智能技術應用于K12教學、企業(yè)內訓和論文評審。他們基于RAGnarok開發(fā)了“MPA-Agent”：一個集基礎問答、教輔生成、論文初審三大模塊于一體的多功能平臺。

每個模塊都通過獨立的流水線配置構建問答流程。例如，論文評審模塊接收Word文件后，系統(tǒng)自動調用句法分析器和審校LLM模型，對語言風格、格式規(guī)范進行初步審查并給出建議。

啟明教育通過多租戶機制區(qū)分內部員工和外部合作伙伴的數(shù)據(jù)使用權，保障數(shù)據(jù)隔離的同時，快速迭代內容與服務模式，贏得了多個教育機構的合作機會。

3.總結：如何滿足典型用戶需求？

用戶類型	核心需求	RAGnarok的滿足方式
B端企業(yè)	系統(tǒng)集成、數(shù)據(jù)隔離、權限審計	MCP協(xié)議、多租戶部署、權限管理、Pipeline編排
C端個人	簡便易用、答案準確、學習輔助	開箱即用UI、引用機制、個性化知識庫與推薦
教育行業(yè)	教輔內容生成、智能評審、模塊靈活調用	多模塊配置、語義理解優(yōu)化、結構化審閱鏈

4.團隊努力與實際效果

團隊在Beta版本發(fā)布期間：

• 技術團隊完成了Retriever優(yōu)化、異步推理鏈完善、模塊聯(lián)通與鏈路打通；
• 用戶團隊針對B端用戶場景進行個性化設計并建立C端用戶群，收集反饋進行產品優(yōu)化；
• 特別關注UI/UX簡潔性設計，實現(xiàn)“零學習成本”的上手體驗。

實際上線后，RAGnarok應對多種應用場景都能夠很好地滿足要求，具有高靈活性，進一步驗證了RAGnarok在多行業(yè)、跨人群中的適應力與可擴展性。

這一版本修復的缺陷

1.之前存在怎樣的缺陷？會帶來什么樣的負面體驗或造成什么樣的負面影響？

拖拽式組件畫布部分實現(xiàn)困難

點擊運行按鈕后用戶很難知道Pipeline的運行進度、運行情況

• 負面影響：
  • 用戶需要頻繁點擊pipeline中的結點來查看輸出情況

Retriever 與向量庫接口性能問題

Retriever組件與底層向量庫接口存在效率瓶頸，檢索速度慢，延遲較高。

• 負面影響：

  • 對企業(yè)用戶來說，文檔問答響應時間長，影響系統(tǒng)在客服和內部知識檢索中的實用性。
  • 對個人用戶來說，知識問答的交互不流暢，容易導致用戶流失或降低使用體驗。

LLM 推理鏈處理過程不穩(wěn)定

異步處理能力不足，推理鏈中間環(huán)節(jié)出錯率高，影響整體問答成功率。

• 負面影響：
  • 導致部分提問無法返回結果或結果不完整，影響用戶對系統(tǒng)可信度和滿意度。
  • 無法支持高并發(fā)問答請求，限制了產品的擴展性和業(yè)務接入能力。

系統(tǒng)模塊聯(lián)通性差

從“文檔上傳”到“問答生成”的鏈路不夠通暢，出現(xiàn)模塊間調用失敗或信息丟失的情況。

• 負面影響：

  • 阻礙B端企業(yè)用戶搭建完整問答流程；
  • 降低C端用戶自建知識庫后的系統(tǒng)響應質量；
  • 增加運維人員介入成本。

2.這次通過什么樣的方式解決了這樣的問題？在新版本中原本存在問題的地方現(xiàn)在是什么樣的？

在Beta階段，團隊對以上問題進行了系統(tǒng)性修復與優(yōu)化：

運行狀態(tài)可視化

結點運行完成后邊會變成紅色

• 修復效果：
  • 將運行狀態(tài)體現(xiàn)在pipeline的外觀上，提升用戶體驗

優(yōu)化 Retriever 與向量庫接口

改寫底層數(shù)據(jù)訪問邏輯，引入批量檢索與緩存機制。

• 修復效果：

  • 檢索速度顯著提升；
  • 支持大規(guī)模文檔庫下的秒級響應；
  • 實現(xiàn)更平穩(wěn)的問答體驗。

完善異步處理與推理鏈機制

引入異步執(zhí)行隊列與超時恢復策略，增加日志追蹤點。

• 修復效果：

  • 推理過程更穩(wěn)定，出錯率降低；
  • LLM調用并發(fā)能力增強；
  • 可監(jiān)控的流程鏈路為調試與維護提供支撐。

打通模塊聯(lián)通鏈路

重新設計模塊間的數(shù)據(jù)格式與接口標準，確保文檔 → 檢索 → 問答的閉環(huán)完整。

• 修復效果：

  • 各模塊聯(lián)動順暢，用戶上傳文檔后即可無縫使用問答功能；
  • B端企業(yè)可快速搭建完整流水線；
  • 顯著減少因接口報錯造成的功能中斷。

3.修復后的產品狀態(tài)總結

• RAGnarok在Beta階段已實現(xiàn)：模塊穩(wěn)定互通、推理快速準確、界面簡潔高效。
• 支持從文檔上傳到智能問答的全鏈路打通；
• 同時兼顧企業(yè)級場景的安全與權限管理，以及個人用戶的輕量化使用需求；
• 能夠絲滑適配多種B端應用場景，顯示出較高的穩(wěn)定性與應用廣度。

對運行環(huán)境要求

1.對客戶端運行環(huán)境

項目	要求說明
系統(tǒng)平臺	支持 Windows 10/11、macOS Monterey/Ventura、Ubuntu 22.04
瀏覽器類型與版本	推薦使用最新版 Chrome、Edge、Safari、Firefox，兼容主流瀏覽器內核
網絡要求	建議連接穩(wěn)定的網絡，便于加載文檔與發(fā)送請求
分辨率與適配	支持 1080p、2K、4K 屏幕分辨率，已完成響應式適配測試
接口兼容性	支持通過 MCP 協(xié)議與外部系統(tǒng)集成，如知識庫平臺、認證系統(tǒng)等

2.對企業(yè)私有部署環(huán)境要求

要求類別	配置說明
操作系統(tǒng)	Ubuntu 22.04 推薦，兼容 CentOS 7+ / Windows Server / macOS（開發(fā)測試環(huán)境）
硬件配置	最低：8GB RAM + 雙核 CPU；推薦：16GB RAM + 四核 CPU；高負載支持：32GB RAM + 八核 CPU
Python 版本	Python 3.10 及以上，使用uv進行項目的環(huán)境管理
部署方式	支持本地 Docker 部署、云端部署等
依賴服務	Docker / Redis / PostgreSQL 等支持組件需預裝

安裝與使用方法

個人用戶（Web端）

1. 打開官網注冊賬號
2. 創(chuàng)建個人知識庫并上傳文檔（支持拖拽）
3. 在界面中輸入問題，即可獲得AI回答

企業(yè)用戶（部署）

1. 克隆RAGnarok項目
2. 按文檔配置啟動服務
3. 登錄后臺上傳企業(yè)文檔，配置Pipeline
4. 設定權限、開啟服務

系統(tǒng)已知的問題和限制

當前發(fā)布版本的已知但不計劃在本版本修復的問題

1. Retriever 與向量庫性能問題

• 問題表現(xiàn)：在高并發(fā)查詢或大型知識庫檢索場景下，向量庫響應較慢或資源占用較高。
• 觸發(fā)條件：上傳大量文檔后進行連續(xù)問答或檢索，或多個用戶并發(fā)訪問系統(tǒng)時。
• 規(guī)避/緩解方法：
  • 推薦在企業(yè)部署中為 Qdrant/向量庫服務配置獨立高性能節(jié)點。
  • 臨時通過限制上傳文檔數(shù)量或控制并發(fā)量緩解性能壓力。
  • 對索引構建進行定期維護，避免向量碎片積累。

2. LLM 推理鏈異步處理不穩(wěn)定

• 問題表現(xiàn)：在高負載下可能出現(xiàn) LLM 返回慢或生成中斷的情況，尤其在多用戶同時提問時。
• 觸發(fā)條件：異步調用鏈路未充分優(yōu)化，特別是在網絡或計算資源緊張環(huán)境下。
• 規(guī)避/緩解方法：
  • 用戶端避免一次性并發(fā)發(fā)起多個復雜問答請求。
  • 建議在部署時開啟 LLM 負載均衡機制或將生成部分部署于獨立服務。

當前發(fā)布版本的已知限制條件及應對方式

1. 文檔上傳格式支持有限

• 限制說明：當前系統(tǒng)支持 PDF、word、txt，但尚未全面支持 Office 文檔和Markdown。
• 規(guī)避方法：
  • 建議用戶將 Markdown/Excel 文件轉為 PDF 后上傳。
  • 使用文本類筆記整理關鍵知識進行上傳。

2. MCP 協(xié)議對接需使用者具備一定技術背景

• 限制說明：MCP 協(xié)議用于對接企業(yè)系統(tǒng)，當前版本對使用者的后端系統(tǒng)開發(fā)能力有一定要求。
• 規(guī)避方法：
  • 提供參考接入文檔，需企業(yè)技術人員參與接入過程。
  • 后續(xù)可通過發(fā)布圖形化集成界面進一步降低門檻。

發(fā)布方式以及發(fā)布地址

B端應用場景MPA-Agent：一款多功能智能代理系統(tǒng)

在線訪問地址：https://www.gpapers.cn/

B 端用戶部署方式（支持私有化與深度集成）

企業(yè)用戶或開發(fā)者如需進行私有部署、定制功能或二次開發(fā)，請訪問我們的 GitHub 倉庫獲取完整源碼與部署說明：

GitHub 項目地址：https://github.com/RAGnarok-dev/

項目內附帶詳細的部署文檔，涵蓋：

• 后端與前端服務部署說明
• 多租戶與私有部署配置
• 模塊化組件啟用與禁用方法
• 數(shù)據(jù)庫與模型服務初始化流程

C 端用戶訪問

RAGnarok 系統(tǒng)的前端已部署并開放訪問，用戶可以直接通過以下地址使用智能問答平臺：

在線訪問地址：http://81.70.198.42/