如果你做過課程答疑大概率體會過這種感覺課程資料里明明寫得清清楚楚但總有同學在群里問“這個知識點在課件哪一部分”“第三章到底考不考這段證明”“兩個概念的區(qū)別課本里有沒有原話”。你一遍一遍翻 PDF、復制粘貼、發(fā)截圖稍微講偏一點學生拿去對照原文立刻穿幫。于是很多人想到一個偷懶方案把課程資料直接扔給大模型讓它來答。試過一次就會發(fā)現模型講得很流利卻在關鍵術語上開始自由發(fā)揮。原因不難理解通用大模型沒有真正讀過你這份講義它只是在憑訓練階段形成的知識慣性作答遇到課程里特有的定義、范圍和考核重點自然會“一本正經地胡說八道”。課程資料問答助手這個案例解決的就是這個問題。它本質上是一個基于檢索增強生成Retrieval-Augmented GenerationRAG的應用先把課程資料切分、向量化、存進向量數據庫用戶提問時先檢索最相關的片段再把片段和問題一起交給大模型生成答案。這樣既保留了大模型的表達能力又把回答限制在了可信的資料范圍內。這類應用是目前大模型落地中最常見、也最穩(wěn)的一類值得每一個后端開發(fā)和算法工程師親手跑通。本文會從問題定義出發(fā)講清楚原理再給出完整的環(huán)境準備、代碼實現、運行驗證和排錯思路。你可以直接照著做也可以把它改造成自己的課程問答工具或內部知識庫問答系統。1. 這個案例真正要解決的問題1.1 直接問大模型為什么不行我們先做一個思想實驗。把一本《數據庫系統概論》的 PDF 扔給 ChatGPT 或任何通用大模型問“本課程的考核范圍是什么”模型大概率會給出一個結構清晰、措辭正式的答案但它根本不知道你的課程大綱也不知道老師期末劃了哪些重點。它給出的只是一個“看起來合理的通用回答”。這就是大模型幻覺的典型場景。模型的本質是語言模型它的目標是生成通順、連貫的文本而不是保證事實正確。當問題超出它的知識范圍或者涉及某個特定機構的私有資料時它只能靠“預測下一個詞”來補齊內容。直接問答還有一個問題知識過期。課程大綱每年都可能調整教材版本也會更新但模型的訓練數據是靜態(tài)的。如果你想回答的是“今年這門課的項目要求”模型不可能知道。1.2 傳統搜索為什么不夠有人會說那我不讓大模型答我自己用關鍵詞搜索課件 PDF搜到相關片段再復制給模型不就行了這在小規(guī)模場景確實可行但有兩個明顯瓶頸。第一關鍵詞搜索不理解語義。用戶問“數據庫宕機之后怎么恢復數據”關鍵詞可能是“故障恢復”用戶問“ACID 是什么意思”課件里寫的可能是“原子性、一致性、隔離性、持久性”。關鍵詞對不上搜索就失效。第二全文搜索返回的是“相關文檔”不是“答案”。用戶得到的是一堆 PDF 片段還需要自己閱讀、定位、整合。1.3 RAG 怎么解決RAG 的思路并不復雜一共兩步先檢索再生成。系統先把課程資料離線切分成小塊用 Embedding 模型轉成向量建立索引。用戶提問時把問題也轉成向量在索引里找出語義最相似的若干片段最后把這些片段作為“參考資料”拼進 Prompt讓大模型基于這些材料作答。方案是否理解語義是否基于資料作答是否適合大規(guī)模資料主要風險直接問大模型是否是幻覺嚴重、知識過期關鍵詞搜索否是中同義表述召回不到、需要人工整理RAG是是是檢索效果依賴切片與向量模型質量一句話總結RAG 不是讓模型更聰明而是讓模型“帶著資料答題”。這也正是課程資料問答助手的核心價值。它把一個通用的、可能幻覺的大模型變成一個只基于你提供的課程資料回答問題的垂直問答工具。2. 核心概念與 RAG 工作原理要把這個案例做明白先要理解五個概念文本切分、Embedding、向量數據庫、相似度檢索、Prompt 注入。2.1 文本切分Chunking一整份 PDF 動輒幾十萬字不可能直接把全文塞進 Prompt。大模型有上下文長度限制而且傳入冗余內容會稀釋關鍵信息。因此需要把資料切分成小塊專業(yè)說法叫 Chunk。切分不是簡單按字數截斷。課程資料有天然的語義邊界比如章節(jié)、段落、列表項。按語義邊界切出來的塊每一塊才可能表達一個完整的意思。實際工程里常用遞歸字符切分器優(yōu)先按段落切段落太長再按句子切。切分粒度直接決定檢索效果。塊太大檢索出來的內容可能涵蓋多個主題不夠精準塊太小單塊信息不完整模型可能看不到上下文。課程類資料通常建議 300 到 600 個字符左右并設置 10% 到 20% 的重疊避免關鍵內容恰好被切斷。2.2 文本向量化Embedding計算機無法直接比較兩段文本的語義相似程度需要先把它轉成向量。Embedding 模型做的事就是把一段文本映射成一個固定維度的向量數組。這里有一個關鍵直覺語義越接近的文本它們的向量在高維空間里的距離越近?！皵祿旎謴汀焙汀肮收虾笳一財祿彪m然用詞完全不同但語義相似向量距離就近?！皵祿旎謴汀焙汀敖裉熘形绯允裁础闭Z義相差很遠向量距離就遠。所以向量檢索能解決關鍵詞搜索解決不了的“同義表述”問題這是整個問答助手理解用戶提問的基礎。2.3 向量數據庫向量數據庫負責存儲和檢索向量。課程案例里常用的選擇是 Chroma它是輕量級本地向量庫安裝簡單、無需獨立部署適合教學和中小型項目。生產環(huán)境中也可以換成 Milvus、Qdrant 或 Elasticsearch 的向量檢索能力。向量庫的核心操作有兩個寫入和查詢。寫入時為每個文本切片生成向量并存儲查詢時把問題向量和庫里所有向量做相似度計算返回最相似的 Top-K 條記錄。2.4 Prompt 注入檢索到相關片段之后系統把這些片段組裝成一段帶指令的文本連同用戶問題一起交給大模型。Prompt 里通常會寫明請根據提供的資料回答問題如果資料中沒有相關內容請明確說明不要編造可以參考資料中的原句回答如果可能給出資料來源或頁碼。這一步是整個系統最后的“護欄”。Prompt 設計得好大模型就會克制自己優(yōu)先引用資料內容Prompt 設計得不好模型還是會忍不住自由發(fā)揮。2.5 完整流程拆解整個課程資料問答助手的工作流程可以用下面這段文字概括課程資料解析 ↓ 文本切分Chunking ↓ Embedding 向量化 ↓ 寫入向量數據庫 ↓ 用戶輸入問題 ↓ 問題向量化 ↓ 向量庫相似度檢索 Top-K ↓ 相關片段注入 Prompt ↓ 大模型生成回答前半段是離線構建索引只做一次后半段是在線問答每次提問都會執(zhí)行。理解了這個流程后面看代碼就會非常輕松。3. 適用場景與技術邊界3.1 適合什么場景課程資料問答助手是 RAG 的一種典型形態(tài)。只要滿足“有固定資料、需要基于資料回答、資料更新頻率不高”這三個條件都可以套用這套實現課程答疑教學大綱、講義、實驗指導書、往年試題整理內部知識庫公司的技術文檔、運維手冊、項目 Wiki產品 FAQ產品說明書、常見問題文檔、客服話術庫政策與制度問答機構內部制度文件、合規(guī)手冊科研文獻輔助讓模型基于指定論文回答相關問題。3.2 不適合什么場景RAG 不是萬能的課程資料問答助手也有明顯邊界。第一不適合實時動態(tài)數據。比如“當前服務器的實時狀態(tài)”“今天股票漲跌”這些數據不在靜態(tài)資料里檢索不到就是答不出來。第二不適合強推理型問題。如果問題需要跨多個章節(jié)、多步推理才能得出結論單個 Top-K 片段往往不夠。這時候需要引入多輪檢索、重排序或 Agent 式拆解復雜度會明顯上升。第三不適合以圖片、公式、表格為主的資料。PDF 解析對文本效果好但面對復雜公式和圖表解析鏈路要額外引入 OCR 或多模態(tài)模型不是本文案例能覆蓋的。3.3 邊界判斷對這個案例的評價要客觀它做的是“基于資料的問答”不是“基于資料的推理”。如果你的課程資料里沒有“項目答辯評分標準”這段內容模型再強也不該回答出來。正確做法是讓它明確回答“資料中未找到相關內容”。這不是系統的缺陷反而是系統可靠性的體現。4. 環(huán)境準備與前置條件4.1 運行環(huán)境建議使用 Python 3.10 或更高版本操作系統的差異不大Windows、macOS、Linux 都可以。之所以要求相對新的 Python 版本是因為 LangChain、Chroma 等庫的新版本已經逐步放棄對舊版本的支持。先創(chuàng)建一個獨立的虛擬環(huán)境避免和系統 Python 環(huán)境互相污染python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate4.2 依賴庫當前案例需要安裝以下依賴# 文件路徑requirements.txt langchain0.1.0 langchain-community0.0.10 langchain-openai0.0.5 chromadb0.4.22 openai1.10.0 pypdf3.17.0 python-dotenv1.0.0這里有一點要特別注意LangChain 的版本迭代非常快API 調整頻繁。早期版本的 OpenAIEmbeddings 從langchain.embeddings導入新版本改成了從langchain_openai導入。本文代碼采用新版本寫法如果你用的是更早的版本請根據實際庫的導入路徑修改。安裝命令pip install -r requirements.txt4.3 大模型服務配置本案例需要一個支持 OpenAI 兼容接口的大模型服務。無論你用的是云服務廠商的 API還是本地部署的推理服務只要接口風格是chat/completions和embeddings都可以接入。配置項包括四個API Key調用模型的身份憑證Base URL服務地址比如https://api.example.com/v1Chat Model負責生成回答的模型名Embedding Model負責向量化的模型名。建議把這些配置放到.env文件里不要把密鑰硬編碼進代碼# 文件路徑.env LLM_API_KEYsk-xxxx LLM_BASE_URLhttps://api.example.com/v1 LLM_MODEL你的對話模型名稱 EMBEDDING_MODEL你的Embedding模型名稱注意.env文件不要提交到 Git 倉庫建議在.gitignore中加上.env。5. 完整代碼實現5.1 項目結構建議按下面的結構組織代碼便于理解和擴展course-qa-assistant/ ├── .env ├── requirements.txt ├── data/ │ └── 數據庫系統概論.pdf ├── build_index.py ├── ask.py └── direct_ask.pydata目錄放課程資料build_index.py負責構建向量索引ask.py是問答主程序direct_ask.py是用于對比的“直接問大模型”腳本。5.2 配置環(huán)境變量先寫一個公共配置模塊減少重復代碼。這里直接用dotenv加載.env文件# 文件路徑config.py import os from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL) LLM_MODEL os.getenv(LLM_MODEL) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL)5.3 構建向量索引這一步的核心任務是把課程 PDF 解析成文本切分成小塊向量化后寫入 Chroma# 文件路徑build_index.py from config import LLM_API_KEY, LLM_BASE_URL, EMBEDDING_MODEL from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma PDF_PATH data/數據庫系統概論.pdf PERSIST_DIR ./chroma_db COLLECTION_NAME course_notes def load_and_split(): loader PyPDFLoader(PDF_PATH) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , ], ) chunks splitter.split_documents(docs) return chunks def main(): chunks load_and_split() print(f文檔解析完成共切分為 {len(chunks)} 個切片) embeddings OpenAIEmbeddings( modelEMBEDDING_MODEL, openai_api_keyLLM_API_KEY, openai_api_baseLLM_BASE_URL, ) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directoryPERSIST_DIR, collection_nameCOLLECTION_NAME, ) print(f向量索引構建完成已寫入 {len(chunks)} 個切片到 {PERSIST_DIR}) if __name__ __main__: main()代碼邏輯拆解PyPDFLoader負責解析 PDF讀取每一頁內容RecursiveCharacterTextSplitter按語義邊界切分文本優(yōu)先段落其次是句子和標點OpenAIEmbeddings調用 Embedding 模型生成向量Chroma.from_documents一次性完成向量化并持久化到本地目錄。這里真正容易踩坑的地方是chunk_size和chunk_overlap的選擇。如果切出來的塊主題混雜后續(xù)檢索精度會明顯下降如果重疊太小關鍵句子又容易被攔腰截斷。課程資料建議先設定 500 和 80跑完再根據實際問答效果調整。5.4 問答主流程索引構建完成后進入核心的問答環(huán)節(jié)# 文件路徑ask.py from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL, EMBEDDING_MODEL from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from openai import OpenAI PERSIST_DIR ./chroma_db COLLECTION_NAME course_notes def create_retriever(k4): embeddings OpenAIEmbeddings( modelEMBEDDING_MODEL, openai_api_keyLLM_API_KEY, openai_api_baseLLM_BASE_URL, ) vectorstore Chroma( persist_directoryPERSIST_DIR, collection_nameCOLLECTION_NAME, embedding_functionembeddings, ) return vectorstore.as_retriever(search_kwargs{k: k}) def build_prompt(question, context): return f請根據提供的課程資料回答問題。 要求 1. 優(yōu)先使用課程資料中的內容作答。 2. 如果資料中沒有相關內容請明確回答“資料中未找到相關內容”不要編造。 3. 回答盡量保留資料中的專業(yè)術語和原句。 課程資料 {context} 問題{question} def ask(question, retriever): hits retriever.invoke(question) context \n\n.join( f【資料片段 {i 1}】\n{doc.page_content} for i, doc in enumerate(hits) ) client OpenAI( api_keyLLM_API_KEY, base_urlLLM_BASE_URL, ) response client.chat.completions.create( modelLLM_MODEL, messages[{role: user, content: build_prompt(question, context)}], temperature0.2, ) answer response.choices[0].message.content return answer, hits if __name__ __main__: retriever create_retriever(k4) while True: question input(\n請輸入問題輸入 exit 退出) if question.strip().lower() exit: break answer, hits ask(question, retriever) print(\n回答, answer) print(\n參考片段) for i, doc in enumerate(hits): source doc.metadata.get(source, 未知) page doc.metadata.get(page, 未知) print(f{i 1}. {doc.page_content[:60]}...) print(f 來源{source}頁碼{page})這段代碼有三個設計要點。第一個要點是temperature0.2。回答類任務希望模型盡量忠實于資料溫度過高會引入隨機性溫度設為低值可以降低自由發(fā)揮的概率。當然它不能完全消除幻覺但能顯著改善。第二個要點是 Prompt 中的“資料不足就明說”。這是對抗幻覺最有效的手段之一。如果檢索到的片段本身就沒有答案模型至少應該承認不知道而不是硬答。第三個要點是返回hits并打印來源。這個設計對課程問答尤其重要。學生看到“這個結論來自第三章第 12 頁”時信任度會遠高于一個孤零零的 AI 答案。這也是把 RAG 問答從“能用”變成“好用”的關鍵一步。5.5 對照組直接問大模型為了直觀對比再寫一個不經過檢索、直接問模型的腳本# 文件路徑direct_ask.py from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL from openai import OpenAI def direct_ask(question): client OpenAI( api_keyLLM_API_KEY, base_urlLLM_BASE_URL, ) response client.chat.completions.create( modelLLM_MODEL, messages[{role: user, content: question}], temperature0.3, ) return response.choices[0].message.content if __name__ __main__: question input(請輸入問題) print(direct_ask(question))這個腳本的存在很有價值。它讓你能快速對比同一個問題在“有 RAG”和“沒有 RAG”兩種情況下的差異從而理解這個案例真正改變的是什么。6. 運行與效果驗證6.1 構建索引把課程 PDF 放到data目錄后執(zhí)行python build_index.py預期輸出文檔解析完成共切分為 385 個切片 向量索引構建完成已寫入 385 個切片到 ./chroma_db如果這個步驟報錯絕大多數原因是依賴安裝不完整或者 PDF 路徑不正確?？梢韵葯z查data目錄下的文件名與代碼中PDF_PATH是否一致。6.2 測試問答繼續(xù)執(zhí)行python ask.py輸入一個課程相關問題。下面是一種可能的運行效果用于幫助你判斷系統行為是否符合預期請輸入問題輸入 exit 退出事務的 ACID 特性是什么 回答 根據課程資料事務的 ACID 特性包括原子性Atomicity、一致性Consistency、隔離性Isolation和持久性Durability。資料中詳細說明了幾種特性的定義和實現方式例如原子性由日志和回滾機制保證持久性需要依賴數據庫的恢復機制。 參考片段 1. 事務是數據庫操作的基本執(zhí)行單元它必須滿足 ACID 特性... 來源data/數據庫系統概論.pdf頁碼8 2. 原子性要求事務中的所有操作要么全部執(zhí)行要么全部不執(zhí)行... 來源data/數據庫系統概論.pdf頁碼8注意這里回答末尾給出了頁碼。這是 RAG 應用最典型的“可溯源”特征也是判斷系統是否跑通的重要標志。6.3 對比直接問答再執(zhí)行python direct_ask.py同樣輸入“事務的 ACID 特性是什么”。沒有資料注入時模型給出的回答通常更通用可能是一段標準的教科書式定義但不會引用你這門課的講義也不會定位到具體章節(jié)。兩種方式對比后你可以得到本文最核心的一個判斷RAG 并不負責“知識”它負責的是“讓模型的回答有根據”。模型能力決定回答是否通順檢索鏈路決定回答是否忠于資料兩者缺一不可。6.4 如何判斷系統是否成功不要只看回答是否通順要按下面的標準判斷回答是否來源于課程資料而不是模型泛泛的常識回答是否包含資料中的特定概念、表述、頁碼或章節(jié)當提問內容明顯不在資料范圍內時模型是否敢于說“未找到相關內容”對同一問題的不同問法比如“ACID 是什么”和“事務的四個特性有哪些”是否能檢索到相似結果。如果第 1、2 條不滿足問題大概率出在檢索環(huán)節(jié)如果第 3 條不滿足問題大概率出在 Prompt 設計如果第 4 條不滿足問題大概率出在 Embedding 模型對中文語義的理解能力上。7. 常見問題與排查思路問題現象可能原因排查方式解決方案啟動時報錯找不到 langchain_openaiLangChain 版本過舊或缺少依賴查看完整錯誤堆棧安裝或升級 langchain-openai確認版本兼容Embedding 調用報 401 或 403API Key 錯誤、Base URL 不匹配用 curl 單獨測試接口連通性檢查 .env 配置確認密鑰和服務地址正確中文亂碼PDF 本身掃描版或編碼異常查看原始文本內容是否正常對掃描版 PDF 接入 OCR或改用 Word/文本格式每次運行都在重新構建索引向量庫沒有正確持久化檢查 chroma_db 目錄是否存在確認 persist_directory 使用絕對路徑或穩(wěn)定相對路徑回答內容與課程資料無關向量檢索返回了不相關片段打印 hits 查看召回內容調整切片大小、增加 Top-K、更換 Embedding 模型模型仍然編造資料外的內容Prompt 約束不足或資料未命中檢查檢索片段是否包含答案強化 Prompt“未找到就明說”提高檢索召回率回答不完整切片太小上下文被切斷查看參考片段是否邏輯完整增大 chunk_size 或 chunk_overlap提問響應速度慢Embedding 檢索慢或模型輸出長觀察耗時分布使用緩存、減少 Top-K或換用更快的模型API 提示上下文超長拼接的上下文片段過多查看實際 token 用量減小 k 值或精簡 Prompt 中的資料格式在這張表里最值得新手關注的是第二條。很多同學會把 API Key 直接硬編碼在代碼里出了問題又不知道該排查環(huán)境還是代碼。建議統一使用.env管理配置這樣換 Key、換模型、換服務地址都只改一個文件。8. 從案例到生產的工程建議8.1 切片參數要根據資料類型調優(yōu)課程講稿、實驗手冊、習題答案三類資料的語義密度完全不同。講稿可以適當增大 chunk_size習題答案則應該盡量保持“一題一塊”的完整性。不要指望一組參數吃遍所有場景建議準備一個幾十條的測試問題集每次調整參數后統一跑一遍用召回率和回答正確率做判斷。8.2 元數據設計要提前做在課程問答場景page、chapter、title這些元數據不是可有可無的裝飾而是回答可信度的核心來源。構建索引時就應該把來源信息寫入 metadata問答時隨片段一起返回。否則等索引建完再補元數據就只能刪庫重建了。8.3 回答必須可溯源這也是課程問答助手與通用聊天機器人的關鍵差異。生產環(huán)境里的 RAG 問答界面應該在答案下方展示“引用片段”并且支持點擊跳轉到原文位置。這個設計能大幅降低用戶對 AI 回答的不信任感也能讓系統在出錯時快速定位到是檢索錯了還是生成錯了。8.4 建立答案緩存課程資料的更新頻率通常不高高頻問題可能只有幾十個?？梢栽跀祿炖锞彺妗皹藴驶瘑栴} 回答 引用片段”命中緩存就直接返回避免每次調用模型產生費用和延遲。推薦使用向量相似度或哈希算法做問題歸一化。8.5 安全與權限如果課程資料涉及未公開的考試題目或內部文檔需要考慮權限控制。向量數據庫本身不提供細粒度權限建議在應用層做數據隔離比如每個用戶只能檢索自己有權限訪問的資料集合。API Key 是敏感憑證一定不能提交到代碼倉庫也要定期輪換。8.6 從單文件到多文檔本文案例只處理一個 PDF但真實課程往往有多份講義、多篇論文、多份實驗指導書。擴展方式也不復雜將PDF_PATH改成目錄遍歷邏輯支持批量加載文件每個文件的相對路徑寫入source元數據查詢時按source字段做過濾。架構不改變只是數據源變多。8.7 建立評測集判斷系統好不好不能靠一兩句“感覺還行”。最有效的做法是積累一個評測集收集 20 到 50 個真實高頻問題人工標注正確答案和對應的資料片段每次修改代碼或參數后都跑一遍。評測集不用大但一定要來自真實用戶這比任何理論分析都更能暴露問題。9. 總結與下一步實踐建議課程資料問答助手是一個“小但完整”的 RAG 實戰(zhàn)案例。它包含了 PDF 解析、文本切分、向量化、向量檢索、Prompt 注入和大模型調用六大環(huán)節(jié)覆蓋了 RAG 應用開發(fā)的主干鏈路。跑通這個案例之后你已經可以回答這些問題為什么直接問大模型會產生幻覺為什么關鍵詞搜索不夠用Embedding 和向量檢索在中間扮演什么角色一個合格的知識庫問答系統至少需要哪些組成部分如果要把這個案例應用到真實項目我建議你按下面順序推進。第一步把手里的課程資料替換成自己的真實內容跑通一遍完整的構建索引和問答流程確認 PDF 解析沒有亂碼、檢索結果基本相關。第二步整理 20 個真實高頻問題建立最簡評測集。用這些問題跑一輪把檢索結果全部打印出來看一遍你會發(fā)現很多問題的根源不是模型不給力而是切片切得不好、檢索召回了不相關的片段。第三步針對發(fā)現的問題調參數。先調整切片大小和重疊再考慮替換 Embedding 模型最后才去優(yōu)化 Prompt。很多人一上來就瘋狂調 Prompt但 Prompt 再好資料沒檢索到也是白搭。第四步補充頁面引用和緩存機制讓系統真正接近可用狀態(tài)。把答案下方的“參考片段”原樣展示給用戶這往往是整個系統最受認可的功能。值得繼續(xù)深入的方向也很多如何引入重排序模型提升檢索精度如何處理課程資料里的復雜公式和圖片如何把單輪問答擴展成多輪對話如何在不重新訓練模型的前提下讓系統快速適配新學期的課程。這些方向都以本文這套核心鏈路為基礎。最后提醒一句這個案例的價值不在于“看起來智能”而在于“每句話都有出處”。做課程答疑系統時守住這一點你就已經比絕大多數只會調用 API 的問答工具靠譜了。建議收藏本文按第 5 節(jié)的代碼把項目跑通再逐步迭代成適合自己業(yè)務的知識庫問答系統。