1
00:00:10,044 --> 00:00:13,244
今天我們要深度解析 GitHub 上的一個熱門專案：

2
00:00:13,244 --> 00:00:15,924
ragflow，一個頂尖的開源 RAG 引擎。

3
00:00:15,924 --> 00:00:18,484
它旨在解決 RAG 應用最棘手的

4
00:00:18,484 --> 00:00:20,484
「垃圾進、垃圾出」問題，

5
00:00:20,484 --> 00:00:22,164
透過深度文件理解，

6
00:00:22,164 --> 00:00:25,924
為大型語言模型打造真正高品質的上下文。

7
00:00:26,064 --> 00:00:29,644
大型語言模型為什麼有時候會一本正經地胡說八道？

8
00:00:29,644 --> 00:00:33,244
很多人第一個反應，就是怪模型本身不夠聰明。

9
00:00:33,244 --> 00:00:37,544
但如果問題的根源，其實是我們餵給它的資料品質呢？

10
00:00:37,544 --> 00:00:39,784
一個叫做 RAGFlow 的開源專案，

11
00:00:39,784 --> 00:00:41,784
正試圖從源頭解決這個問題。

12
00:00:41,784 --> 00:00:43,783
它不是又一個開發框架，

13
00:00:43,783 --> 00:00:45,783
而是一套完整的 RAG 引擎，

14
00:00:45,783 --> 00:00:50,924
它獨特的設計，可能會改變大家打造企業級 AI 應用的方法。

15
00:00:50,924 --> 00:00:53,664
這個專案在 GitHub 上累積了超過八萬顆星，

16
00:00:53,664 --> 00:00:55,164
它到底厲害在哪裡？

17
00:00:55,324 --> 00:00:58,964
RAGFlow 是由 infiniflow 團隊開發的一個開源專案，

18
00:00:58,964 --> 00:01:01,363
全名是檢索增強生成引擎，

19
00:01:01,363 --> 00:01:02,863
也就是 RAG engine。

20
00:01:02,863 --> 00:01:04,503
它的核心目標很明確：

21
00:01:04,503 --> 00:01:06,944
要為大型語言模型 LLM

22
00:01:06,944 --> 00:01:08,944
提供一個非常可靠的上下文，

23
00:01:08,944 --> 00:01:11,104
來解決模型回答時沒有根據、

24
00:01:11,104 --> 00:01:13,104
甚至產生幻覺的老問題。

25
00:01:13,104 --> 00:01:15,644
這個專案在 GitHub 上有多受歡迎呢？

26
00:01:15,644 --> 00:01:18,683
它已經累積了八萬八千三百七十七顆星，

27
00:01:18,683 --> 00:01:21,483
光是今天一天就增加了四百七十三顆，

28
00:01:21,483 --> 00:01:23,224
Fork 數量也突破了一萬。

29
00:01:23,244 --> 00:01:25,983
這代表開發者社群對它有非常高的期待。

30
00:01:25,983 --> 00:01:27,683
RAGFlow 的特別之處，在於

31
00:01:27,683 --> 00:01:31,364
它把先進的 RAG 技術跟 Agent 的能力結合在一起，

32
00:01:31,364 --> 00:01:33,663
目標是為各種規模的企業，

33
00:01:33,663 --> 00:01:36,004
打造一套順暢的 AI 工作流程。

34
00:01:36,004 --> 00:01:38,364
現在要開發大型語言模型應用，

35
00:01:38,364 --> 00:01:40,564
最主流的做法就是 RAG，

36
00:01:40,564 --> 00:01:43,144
也就是檢索、增強、生成。

37
00:01:43,144 --> 00:01:44,703
這個流程聽起來很簡單：

38
00:01:44,703 --> 00:01:47,203
先從自己的資料庫裡找出相關文件，

39
00:01:47,203 --> 00:01:49,044
再把這些文件跟用戶的問題，

40
00:01:49,044 --> 00:01:51,384
一起丟給語言模型去產生答案。

41
00:01:51,403 --> 00:01:53,144
聽起來很美好，對吧？

42
00:01:53,144 --> 00:01:54,403
但真正的痛點，

43
00:01:54,403 --> 00:01:56,983
其實在最一開始的「知識提取」。

