前言
當(dāng)前產(chǎn)品智能化需要在ollama的Deepseek服務(wù)接口的基礎(chǔ)上，再提供RAG（Retrieval-Augmented Generation檢索增強(qiáng)生成）知識庫和聯(lián)網(wǎng)搜索能力。實(shí)現(xiàn)基本的智能化能力。這里簡單整理下對接的思路。
為什么要自建？
1，大模型底座是基于ollama搭建的，ollama在多卡多機(jī)的情況下，性能怕有瓶頸，如果是vllm可能會(huì)好點(diǎn)。
2，在有敏感數(shù)據(jù)的私有化環(huán)境中，走公網(wǎng)的ollama接口可能會(huì)有一定的數(shù)據(jù)安全問題，用戶也有相應(yīng)的限制要求知識庫在本地存儲。
RAG是什么？
RAG Retrieval-Augmented Generation 可以理解為檢索增強(qiáng)生成。簡言之：RAG 技術(shù)將檢索和生成結(jié)合起來，利用外部知識庫（如文檔、數(shù)據(jù)庫、網(wǎng)頁等）來增強(qiáng)模型的生成能力。最先來源于2020年的《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，不過這論文太專業(yè)太數(shù)學(xué)了。這里簡單參考同濟(jì)大學(xué)的論文《Retrieval-Augmented Generation for Large Language Models: A Survey》（╮(╯▽╰)╭網(wǎng)上一大堆翻譯的，可以找下翻譯版本）。RAG技術(shù)很明確，論文所述：
Retrieval-Augmented Generation (RAG) has emerged as a promising solution by incorporating knowledge from external databases. This enhances the accuracy and credibility of the generation, particularly for knowledge-intensive tasks, and allows for continuous knowledge updates and integration of domainspecific information.
檢索增強(qiáng)生成（RAG）通過整合來自外部數(shù)據(jù)庫的知識，已成為一種很有前景的解決方案。這提高了大模型生成的準(zhǔn)確性和可信度，特別是對于知識密集型任務(wù)，并且允許持續(xù)的知識更新和特定領(lǐng)域信息的整合。
關(guān)鍵詞：外部數(shù)據(jù)庫，提高大模型的生成的準(zhǔn)確性和可信度，特定領(lǐng)域的信息，知識庫實(shí)時(shí)更新。由于大模型基本上是基于某一個(gè)時(shí)間段互聯(lián)網(wǎng)的所有信息訓(xùn)練的，如果是在某一些特定的領(lǐng)域，比如公司內(nèi)部的產(chǎn)品文檔，知識信息等大模型就會(huì)出現(xiàn)幻覺。因此結(jié)合一個(gè)外部的私有的專業(yè)的能實(shí)時(shí)更新的數(shù)據(jù)庫對特定領(lǐng)域的問題，大模型能提高準(zhǔn)確的和可信度。
原理架構(gòu)
論文中的圖：
簡單畫下理解下。
一些說明
1，知識庫存在存儲和檢索的過程，存儲需要先將特定領(lǐng)域的文本先向量化存儲到向量庫中。然后用戶交互語句作為查詢語句去查詢向量庫，匹配相識度高的段。返回相關(guān)的段后在和查詢語句一起給到LLM大模型去生成增強(qiáng)后的結(jié)果。
2，存儲和檢索都離不開EmbeddingModel(文本向量化模型也叫文本嵌入模型)。
3，查詢語句也需要向量化QueryEmbedding(查詢語句向量化)，這樣才能在向量數(shù)據(jù)庫中計(jì)算相似度。原始文本同樣也會(huì)存儲到向量庫中。
有哪些落地方式？
現(xiàn)大體了解了RAG的工作思想和原理，如何和Datawings結(jié)合實(shí)現(xiàn)私有的知識庫？主要是兩種思路，一種是直接使用開源的第三方一站式大語言模型（LLM）應(yīng)用開發(fā)平臺，高效快速開發(fā)成本低，不過后續(xù)遷移成本可能較高，又依賴了多個(gè)組件，比如Dify，RagFlow，MaxKB等等。還有一種就是基于LangChain4j+AIService+SearXNG自建RAG+聯(lián)網(wǎng)查詢的能力，簡單靈活，不過需要一定的開發(fā)成本，后續(xù)維護(hù)需要花時(shí)間。下面簡單介紹下兩種方法的大概思路。
實(shí)現(xiàn)思路
一些說明
1，需要在本地交付一個(gè)ollama+文本嵌入模型（nomic-embed-text:latest，shaw/dmeta-embedding-zh:latest等）。需要高性能的CPU或者GPU。
2，自建知識庫有主要有兩種思路，a)使用Dify/RagFlow/AnythingLLM等開源的RAG平臺。b)使用langchain4j+vectorDB(elasticsearch/clickhouse/chroma等向量庫)自己開發(fā)一個(gè)RAG。大模型使用外部開放API的模型，然后在自建的RAG平臺中使用或者實(shí)現(xiàn)文本嵌入Embedding、Workflow、Agent的能力。
LangChain4j+AIService+SearXNG(自建)
一些說明
1，自建私有化基于Langchain4j框架java版本，當(dāng)然肯定推薦python版本。
2，Langchain4j AiService能實(shí)現(xiàn)各種復(fù)雜的AI能力，比如和各種組件結(jié)合，RAG本地知識庫（Embedding），聯(lián)網(wǎng)查詢（WebSearch），尤其是多種格式化輸入和格式化輸出（直接回答，集合類型，分類任務(wù)，數(shù)據(jù)提取，自定義對象，訪問額外信息（如令牌使用量），JSON 模式），以及Tools (Function Calling)做一些自定義的專業(yè)數(shù)學(xué)計(jì)算和邏輯判斷，推薦使用。
3，VectorDB為向量庫，存儲私有文檔向量化后的數(shù)據(jù)。一般業(yè)內(nèi)比較主流（Dify，RagFlow）的是使用elasticsearch，核心算法是KNN，可以查看es官方文檔對KNN算法的說明，英文版本(elastic.co/what-is/knn)，中文版本(elastic.co/cn/what-is/knn)。其他langchain4j支持的向量庫可以查看文檔。
4，資源庫就是需要被例如deepseek等大模型查詢的私有化文檔，這些文檔可以存儲本地FileSystem中，也可以存到S3中，只要能通過文件流讀取解析成Document向量化存儲到向量庫即可，可以查看Langchain4j的官方文檔使用說明。
5，searxng主要是查詢互聯(lián)網(wǎng)數(shù)據(jù)的代理，尷尬的是沒法配置國內(nèi)的搜索引擎，不過可以使用bing。
6，最后整體開發(fā)完成后，一樣服務(wù)直接調(diào)用Langchain4j開發(fā)的模塊或代理做聯(lián)網(wǎng)查詢和本地知識庫查詢。
代碼實(shí)現(xiàn)
參考本欄文檔《Langchain4j實(shí)現(xiàn)本地RAG和聯(lián)網(wǎng)查詢》
Dify(推薦)
一個(gè)快速的一站式大語言模型（LLM）應(yīng)用開發(fā)平臺。頁面化操作加速生成式AI應(yīng)用的創(chuàng)建和部署，不需要想langchain4j那樣還需要開發(fā)代碼，dify直接使用即可提供agent，restapi，workflow等能力。dify相對于其他的RAG開源工具，資源消耗較少。因此選擇此工具，當(dāng)然也可以選擇Ragflow（資源成本太高，太重太大了），大體的模塊架構(gòu)是差不多的，都是以向量庫存儲為主，然后在agent思想的參考下，包裝了一些組件，比如聯(lián)網(wǎng)查詢，第三方大模型集成，頁面操作等等。
為快速解決知識庫和聯(lián)網(wǎng)查詢功能的智能化需求，強(qiáng)烈建議先使用開源的第三方的RAG或一站式開發(fā)平臺。比較好的有Dify(Apache License 2.0+一些商業(yè)化附加條件)，Ragflow(Apache License Version 2.0)
原理架構(gòu)
官方文檔有對應(yīng)的架構(gòu)圖。不過我們業(yè)務(wù)方不需要關(guān)注怎么復(fù)雜的細(xì)節(jié)。我們只需要關(guān)注大體的部署結(jié)構(gòu)和技術(shù)棧即可，方便和我們的業(yè)務(wù)服務(wù)結(jié)合。
一些說明
1，redis和pg存儲Dify的業(yè)務(wù)數(shù)據(jù)，如果想把pg換成mysql，比較麻煩。
2，業(yè)務(wù)服務(wù)有三個(gè)api，worker，web。官方文檔沒看到具體的功能說明，不過看日志和名字大概了解到api為主要的核心對內(nèi)對外接口調(diào)用，web為頁面能力監(jiān)控和管理，woker為一些異步任務(wù)的調(diào)度和執(zhí)行。
3，ssrf_proxy為系統(tǒng)網(wǎng)絡(luò)代理，比如控制容器的網(wǎng)絡(luò)安全限制。sandbox為客戶提交的代碼做一個(gè)隔離的調(diào)試環(huán)境，以及一些資源限制。
4，向量數(shù)據(jù)庫，dify支持的向量數(shù)據(jù)庫可以查看docker-compose.yaml文件，比較熟悉的主要有默認(rèn)的weaviate，chroma，opensearch，elasticsearch。
5，nginx主要為頁面靜態(tài)文件和對外接口代理。
6，dify相對于langchain4j最主要的是不需要多少代碼開發(fā)，在頁面上就能完成對應(yīng)的功能，比如api，agent，workflow。但是麻煩在依賴了太多的組件。
使用案例
RAG+聯(lián)網(wǎng)查詢
Workflow
對外API
這里使用一個(gè)簡單的chat模擬對外API能力，需要注意的dify是和openai的兼容性較差，后續(xù)如果遷移到openai兼容性較高（入ollama）的則需要一定的遷移工作。
總結(jié)
1，只提供大概的落地思路，具體的首先細(xì)節(jié)比較繁瑣和深入，拋磚引玉，具體情況按具體分析具體解決。
2，如果使用Dify，需要考慮高可用的部署問題，同時(shí)由于Dify的接口和OpenAI格式的兼容性較差，要考慮后續(xù)遷移的問題。
3，Langchain4j的Aiservice和Dify的Agent+workflow可以實(shí)現(xiàn)復(fù)雜的結(jié)構(gòu)化數(shù)據(jù)返回和邏輯判斷，甚至可以實(shí)現(xiàn)圖表展示。
