1、前言
在6.28/29的稀土掘金開發者大會RAG專場上，我們公司CEO員外代表TorchV分享了我們在《RAG在企業應用中落地的難點與創新》
其中最後分享了兩個觀點：
- AI在應用場景落地時有三個特點：功能小、質量高、價值大
-
- 如果說做產品是把一橫做好的話，那麼去做企業落地服務就是一豎，從需求和方案，再到 POC，和最後交付。
-
對於AI應用的三個特點，我們在落地的時候，其實碰到的問題蠻多的，但是用過大模型或者AI產品的人應該都知道，目前基於大模型應用開發的C端產品其實在整體給人的感覺都是相對較小的工具居多，在幫助人類提效這件事上，藉助於AI工具，能很好的完成日常繁雜的工作和學習任務。比如AI翻譯、網頁總結外掛等等。這類產品更多的是偏C端為主，藉助於網際網路的生態以及開源技術的發展，只要功能/互動滿足使用者的要求，很快就能打動C端使用者進行嚐鮮試用甚至付費。
但是做B端類的產品，整個交付的過程就明顯和C端不一樣，在B端我們除了產品本身需要功能足夠強大之外，我們還需要做AI的落地交付，這裡麵包含私有化定製/客戶培訓/私有化部署/軟硬體適配等等繁雜的工作，整個交付週期漫長的多。這明顯是和上面第二個觀點相呼應的，產品+服務才能綜合服務好B端的客戶。
本篇是結合我們公司在B端RAG/大模型應用產品的落地交付的場景考慮，以實際場景出發，談談我對知識庫類產品的技術架構的思考總結。
2、業務功能/技術元件拆解抽象
圖3-業務架構
在文章的標題中，我已經標註了範圍: RAG、大模型、非結構化資料
我們從這三個方面出發，在軟體層面，我們如何來考慮這些新型的技術名詞，將他們從技術/產品功能的角度進行拆解，實現對應的功能交付給我們的客戶。
從業務的功能訴求來看，主要有幾個方面：
- 知識庫：客戶需要將業務資料統一收集處理，形成知識庫，以便提供給LLM進行使用
- 應用中心：B端客戶需要開箱即用的產品，解決實際工作業務中碰到的問題
- 使用者許可權：系統提供企業級靈活可控的許可權管理，方便企業客戶進行統一管理授權。
- 多租戶：多租戶體系架構是必不可少的，可以保證資料以Schema級別進行隔離，保障資料安全以及上層應用的靈活輸出支撐。
- ...
而從技術側考慮，技術人員需要關注的是：
- 非結構化資料的處理：平臺需要支援多種多樣的非結構化資料的提取處理工作，將整個文件內容進行chunking、embedding進入資料庫，以便進行搜尋
- 檔案型別廣度：提供眾多的非結構化資料文件(PDF/PPT/WORD等)的提取支援，是打動B端客戶的有利吸引點，
- 檔案解析精度：以PDF/PPT/Word為首的文件解析工作困難重重，如何在解析的工作上更進一步，從根源上減少模型在利用已知資料的幻覺問題
- 任務排程：資料的處理依靠穩定的任務排程平臺，保證資料處理的最終有序執行。
- 模型服務：從LLM大語言模型、Reranker模型、embedding、OCR模型、視覺模型等等，保證模型的冪等輸出，為上層應用提供穩定可靠的服務支撐。
- LLM模型：提供一系列Agent服務，保證上層業務能夠靈活呼叫大模型獲取滿意的結果
- ReRanker模型：重排序模型是問答二階段召回提高準確率的關鍵手段，不可忽慮
- Embedding模型：向量化嵌入，提供對知識文字的表徵提取向量工作，不可忽慮
- OCR/視覺模型：輔助非結構化資料提取在規則提取不滿足的情況下，啟動OCR及視覺模型，增強非結構化資料的提供效果
- 向量資料庫(VectorDB): 需要結合實際業務訴求，從效能/空間/生態等多方面考量VectorDB等選型
技術的角度拆分，其實技術人員關注的點非常的多，每一項工作其實都可以是獨立的中介軟體產品，要把這些全部整合到一塊，並非易事。
3、微服務/分散式/雲原生？
寫過Java的估計對上面這三個名詞都已經滾瓜亂熟了，我記得很早之前，說面試你如果不會微服務，那都找不到工作(PS:現在好像不管你會什麼，也同樣都找不到)😂。
對於AI應用，可能更多的軟體生態是由Python帶動起來的，包括一些工具庫LangChain、LlamaIndex等都是Python，雖然Java中也不乏有一些，比如LangChain4j、Spring-AI等元件，都是後起之秀，在整個生態穩定性等方面確實是落後了一節。
但可能很多人都在用過LangChain等框架後有一個共識，那就是當作工具用沒有問題，但是上生產？問題太多了。我覺得主要的幾個點：
- LangChain的過度封裝，對於應用層而言，不管是Agent，還是RAG，其實蠻簡單的一件事情，和大模型API介面對接就好了，但是你去看LangChain的原始碼，整個呼叫鏈路封裝的極其複雜，改都沒法改。
- 上層的業務需求變化太大了，有時候是需要結合自己公司的實際業務情況來進行處理的，這種情況下，還不如自己寫來的快，其實呼叫的鏈路並不複雜
- 就穩定性/事務/資料一致性而言，Python作為企業服務介面主語言是否合適呢？
而我們今天討論的是整個產品的技術架構的選擇，其實在上面業務功能/技術元件抽象那一節，我們已經拆分了功能和技術點，從技術點去看，這已經是一個集眾多服務於一體的綜合技術解決方案了。在應用層面的功能，我們是否還需要像以前那樣，整一套微服務架構出來來開發業務功能？
我的個人看法是：根據團隊配置，微服務可用可不用。但是應用程式必須天然分散式，支援橫向擴充套件叢集，彈性伸縮。
目前這個環境，專案搞微服務，最後的困境可能就是所有服務都是你一個人負責，寫完a服務寫b服務，再來個rpc呼叫，還要考慮資料熔斷、可用性等等，小團隊我覺得完全沒必要折騰！
主要考慮的點：
1、海量非結構化資料處理的提效
在處理RAG產品類中，非結構化資料的處理除了快速解析之外，還需要將文字進行向量化，而我們在技術架構中需要能夠快速的處理這些檔案，透過Pipeline的方式，將非結構化資料最終儲存到向量資料庫中，這裡面傳統的做法不得不用訊息中介軟體MQ，而應用層面的程式則可以透過考慮彈性伸縮的方式，擴充消費節點，以提高整體的處理效率
2、海量向量資料的儲存/計算召回效率
當我們對非結構化資料進行提取後，需要經過Embedding模型進行向量化，這裡面還涉及到文字的Chunking分塊，所以底層向量資料的儲存和計算必然是一個需要更全面的考慮向量資料庫中介軟體，這其中包括：向量召回的效能、資料的儲存/備份、多租戶Schema級別資料許可權等等
3、資料最終一致性
資料的Embedding處理、大模型排程扣費、快取等等，在目前已經眾多服務元件拆分的情況下，整個資料的處理任務我覺得需要保證資料的最終一致性，在分散式場景下，多節點處理時需要特別注意。
4、應用功能原子性（雲原生）
整個應用層的功能，我覺得需要保持獨立，並且保障穩定性，這點其實我覺得在私有化部署/交付的環節比較奏效。如果你是一名運維或者主力開發者，在一個完全內網隔離的環境下部署時，你會體會到這種便捷。
總之，我覺得在應用層面服務，服務端應該做的是：減少配置、輕量化、穩定
4、程式語言/中介軟體選擇？
我們團隊目前的開發語言是Java+Python的組合，主要有職責分工：
- Java：上層業務應用的API介面，任務排程、資料處理等等
- Python：和模型、資料處理、NLP等相關任務以介面的形式開放出來，API介面是無狀態的，所有的資料狀態流轉都在Java端實現
這裡面很多開發可能會有一些擔憂，對於Java語言的選擇，是否在目前的RAG/大模型領域合適？其實最困惑的就是非結構化資料的處理，可能很多開發者看到目前開源的眾多元件或者平臺，都是Python的主技術棧，認為Java處理不了，其實這是完全有誤區的，對於最難處理的PDF檔案提取，Apache PDFBox絕對是值得你深挖的一個元件，當然Python本來就擅長資料處理/分析，可以根據團隊的配置進行執行選擇，這裡面我覺得主要考慮的幾個點：
1、團隊人員配置
根據團隊當前的主流程式語言去做技術架構上的選型和決策，並沒有絕對意義上的以哪個程式語言為主，Java、Python、Go、NodeJS、TypeScript等等都可以。
2、軟體生態&技術成熟度
上層應用產品的開發，肯定首先要考慮有哪些成熟的中介軟體和元件，來開發完成這一眾多的需求，總不能從0到1造輪子，造輪子固然能提升開發人員的水平技能，但是在AI日益發展的今天，為公司產品儘早的找到PMF才是首要任務。需要綜合考慮。
其他的程式語言我不瞭解，就非結構化資料的解析這一塊，其實Python和Java都相對更加豐富和穩 定。
Java語言中比較好用的包括：Apache PDFBox、POI、Tika
Python中包括：PyMuPDF、pdfplumber、pypdf、camelot、python-docx等等
3、穩定性/叢集/高可用
嗯，這裡沒有高併發，因為大家都沒卡😂
大模型的產品相比較傳統的業務在這點上並沒有 太多的區別，穩定性/叢集等特點也是需要的，技術人員在選擇中介軟體時，也應當考慮這一點。
例如MQ訊息中介軟體、快取Redis等等
4、部署實施/交付
沒錯，最後一步部署實施這個環節也需要考慮，Docker確實能帶來極大的便利，但是成本也是需要考量的，目前的Python生態打包整個Docker，壓縮包動輒2、3G起步，其實也是蠻頭疼的，如果你是使用K8s排程來部署，k8s拉取一個10G的映象也不是那麼快的😂
5、最後
AI應用是一個需要快速試錯、功能強大的某一個點去突破，技術架構上，也應當考慮整體的開發效率、生態等等。
這讓我想起來十幾年前的jQuery，一經面世，得到眾多開發者的喜愛，經典名言：
Write Less, Do More!!!
在大模型日益健壯發展的同時，我們的技術架構，是否也應該做一次瘦身呢？
如果你也在關注大模型、RAG檢索增強生成技術，歡迎關注我，一起探索學習、成長～！
