為什么我要開發(fā)它？

老實(shí)說，市面上類似工具不少，但要么太重，要么需要聯(lián)網(wǎng)，所以我就想做個(gè)夠用、夠輕、夠簡單的工具，主要解決這幾個(gè)我自己的痛點(diǎn)：

• 本地文檔太多，找起來頭疼
• 不想把文檔傳到云端（有些是公司內(nèi)部資料）
• 普通筆記本性能有限，不想裝太多大型軟件
• 希望能快速獲取多文檔的關(guān)鍵信息

主界面

文件上傳

這部分我花了不少時(shí)間優(yōu)化用戶體驗(yàn)。上傳很簡單，拖拽就行。支持PDF、Word、TXT等格式。還有批量處理功能，因?yàn)榻?jīng)常會(huì)一次性處理一個(gè)項(xiàng)目的多個(gè)文檔，一個(gè)個(gè)上傳太煩了。后臺(tái)會(huì)自動(dòng)提取內(nèi)容。

開發(fā)EasyRAG時(shí)，我特別重視文檔分塊這一環(huán)節(jié)，因?yàn)樗苯佑绊憴z索質(zhì)量。我最終實(shí)現(xiàn)了六種分塊策略：text_semantic結(jié)合了語義和文本特征，是我處理大多數(shù)文檔的首選；對(duì)于內(nèi)容連貫性強(qiáng)的論文，我通常用純semantic方法；遇到結(jié)構(gòu)化文檔時(shí)，hierarchical和markdown_header策略效果更好；而對(duì)于沒有明顯結(jié)構(gòu)的長文本，recursive_character遞歸分塊表現(xiàn)不錯(cuò)；特別是在搜索場景中，bm25分塊算法的準(zhǔn)確率有明顯提升。這套多策略分塊系統(tǒng)讓EasyRAG能夠智能處理各種類型的文檔，而不是用一刀切的方式，這也是我反復(fù)測試后最滿意的一個(gè)功能點(diǎn)。

文檔檢索

我這塊檢索是利用了向量庫faiss以及gte embedding模型和gte的rerank模型來實(shí)現(xiàn)的，效果上基本可以滿足語義檢索的要求。

智能問答

會(huì)自動(dòng)下載一個(gè)7b的小模型對(duì)檢索的內(nèi)容進(jìn)行總結(jié)回答。

配置要求

做這個(gè)項(xiàng)目時(shí)我有個(gè)很明確的目標(biāo)：一定要能在普通電腦上流暢運(yùn)行。因?yàn)槲易约旱墓P記本也就是普通配置，不想搞得電腦動(dòng)不動(dòng)就卡死。

• 完全本地部署，數(shù)據(jù)不出本機(jī)
• 最低配置要求：4GB內(nèi)存，2核CPU
• 不需要GPU，用CPU就能跑得不錯(cuò)
• 占用資源比較少，后臺(tái)運(yùn)行不影響其他工作

在數(shù)據(jù)處理方面，我加了一些自己的小創(chuàng)新：

• 自動(dòng)根據(jù)文檔特點(diǎn)選擇不同的分塊策略
• 只索引重要內(nèi)容，過濾掉廢話
• 檢索算法做了優(yōu)化，在保證準(zhǔn)確率的同時(shí)提高速度

使用建議

用了一段時(shí)間后，我發(fā)現(xiàn)幾個(gè)提升體驗(yàn)的小技巧：

1. PDF文件最好是文本型的，圖片型的識(shí)別率會(huì)低一些（也是基于本地ocr模型跑的，如果使用的cpu的話解析速度也會(huì)很感人）
2. 文件不要太大，最好拆分一下，處理速度會(huì)更快
3. 用固態(tài)硬盤的話速度會(huì)有明顯提升（我換了SSD后快了不少）
4. 內(nèi)存夠用的話可以適當(dāng)提高并發(fā)數(shù)，處理多文件會(huì)更快

后續(xù)計(jì)劃

這個(gè)項(xiàng)目還在不斷完善中，我計(jì)劃增加這些功能：

• 增加多語言支持
• 提供更多自定義選項(xiàng)
• 增加結(jié)構(gòu)化數(shù)據(jù)庫的同步支持
• 對(duì)接dify知識(shí)庫的接口支持

如果你也有好的想法，歡迎在GitHub上提issue或者PR：EasyRAG項(xiàng)目地址：https://github.com/BetaStreetOmnis/EasyRAG

寫在最后

2025年的今天，AI創(chuàng)新已如井噴，幾乎每天都有新的技術(shù)出現(xiàn)。作為親歷三次AI浪潮的技術(shù)人，我堅(jiān)信AI不是替代人類，而是讓我們從重復(fù)工作中解放出來，專注于更有創(chuàng)造性的事情，關(guān)注我們公眾號(hào)口袋大數(shù)據(jù)，一起探索大模型落地的無限可能！