44
00:01:56,983 --> 00:01:59,943
企業的真實文件可不是乾淨的純文字。

45
00:01:59,943 --> 00:02:02,023
裡面充滿了掃描的 PDF、

46
00:02:02,023 --> 00:02:03,123
複雜的表格、

47
00:02:03,123 --> 00:02:04,523
還有多欄位的報告。

48
00:02:04,523 --> 00:02:06,064
傳統的 RAG 流程，

49
00:02:06,064 --> 00:02:09,263
常常很粗暴地把這些文件切成一段段的文字，

50
00:02:09,263 --> 00:02:12,724
結果就是，文件裡重要的版面結構和語意關聯，

51
00:02:12,724 --> 00:02:13,964
全部都遺失了。

52
00:02:13,964 --> 00:02:15,364
這就造成了所謂的

53
00:02:15,964 --> 00:02:18,064
「垃圾進，垃圾出」。

54
00:02:18,064 --> 00:02:20,403
這也是為什麼語言模型常常回答得不好、

55
00:02:20,424 --> 00:02:22,564
引用錯誤，甚至胡說八道。

56
00:02:22,564 --> 00:02:24,064
而 RAGFlow 要解決的，

57
00:02:24,064 --> 00:02:25,364
就是這個最前端，

58
00:02:25,364 --> 00:02:27,504
但也最關鍵的資料品質問題。

59
00:02:27,504 --> 00:02:28,903
RAGFlow 的技術核心，

60
00:02:28,903 --> 00:02:30,303
可以濃縮成一句話：

61
00:02:30,303 --> 00:02:32,343
「Quality in, quality out」，

62
00:02:32,343 --> 00:02:34,243
也就是高品質的輸入，

63
00:02:34,243 --> 00:02:35,843
才會有高品質的輸出。

64
00:02:35,843 --> 00:02:37,343
它的第一個技術亮點，

65
00:02:37,343 --> 00:02:40,743
是一個叫做 `DeepDoc` 的深度文件理解模組。

66
00:02:40,743 --> 00:02:43,424
你可以把它想像成一位數位文件鑑識專家。

67
00:02:43,424 --> 00:02:44,724
它不只是讀文字，

68
00:02:44,724 --> 00:02:47,724
它還會去分析 PDF 或 Word 文件的版面，

69
00:02:47,724 --> 00:02:49,823
可以很精準地把表格抽出來、

70
00:02:49,944 --> 00:02:51,084
辨識圖片內容、

71
00:02:51,084 --> 00:02:53,784
還能看懂標題和段落之間的層級關係。

72
00:02:54,243 --> 00:02:56,743
這種智慧化的切塊 chunking 方式，

73
00:02:56,743 --> 00:02:59,664
確保了餵給模型的上下文，是高品質

74
00:02:59,664 --> 00:03:01,064
而且結構完整的。

75
00:03:01,064 --> 00:03:04,123
這就從根本上提升了檢索的準確度。

76
00:03:04,123 --> 00:03:05,424
再來，RAGFlow

77
00:03:05,424 --> 00:03:07,924
把 RAG 跟 Agent 的工作流程結合在一起。

78
00:03:07,924 --> 00:03:09,823
這代表它不只會回答問題，

79
00:03:09,823 --> 00:03:12,263
還能自動執行多個步驟的複雜任務。

80
00:03:12,263 --> 00:03:13,203
更厲害的是，

81
00:03:13,203 --> 00:03:18,103
它為此設計了一個基於 `gVisor` 技術的程式碼執行沙箱 sandbox。

82
00:03:18,103 --> 00:03:18,903
sandbox

83
00:03:18,924 --> 00:03:20,024
這代表什麼意思？

84
00:03:20,024 --> 00:03:25,064
這代表 Agent 可以安全地執行由 LLM 生成的 Python 程式碼，

85
00:03:25,064 --> 00:03:26,564
來完成複雜的分析任務。

86
00:03:26,564 --> 00:03:29,064
同時，又有一道堅固的防火牆保護，

87
00:03:29,064 --> 00:03:31,403
不怕惡意程式碼攻擊主機系統。

88
00:03:31,403 --> 00:03:35,343
這個設計，對於企業級的 AI 自動化應用來說，

