北京
一個團隊有份精心撰寫的200頁API文檔，但新來的工程師前兩周不是在讀它，而是在Slack里反復問同樣的問題，然后被一句“去看第47頁”打回來。文檔沒錯，甚至寫得很好——但當所有人找信息的速度跟不上提問的速度時，準確的文檔等于廢紙。這就是檢索增強生成（RAG）專門解決的尷尬。
直接把整份PDF塞進大模型里問？上下文窗口直接爆掉，每次請求燒掉大量token，模型還會在密密麻麻的文本里丟掉線索。RAG走的是另一條路：提前把文檔切成小段，每次提問只撈出最相關的三兩段喂給模型。模型看到的上下文干凈聚焦，答案也只來自文檔里真正寫的內容，而不是模型訓練時記住的半真半假。下面我們從零到一搭一套，上傳任意PDF，用自然語言提問，讓系統自己從文檔里找答案。
整套技術棧不會讓你掏一分錢：Node.js加Express作為后端，Google Gemini負責把文字段落變成向量，Groq提供文本生成的大模型，pgvector在Docker里跑向量存儲。不需要綁信用卡，沒有試用期。完整代碼掛在GitHub上，倉庫名叫nodejs-rag-chatbot。
第一步：你多半低估了切塊和重疊的重要性。
RAG的攝取階段，每次上傳文檔時會先抽取出純文本，按每段400到600個字符切開，塊與塊之間保留一點重疊。這么做的邏輯很簡單：關鍵句如果恰好落在塊的邊界上，沒有重疊就會被攔腰截斷，搜索時再牛的向量也救不回來。切完后，每一段跑一次嵌入模型，輸出一長串代表句子語義的數字，也就是向量，然后把文本和向量一起存進Postgres。
第二步：同一個嵌入模型必須上下場都用。
提問階段，用戶的文字也會被同一個模型轉成向量，再到數據庫里找出距離最近的向量對應的那幾段文字。取排在最前面的5塊，拼成一個上下文段落喂給大模型，大模型就只基于這些片段給出回答。這里特別容易踩的坑是：如果攝取時用A嵌入模型，查詢時換成B，生成的向量坐標所代表的幾何空間完全對不上，就像在蘋果堆里找蘋果，卻拿著一張橘子的地圖。
第三步：向量搜索之所以聰明，因為它抓的是語義，不是關鍵詞。
文檔里寫著“終止該進程”，用戶問的是“怎么停掉它”。純粹靠字符串匹配，這兩句根本搭不上線。但嵌入模型捕捉的是“終止”和“停掉”的語義相似度，向量距離近的塊自然就被撈上來了。這也是RAG對比傳統關鍵詞搜文檔最核心的升級。
第四步：免費不等于湊合，這套方案的內核相當精打細算。
架構刻意做得極簡，只留兩個接口：一個POST /ingest接受PDF上傳、完成切塊和向量存庫，另一個接口用來接收問題、返回基于文檔原文生成的回答。沒有多余組件，所以維護成本也極低。而且Gemini的嵌入和Groq的文本生成目前都有慷慨的免費額度，跑通一個團隊內部的文檔問答系統，完全可以做到零賬單。
第五步：別高估大模型的記憶力，也別低估你手里文檔的價值。
這套工具最實用的場景就是讓沉在硬盤里的API文檔、內部規范、研究論文真正變成“問得到”的知識。與其每回都靠Ctrl+F賭運氣，不如讓文檔自己長出回答問題的本事。所有選型都親測可跑，你只需要一行git clone，再加一個docker compose up。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
