200頁(yè)文檔還在Ctrl+F？免費(fèi)RAG問(wèn)答機(jī)器人，精準(zhǔn)定位第47頁(yè)

一個(gè)團(tuán)隊(duì)有份精心撰寫(xiě)的200頁(yè)API文檔，但新來(lái)的工程師前兩周不是在讀它，而是在Slack里反復(fù)問(wèn)同樣的問(wèn)題，然后被一句“去看第47頁(yè)”打回來(lái)。文檔沒(méi)錯(cuò)，甚至寫(xiě)得很好——但當(dāng)所有人找信息的速度跟不上提問(wèn)的速度時(shí)，準(zhǔn)確的文檔等于廢紙。這就是檢索增強(qiáng)生成（RAG）專(zhuān)門(mén)解決的尷尬。

直接把整份PDF塞進(jìn)大模型里問(wèn)？上下文窗口直接爆掉，每次請(qǐng)求燒掉大量token，模型還會(huì)在密密麻麻的文本里丟掉線(xiàn)索。RAG走的是另一條路：提前把文檔切成小段，每次提問(wèn)只撈出最相關(guān)的三兩段喂給模型。模型看到的上下文干凈聚焦，答案也只來(lái)自文檔里真正寫(xiě)的內(nèi)容，而不是模型訓(xùn)練時(shí)記住的半真半假。下面我們從零到一搭一套，上傳任意PDF，用自然語(yǔ)言提問(wèn)，讓系統(tǒng)自己從文檔里找答案。

整套技術(shù)棧不會(huì)讓你掏一分錢(qián)：Node.js加Express作為后端，Google Gemini負(fù)責(zé)把文字段落變成向量，Groq提供文本生成的大模型，pgvector在Docker里跑向量存儲(chǔ)。不需要綁信用卡，沒(méi)有試用期。完整代碼掛在GitHub上，倉(cāng)庫(kù)名叫nodejs-rag-chatbot。

第一步：你多半低估了切塊和重疊的重要性。
RAG的攝取階段，每次上傳文檔時(shí)會(huì)先抽取出純文本，按每段400到600個(gè)字符切開(kāi)，塊與塊之間保留一點(diǎn)重疊。這么做的邏輯很簡(jiǎn)單：關(guān)鍵句如果恰好落在塊的邊界上，沒(méi)有重疊就會(huì)被攔腰截?cái)?，搜索時(shí)再牛的向量也救不回來(lái)。切完后，每一段跑一次嵌入模型，輸出一長(zhǎng)串代表句子語(yǔ)義的數(shù)字，也就是向量，然后把文本和向量一起存進(jìn)Postgres。

第二步：同一個(gè)嵌入模型必須上下場(chǎng)都用。
提問(wèn)階段，用戶(hù)的文字也會(huì)被同一個(gè)模型轉(zhuǎn)成向量，再到數(shù)據(jù)庫(kù)里找出距離最近的向量對(duì)應(yīng)的那幾段文字。取排在最前面的5塊，拼成一個(gè)上下文段落喂給大模型，大模型就只基于這些片段給出回答。這里特別容易踩的坑是：如果攝取時(shí)用A嵌入模型，查詢(xún)時(shí)換成B，生成的向量坐標(biāo)所代表的幾何空間完全對(duì)不上，就像在蘋(píng)果堆里找蘋(píng)果，卻拿著一張橘子的地圖。

第三步：向量搜索之所以聰明，因?yàn)樗サ氖钦Z(yǔ)義，不是關(guān)鍵詞。
文檔里寫(xiě)著“終止該進(jìn)程”，用戶(hù)問(wèn)的是“怎么停掉它”。純粹靠字符串匹配，這兩句根本搭不上線(xiàn)。但嵌入模型捕捉的是“終止”和“停掉”的語(yǔ)義相似度，向量距離近的塊自然就被撈上來(lái)了。這也是RAG對(duì)比傳統(tǒng)關(guān)鍵詞搜文檔最核心的升級(jí)。

第四步：免費(fèi)不等于湊合，這套方案的內(nèi)核相當(dāng)精打細(xì)算。
架構(gòu)刻意做得極簡(jiǎn)，只留兩個(gè)接口：一個(gè)POST /ingest接受PDF上傳、完成切塊和向量存庫(kù)，另一個(gè)接口用來(lái)接收問(wèn)題、返回基于文檔原文生成的回答。沒(méi)有多余組件，所以維護(hù)成本也極低。而且Gemini的嵌入和Groq的文本生成目前都有慷慨的免費(fèi)額度，跑通一個(gè)團(tuán)隊(duì)內(nèi)部的文檔問(wèn)答系統(tǒng)，完全可以做到零賬單。

第五步：別高估大模型的記憶力，也別低估你手里文檔的價(jià)值。
這套工具最實(shí)用的場(chǎng)景就是讓沉在硬盤(pán)里的API文檔、內(nèi)部規(guī)范、研究論文真正變成“問(wèn)得到”的知識(shí)。與其每回都靠Ctrl+F賭運(yùn)氣，不如讓文檔自己長(zhǎng)出回答問(wèn)題的本事。所有選型都親測(cè)可跑，你只需要一行g(shù)it clone，再加一個(gè)docker compose up。