89
00:03:35,343 --> 00:03:37,343
提供了非常關鍵的安全保障。

90
00:03:37,343 --> 00:03:39,743
最後，來看看它的整體架構。

91
00:03:39,743 --> 00:03:42,743
RAGFlow 採用了基於 Docker 的容器化部署，

92
00:03:42,743 --> 00:03:46,644
把後端服務、資料庫和文件引擎都模組化了。

93
00:03:46,664 --> 00:03:48,763
它還讓開發者可以在 Elasticsearch，

94
00:03:48,763 --> 00:03:52,203
或是他們自己研發的 Infinity 向量資料庫之間自由選擇。

95
00:03:52,203 --> 00:03:55,403
這代表它同時兼顧了部署的方便性和架構的彈性。

96
00:03:55,403 --> 00:03:57,403
RAGFlow 的應用場景非常明確，

97
00:03:57,403 --> 00:03:58,804
主要就是針對那些

98
00:03:58,804 --> 00:04:02,084
需要處理大量非結構化文件的企業和開發者。

99
00:04:02,084 --> 00:04:02,843
舉個例子，

100
00:04:02,843 --> 00:04:07,144
一間金融機構可以用它來處理幾千份掃描的年度報告 PDF。

101
00:04:07,144 --> 00:04:09,584
然後建立一個內部的知識問答系統，

102
00:04:09,584 --> 00:04:11,683
不只可以精準回答財務數據，

103
00:04:11,683 --> 00:04:13,924
還能追溯到報告的原文頁數。

104
00:04:13,924 --> 00:04:15,123
對於開發者來說，

105
00:04:15,144 --> 00:04:17,444
可以把 RAGFlow 當作後端引擎，

106
00:04:17,444 --> 00:04:18,843
很快地為自己的 App，

107
00:04:18,843 --> 00:04:21,983
加上讀取私有資料的進階問答功能，

108
00:04:21,983 --> 00:04:25,043
不用再自己從頭蓋一個複雜的資料處理流程。

109
00:04:25,043 --> 00:04:26,483
而對數據分析師來說，

110
00:04:26,483 --> 00:04:29,524
它的 Agent 功能可以建立自動化工作流程，

111
00:04:29,524 --> 00:04:33,924
從海量文件中自動提取、分析並總結特定資訊。

112
00:04:33,924 --> 00:04:35,924
不過，這麼強大的功能，

113
00:04:35,924 --> 00:04:37,763
也代表它有一定的入門門檻。

114
00:04:37,763 --> 00:04:40,963
使用者需要對 Docker 和 Docker Compose 有基本的認識，

115
00:04:40,963 --> 00:04:44,963
才能順利在自己的環境完成 Self-Hosting 的部署。

116
00:04:45,044 --> 00:04:48,643
社群對 RAGFlow 的評價，可以說是非常兩極。

117
00:04:48,643 --> 00:04:51,044
一方面，正面的評價非常多，

118
00:04:51,044 --> 00:04:53,604
大家最稱讚的就是它的 DeepDoc 模組，

119
00:04:53,604 --> 00:04:56,004
處理複雜文件的能力真的太強了。

120
00:04:56,004 --> 00:04:57,444
很多技術評測都認為，

121
00:04:57,444 --> 00:04:59,843
它在處理真實世界的商業文件，

122
00:04:59,843 --> 00:05:01,843
像是掃描 PDF 或財報時，

123
00:05:01,843 --> 00:05:04,403
效果遠遠勝過其他的開源方案。

124
00:05:04,403 --> 00:05:07,764
加上它提供了一套包含前端介面的完整產品，

125
00:05:07,764 --> 00:05:10,004
讓企業導入的門檻大幅降低，

126
00:05:10,004 --> 00:05:13,284
甚至被譽為是「最佳自架設 RAG 產品」。

127
00:05:13,363 --> 00:05:15,923
然而，負面的聲音也同樣存在。

128
00:05:15,923 --> 00:05:19,923
疑慮主要集中在它比較高的部署成本和資源消耗。

129
00:05:19,923 --> 00:05:22,243
跟那些輕量的函式庫比起來，

130
00:05:22,243 --> 00:05:24,004
RAGFlow 的多容器架構，

