我開源了一個輕量級知識庫工具：EasyRAG使用分享
為什么我要開發(fā)它？
老實說，市面上類似工具不少，但要么太重，要么需要聯(lián)網(wǎng)，所以我就想做個夠用、夠輕、夠簡單的工具，主要解決這幾個我自己的痛點：
- 本地文檔太多，找起來頭疼
- 不想把文檔傳到云端（有些是公司內(nèi)部資料）
- 普通筆記本性能有限，不想裝太多大型軟件
- 希望能快速獲取多文檔的關(guān)鍵信息
主界面
文件上傳
這部分我花了不少時間優(yōu)化用戶體驗。上傳很簡單，拖拽就行。支持PDF、Word、TXT等格式。還有批量處理功能，因為經(jīng)常會一次性處理一個項目的多個文檔，一個個上傳太煩了。后臺會自動提取內(nèi)容。
開發(fā)EasyRAG時，我特別重視文檔分塊這一環(huán)節(jié)，因為它直接影響檢索質(zhì)量。我最終實現(xiàn)了六種分塊策略：text_semantic結(jié)合了語義和文本特征，是我處理大多數(shù)文檔的首選；對于內(nèi)容連貫性強的論文，我通常用純semantic方法；遇到結(jié)構(gòu)化文檔時，hierarchical和markdown_header策略效果更好；而對于沒有明顯結(jié)構(gòu)的長文本，recursive_character遞歸分塊表現(xiàn)不錯；特別是在搜索場景中，bm25分塊算法的準確率有明顯提升。這套多策略分塊系統(tǒng)讓EasyRAG能夠智能處理各種類型的文檔，而不是用一刀切的方式，這也是我反復(fù)測試后最滿意的一個功能點。
文檔檢索
我這塊檢索是利用了向量庫faiss以及gte embedding模型和gte的rerank模型來實現(xiàn)的，效果上基本可以滿足語義檢索的要求。
智能問答
會自動下載一個7b的小模型對檢索的內(nèi)容進行總結(jié)回答。
配置要求
做這個項目時我有個很明確的目標：一定要能在普通電腦上流暢運行。因為我自己的筆記本也就是普通配置，不想搞得電腦動不動就卡死。
- 完全本地部署，數(shù)據(jù)不出本機
- 最低配置要求：4GB內(nèi)存，2核CPU
- 不需要GPU，用CPU就能跑得不錯
- 占用資源比較少，后臺運行不影響其他工作
在數(shù)據(jù)處理方面，我加了一些自己的小創(chuàng)新：
- 自動根據(jù)文檔特點選擇不同的分塊策略
- 只索引重要內(nèi)容，過濾掉廢話
- 檢索算法做了優(yōu)化，在保證準確率的同時提高速度
使用建議
用了一段時間后，我發(fā)現(xiàn)幾個提升體驗的小技巧：
- PDF文件最好是文本型的，圖片型的識別率會低一些（也是基于本地ocr模型跑的，如果使用的cpu的話解析速度也會很感人）
- 文件不要太大，最好拆分一下，處理速度會更快
- 用固態(tài)硬盤的話速度會有明顯提升（我換了SSD后快了不少）
- 內(nèi)存夠用的話可以適當提高并發(fā)數(shù)，處理多文件會更快
后續(xù)計劃
這個項目還在不斷完善中，我計劃增加這些功能：
- 增加多語言支持
- 提供更多自定義選項
- 增加結(jié)構(gòu)化數(shù)據(jù)庫的同步支持
- 對接dify知識庫的接口支持
如果你也有好的想法，歡迎在GitHub上提issue或者PR：EasyRAG項目地址：https://github.com/BetaStreetOmnis/EasyRAG
寫在最后
2025年的今天，AI創(chuàng)新已如井噴，幾乎每天都有新的技術(shù)出現(xiàn)。作為親歷三次AI浪潮的技術(shù)人，我堅信AI不是替代人類，而是讓我們從重復(fù)工作中解放出來，專注于更有創(chuàng)造性的事情，關(guān)注我們公眾號口袋大數(shù)據(jù)，一起探索大模型落地的無限可能！