131
00:05:24,004 --> 00:05:26,484
對個人開發者來說，確實有點重。

132
00:05:26,484 --> 00:05:27,764
也有些開發者認為，

133
00:05:27,764 --> 00:05:30,004
它的流程設計，在彈性上，

134
00:05:30,004 --> 00:05:32,803
還是比不上 LangChain 或 拉馬Index 這些框架。

135
00:05:32,803 --> 00:05:35,044
如果我們從一個更宏觀的角度來看，

136
00:05:35,044 --> 00:05:36,884
RAGFlow 的出現，其實代表了，

137
00:05:36,884 --> 00:05:39,444
RAG 領域一個很重要的思維轉變，

138
00:05:39,444 --> 00:05:41,604
那就是，大家優化的重心，

139
00:05:41,683 --> 00:05:43,843
開始從後端的提示工程，

140
00:05:43,843 --> 00:05:45,123
prompt engineering，

141
00:05:45,123 --> 00:05:46,963
轉移到前端的資料擷取

142
00:05:46,963 --> 00:05:47,843
ingestion。

143
00:05:47,843 --> 00:05:49,923
它揭示了一個很樸素的真理：

144
00:05:49,923 --> 00:05:51,604
高品質的 AI 輸出，

145
00:05:51,604 --> 00:05:54,083
源頭就是高品質的資料輸入。

146
00:05:54,083 --> 00:05:56,403
不過，這種對品質的極致追求，

147
00:05:56,403 --> 00:05:58,243
也帶來了潛在的風險。

148
00:05:58,243 --> 00:06:00,004
它複雜的微服務架構，

149
00:06:00,004 --> 00:06:01,444
提高了維運的門檻，

150
00:06:01,444 --> 00:06:03,444
對硬體資源的要求也比較高。

151
00:06:03,444 --> 00:06:06,164
而且，雖然它用了 gVisor 這種先進技術，

152
00:06:06,164 --> 00:06:09,204
但任何允許遠端執行程式碼的功能，

153
00:06:09,204 --> 00:06:12,803
本質上都是一個需要持續留意的安全攻擊面。

154
00:06:12,803 --> 00:06:14,803
所以，RAGFlow 的真正價值，

155
00:06:14,803 --> 00:06:17,683
並不是要取代像 LangChain 這類靈活的函式庫。

156
00:06:17,683 --> 00:06:21,284
它的定位，是為那些需要處理真實世界

157
00:06:21,284 --> 00:06:22,884
messy data 的企業，

158
00:06:22,884 --> 00:06:24,724
提供一個功能強大、

159
00:06:24,724 --> 00:06:25,764
安全可靠，

160
00:06:25,764 --> 00:06:27,444
而且開箱即用的，

161
00:06:27,444 --> 00:06:28,963
全端 RAG 平台。

162
00:06:28,963 --> 00:06:29,843
總結來說，

163
00:06:29,843 --> 00:06:31,523
RAGFlow 是一個專為解決

164
00:06:31,523 --> 00:06:33,683
真實世界文件混亂問題而生的「生產級」RAG 引擎。

165
00:06:33,683 --> 00:06:35,284
生產級 RAG 引擎。

166
00:06:35,284 --> 00:06:36,484
它最大的價值，

167
00:06:36,484 --> 00:06:38,884
就是透過深度的文件理解技術，

168
00:06:38,884 --> 00:06:41,444
從源頭就提升了輸入資料的品質，

169
00:06:41,444 --> 00:06:44,083
進而確保大型語言模型輸出的結果，

170
00:06:44,083 --> 00:06:46,243
既可靠又能追溯來源。

171
00:06:46,243 --> 00:06:49,363
所以，如果你正在開發的 AI 應用，

172
00:06:49,363 --> 00:06:51,923
需要處理大量複雜的 PDF、

173
00:06:51,923 --> 00:06:53,683
掃描文件或報告，

174
00:06:53,683 --> 00:06:56,803
而且你非常重視答案的準確度和可信度，

175
00:06:56,803 --> 00:06:57,843
那麼 RAGFlow，

176
00:06:57,843 --> 00:06:59,843
絕對是一個值得你密切關注的專案。