簡介這份PDF文檔面向零售行業(yè)從業(yè)者、數字化轉型負責人及對DeepSeek應用感興趣的開發(fā)者聚焦如何以低成本方式構建商品知識引擎。內容從零售業(yè)現狀與改造需求切入系統講解DeepSeek的基本原理、神經網絡架構與訓練過程并深入剖析向量數據庫的向量表示、索引與相似度查詢機制對比Faiss、Milvus、Pinecone等常見方案的選型依據。文檔還完整覆蓋商品知識引擎的構建流程包括需求分析、數據采集與預處理、特征提取與向量轉換、數據庫配置及集成測試并配有Python代碼實踐涵蓋環(huán)境搭建、模擬商品數據、向量查詢與引擎類封裝。性能優(yōu)化部分則涉及模型壓縮、索引優(yōu)化、緩存機制與監(jiān)控調優(yōu)最后通過連鎖超市推薦、電商智能搜索等案例展示效果評估方法。資源包內含1個PDF文件大小約1.98MB共23頁目錄清晰、圖表完整已有58人學習。讀者可借此掌握從技術原理到代碼落地的完整路徑獲得可復用的低成本改造思路與實操參考。1. 零售商品知識引擎為什么用 DeepSeek 加向量數據庫而不是關鍵詞匹配一家社區(qū)連鎖超市的運營主管跟我吐槽過一件事門店有 8000 多個 SKU顧客問“有沒有適合糖尿病人吃的無糖餅干”店員只能憑記憶翻貨架翻不到就說沒有。后來他們試著在內部系統里加了個搜索框結果搜“無糖”出來一堆“無糖可樂”“無糖口香糖”真正想找的餅干排在第三頁。這不是搜索框的問題是關鍵詞匹配根本理解不了“適合糖尿病人”和“無糖”之間的語義關系。商品知識引擎要解決的就是這類問題。它把商品標題、規(guī)格、配料表、適用人群、促銷規(guī)則這些散落在 ERP、Excel、商品詳情頁里的信息統一轉成向量存進向量數據庫再用 DeepSeek 這類大模型做意圖理解和答案生成。顧客或店員用自然語言提問系統先檢索語義最接近的商品片段再讓模型組織成一句人話。整套方案不需要 GPU 集群一臺 8 核 16G 的云主機就能跑起來這正是“低成本改造”的含義。適合誰看零售 IT 負責人、門店數字化產品經理、想用大模型做垂直知識庫的后端工程師。如果你手里有商品數據但不知道怎么讓大模型“記住”它們這篇筆記就是按這個思路拆的。2. 商品知識引擎的骨架DeepSeek 負責什么向量數據庫負責什么2.1 為什么不是把商品表直接塞給大模型很多人第一反應是我把商品 Excel 轉成 JSON每次提問全量塞進 DeepSeek 的上下文不就行了8000 個 SKU每個商品平均 200 字描述全量就是 160 萬字。DeepSeek 的上下文窗口再大也扛不住每輪對話都灌這么多而且 token 成本會隨對話輪次線性上漲。更致命的是大模型對長上下文中間部分的信息召回率會下降商品一多它就開始“胡編”庫存和價格。正確做法是兩段式向量數據庫做粗篩把候選商品從 8000 個縮到 5 到 10 個DeepSeek 做精排和生成只處理這幾條候選。這樣每次請求的 token 量可控響應速度也能壓在 2 秒以內。2.2 向量數據庫選型Milvus、Chroma、Qdrant 在零售場景下的取舍熱搜里?？吹?milvus、chroma、qdrant 的對比我按零售商品知識引擎的實際需求列一下維度ChromaQdrantMilvus部署復雜度極低pip 裝完就能用低單二進制或 Docker中依賴 etcd/MinIO單機數據量10 萬級以下百萬級千萬級以上過濾檢索基礎元數據過濾強支持復雜 payload 過濾強支持分區(qū)標量過濾持久化本地文件或內存本地磁盤對象存儲適合場景原型驗證、小店中型連鎖、多門店大型商超集團我的建議如果你只是先跑通一個門店的商品知識引擎Chroma 足夠代碼量最少。如果計劃覆蓋幾十家門店、商品數據要按門店隔離直接上 Qdrant它的 payload 過濾能讓你用store_id字段做租戶隔離不用維護多套索引。Milvus 適合已經有數據平臺團隊、要接實時商品流的大集團單店改造沒必要上。2.3 商品數據向量化的最小流程向量化不是把商品標題丟給 embedding 模型就完事。零售商品有幾個特殊字段必須拼進文本商品名、規(guī)格、配料/材質、適用人群、禁忌、當前促銷。我一般按這個模板拼# 商品文本拼接模板字段順序影響語義權重 def build_product_text(item): parts [ f商品名稱{item[name]}, f規(guī)格{item[spec]}, f配料或材質{item.get(ingredients, 無)}, f適用人群{item.get(target_audience, 通用)}, f禁忌{item.get(taboo, 無)}, f當前促銷{item.get(promotion, 無)}, ] return \n.join(parts)邏輯說明把結構化字段轉成“字段名值”的格式embedding 模型對這類文本的語義區(qū)分度比純拼接高。參數說明ingredients和taboo用get兜底因為很多零售商品數據這兩個字段是空的直接取會報 KeyError。促銷字段一定要放進去否則顧客問“今天有什么優(yōu)惠”時向量檢索會漏掉促銷商品。提示embedding 模型建議選中文優(yōu)化過的比如 BGE 系列的中文模型。用通用多語言模型在中文商品名上的召回率會差 10 到 15 個百分點。3. 用 DeepSeek API 加 Qdrant 跑通商品問答的最小閉環(huán)3.1 環(huán)境準備與依賴安裝先確認 Python 版本在 3.9 以上然后裝這幾個包pip install qdrant-client openai sentence-transformers pandas這里用openai包是因為 DeepSeek 的 API 兼容 OpenAI 的調用格式不用額外裝 DeepSeek 專用 SDK。sentence-transformers用來本地跑 embedding 模型不依賴外部 embedding API省一筆調用費。3.2 商品數據入庫從 CSV 到 Qdrant 集合假設你有一份products.csv字段包括sku_id、name、spec、ingredients、target_audience、taboo、promotion、price。import pandas as pd from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct from sentence_transformers import SentenceTransformer # 初始化本地 Qdrant數據存在 ./qdrant_data client QdrantClient(path./qdrant_data) # 加載中文 embedding 模型 model SentenceTransformer(BAAI/bge-small-zh-v1.5) # 建集合向量維度 512 對應 bge-small-zh client.recreate_collection( collection_nameproduct_knowledge, vectors_configVectorParams(size512, distanceDistance.COSINE), ) df pd.read_csv(products.csv) def build_product_text(row): return \n.join([ f商品名稱{row[name]}, f規(guī)格{row[spec]}, f配料或材質{row.get(ingredients, 無)}, f適用人群{row.get(target_audience, 通用)}, f禁忌{row.get(taboo, 無)}, f當前促銷{row.get(promotion, 無)}, ]) points [] for idx, row in df.iterrows(): text build_product_text(row) vector model.encode(text).tolist() points.append(PointStruct( ididx, vectorvector, payload{ sku_id: row[sku_id], name: row[name], price: float(row[price]), promotion: row.get(promotion, ), } )) client.upsert(collection_nameproduct_knowledge, pointspoints) print(f入庫完成共 {len(points)} 條商品)邏輯說明recreate_collection每次運行會清空舊集合生產環(huán)境要換成create_collection加存在判斷。PointStruct的payload存的是原始字段檢索回來直接能用不用再查數據庫。參數說明size512必須和 embedding 模型輸出維度一致bge-small-zh-v1.5 是 512 維換成 bge-base-zh 就是 768 維建集合時寫錯會直接報維度不匹配。3.3 檢索加生成DeepSeek 提示詞怎么寫才不胡說檢索到候選商品后把候選商品和用戶問題一起交給 DeepSeek。提示詞的關鍵是約束模型“只根據候選商品回答”。from openai import OpenAI llm OpenAI( api_key你的DeepSeek API Key, base_urlhttps://api.deepseek.com ) def ask_product_question(question, top_k5): # 1. 問題向量化 q_vector model.encode(question).tolist() # 2. 向量檢索 hits client.search( collection_nameproduct_knowledge, query_vectorq_vector, limittop_k, ) # 3. 拼候選上下文 context_lines [] for h in hits: p h.payload context_lines.append( f商品{p[name]}價格{p[price]}元促銷{p[promotion]} ) context \n.join(context_lines) # 4. 調 DeepSeek 生成 resp llm.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: ( 你是零售門店的商品導購助手。只能根據下面提供的候選商品回答 不要編造候選列表之外的商品。如果候選商品無法回答用戶問題 直接說“當前沒有找到匹配商品”。 )}, {role: user, content: f候選商品\n{context}\n\n用戶問題{question}} ], temperature0.2, ) return resp.choices[0].message.content邏輯說明temperature0.2是為了讓輸出穩(wěn)定導購場景不需要創(chuàng)意。system prompt 里明確“只能根據候選商品回答”這是防止模型拿訓練數據里的通用商品知識來編。參數說明top_k5是經驗值太少容易漏太多會引入不相關商品干擾模型判斷。如果商品描述很長可以調到 8但要注意 token 消耗。注意DeepSeek API 的base_url是https://api.deepseek.com不要寫成帶/v1的地址否則會 404。模型名用deepseek-chat不要用deepseek-reasoner導購場景不需要推理鏈用 reasoner 反而慢且貴。4. 避坑與排查商品知識引擎上線前必須處理的 5 個問題4.1 現象搜“無糖餅干”返回“無糖可樂”排序靠前原因embedding 模型對“餅干”和“可樂”的品類區(qū)分度不夠因為兩者在“無糖”這個維度上語義很近。解決在 payload 里加一個category字段檢索時用 Qdrant 的filter做品類硬過濾。比如用戶問題里識別到“餅干”就只搜category餅干的子集。識別品類可以用一個簡單的關鍵詞映射表不用上模型。4.2 現象促銷商品搜不出來明明今天在打折原因促銷字段是每天變的但向量是入庫時算的促銷信息變了向量沒變。解決促銷信息不要只放在向量文本里要同時放在 payload 里檢索后由 DeepSeek 根據 payload 里的實時促銷字段來回答。向量文本里的促銷只作為語義補充不作為事實來源。4.3 現象DeepSeek 回答里出現候選列表里沒有的商品原因system prompt 約束不夠強或者候選商品太少導致模型“自由發(fā)揮”。解決在 system prompt 里加一句“如果候選商品為空必須回答‘沒有找到’”。另外把top_k從 5 調到 8給模型更多候選減少它編造的動機。4.4 現象Qdrant 本地模式跑一段時間后檢索變慢原因path./qdrant_data的本地模式在數據量超過 5 萬條后每次檢索都要加載索引文件。解決數據量超過 5 萬就換成 Docker 跑 Qdrant 服務用QdrantClient(hostlocalhost, port6333)連接。本地模式只適合原型驗證。4.5 現象商品名里有生僻字embedding 后檢索不到原因部分 embedding 模型對生僻字會映射到 unknown token。解決在文本拼接時把生僻字商品名同時保留拼音字段比如“藜麥”拼成“l(fā)i mai”一起放進向量文本。這樣用戶搜“l(fā)imai”也能命中。5. 讓商品知識引擎越用越準兩個進階技巧和驗證方法5.1 用查詢日志做檢索效果回歸上線后把用戶問題和檢索到的 top_k 商品存一張日志表每周抽 50 條人工標注“檢索結果是否相關”。如果相關率低于 80%說明 embedding 模型或文本模板需要調。我一般會先調文本模板把用戶高頻問到的字段往前排比如顧客常問“適合什么人吃”就把target_audience放到商品名后面第二位。5.2 混合檢索向量加關鍵詞雙路召回純向量檢索在商品編碼、品牌名這類精確匹配上會翻車。比如顧客問“有沒有 6901234567890 這個條碼的商品”向量檢索基本召回不了。解決辦法是加一路關鍵詞檢索用 Qdrant 的scroll接口做 payload 精確匹配兩路結果合并去重后再交給 DeepSeek。代碼上就是在ask_product_question里加一個條碼正則判斷命中條碼就直接走精確查詢不走向量。5.3 驗證方法用 20 個真實顧客問題做冒煙測試上線前準備 20 個真實問題覆蓋品類查詢、成分查詢、促銷查詢、禁忌查詢四類。跑一遍看回答準確率。我自己的標準是20 個里至少 17 個回答正確且沒有編造。低于這個數就不要上線回去查是檢索漏了還是提示詞沒約束住。最后說個血淚經驗商品知識引擎最怕的不是技術選型是商品數據本身臟。配料表里寫“等”字、適用人群寫“詳見包裝”、促銷字段寫“以門店為準”這些臟數據進向量庫后DeepSeek 再強也救不回來。我現在的習慣是入庫前先跑一遍數據質量檢查空字段率超過 30% 的列直接不放進向量文本寧可少一個維度也不要讓模型學到垃圾。希望幫到你。本文還有配套的精品資源點擊獲取 零售商品知識引擎：DeepSeek 加向量數據庫實現低成本語義搜索
簡介這份PDF文檔面向零售行業(yè)從業(yè)者、數字化轉型負責人及對DeepSeek應用感興趣的開發(fā)者聚焦如何以低成本方式構建商品知識引擎。內容從零售業(yè)現狀與改造需求切入系統講解DeepSeek的基本原理、神經網絡架構與訓練過程并深入剖析向量數據庫的向量表示、索引與相似度查詢機制對比Faiss、Milvus、Pinecone等常見方案的選型依據。文檔還完整覆蓋商品知識引擎的構建流程包括需求分析、數據采集與預處理、特征提取與向量轉換、數據庫配置及集成測試并配有Python代碼實踐涵蓋環(huán)境搭建、模擬商品數據、向量查詢與引擎類封裝。性能優(yōu)化部分則涉及模型壓縮、索引優(yōu)化、緩存機制與監(jiān)控調優(yōu)最后通過連鎖超市推薦、電商智能搜索等案例展示效果評估方法。資源包內含1個PDF文件大小約1.98MB共23頁目錄清晰、圖表完整已有58人學習。讀者可借此掌握從技術原理到代碼落地的完整路徑獲得可復用的低成本改造思路與實操參考。1. 零售商品知識引擎為什么用 DeepSeek 加向量數據庫而不是關鍵詞匹配一家社區(qū)連鎖超市的運營主管跟我吐槽過一件事門店有 8000 多個 SKU顧客問“有沒有適合糖尿病人吃的無糖餅干”店員只能憑記憶翻貨架翻不到就說沒有。后來他們試著在內部系統里加了個搜索框結果搜“無糖”出來一堆“無糖可樂”“無糖口香糖”真正想找的餅干排在第三頁。這不是搜索框的問題是關鍵詞匹配根本理解不了“適合糖尿病人”和“無糖”之間的語義關系。商品知識引擎要解決的就是這類問題。它把商品標題、規(guī)格、配料表、適用人群、促銷規(guī)則這些散落在 ERP、Excel、商品詳情頁里的信息統一轉成向量存進向量數據庫再用 DeepSeek 這類大模型做意圖理解和答案生成。顧客或店員用自然語言提問系統先檢索語義最接近的商品片段再讓模型組織成一句人話。整套方案不需要 GPU 集群一臺 8 核 16G 的云主機就能跑起來這正是“低成本改造”的含義。適合誰看零售 IT 負責人、門店數字化產品經理、想用大模型做垂直知識庫的后端工程師。如果你手里有商品數據但不知道怎么讓大模型“記住”它們這篇筆記就是按這個思路拆的。2. 商品知識引擎的骨架DeepSeek 負責什么向量數據庫負責什么2.1 為什么不是把商品表直接塞給大模型很多人第一反應是我把商品 Excel 轉成 JSON每次提問全量塞進 DeepSeek 的上下文不就行了8000 個 SKU每個商品平均 200 字描述全量就是 160 萬字。DeepSeek 的上下文窗口再大也扛不住每輪對話都灌這么多而且 token 成本會隨對話輪次線性上漲。更致命的是大模型對長上下文中間部分的信息召回率會下降商品一多它就開始“胡編”庫存和價格。正確做法是兩段式向量數據庫做粗篩把候選商品從 8000 個縮到 5 到 10 個DeepSeek 做精排和生成只處理這幾條候選。這樣每次請求的 token 量可控響應速度也能壓在 2 秒以內。2.2 向量數據庫選型Milvus、Chroma、Qdrant 在零售場景下的取舍熱搜里?？吹?milvus、chroma、qdrant 的對比我按零售商品知識引擎的實際需求列一下維度ChromaQdrantMilvus部署復雜度極低pip 裝完就能用低單二進制或 Docker中依賴 etcd/MinIO單機數據量10 萬級以下百萬級千萬級以上過濾檢索基礎元數據過濾強支持復雜 payload 過濾強支持分區(qū)標量過濾持久化本地文件或內存本地磁盤對象存儲適合場景原型驗證、小店中型連鎖、多門店大型商超集團我的建議如果你只是先跑通一個門店的商品知識引擎Chroma 足夠代碼量最少。如果計劃覆蓋幾十家門店、商品數據要按門店隔離直接上 Qdrant它的 payload 過濾能讓你用store_id字段做租戶隔離不用維護多套索引。Milvus 適合已經有數據平臺團隊、要接實時商品流的大集團單店改造沒必要上。2.3 商品數據向量化的最小流程向量化不是把商品標題丟給 embedding 模型就完事。零售商品有幾個特殊字段必須拼進文本商品名、規(guī)格、配料/材質、適用人群、禁忌、當前促銷。我一般按這個模板拼# 商品文本拼接模板字段順序影響語義權重 def build_product_text(item): parts [ f商品名稱{item[name]}, f規(guī)格{item[spec]}, f配料或材質{item.get(ingredients, 無)}, f適用人群{item.get(target_audience, 通用)}, f禁忌{item.get(taboo, 無)}, f當前促銷{item.get(promotion, 無)}, ] return \n.join(parts)邏輯說明把結構化字段轉成“字段名值”的格式embedding 模型對這類文本的語義區(qū)分度比純拼接高。參數說明ingredients和taboo用get兜底因為很多零售商品數據這兩個字段是空的直接取會報 KeyError。促銷字段一定要放進去否則顧客問“今天有什么優(yōu)惠”時向量檢索會漏掉促銷商品。提示embedding 模型建議選中文優(yōu)化過的比如 BGE 系列的中文模型。用通用多語言模型在中文商品名上的召回率會差 10 到 15 個百分點。3. 用 DeepSeek API 加 Qdrant 跑通商品問答的最小閉環(huán)3.1 環(huán)境準備與依賴安裝先確認 Python 版本在 3.9 以上然后裝這幾個包pip install qdrant-client openai sentence-transformers pandas這里用openai包是因為 DeepSeek 的 API 兼容 OpenAI 的調用格式不用額外裝 DeepSeek 專用 SDK。sentence-transformers用來本地跑 embedding 模型不依賴外部 embedding API省一筆調用費。3.2 商品數據入庫從 CSV 到 Qdrant 集合假設你有一份products.csv字段包括sku_id、name、spec、ingredients、target_audience、taboo、promotion、price。import pandas as pd from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct from sentence_transformers import SentenceTransformer # 初始化本地 Qdrant數據存在 ./qdrant_data client QdrantClient(path./qdrant_data) # 加載中文 embedding 模型 model SentenceTransformer(BAAI/bge-small-zh-v1.5) # 建集合向量維度 512 對應 bge-small-zh client.recreate_collection( collection_nameproduct_knowledge, vectors_configVectorParams(size512, distanceDistance.COSINE), ) df pd.read_csv(products.csv) def build_product_text(row): return \n.join([ f商品名稱{row[name]}, f規(guī)格{row[spec]}, f配料或材質{row.get(ingredients, 無)}, f適用人群{row.get(target_audience, 通用)}, f禁忌{row.get(taboo, 無)}, f當前促銷{row.get(promotion, 無)}, ]) points [] for idx, row in df.iterrows(): text build_product_text(row) vector model.encode(text).tolist() points.append(PointStruct( ididx, vectorvector, payload{ sku_id: row[sku_id], name: row[name], price: float(row[price]), promotion: row.get(promotion, ), } )) client.upsert(collection_nameproduct_knowledge, pointspoints) print(f入庫完成共 {len(points)} 條商品)邏輯說明recreate_collection每次運行會清空舊集合生產環(huán)境要換成create_collection加存在判斷。PointStruct的payload存的是原始字段檢索回來直接能用不用再查數據庫。參數說明size512必須和 embedding 模型輸出維度一致bge-small-zh-v1.5 是 512 維換成 bge-base-zh 就是 768 維建集合時寫錯會直接報維度不匹配。3.3 檢索加生成DeepSeek 提示詞怎么寫才不胡說檢索到候選商品后把候選商品和用戶問題一起交給 DeepSeek。提示詞的關鍵是約束模型“只根據候選商品回答”。from openai import OpenAI llm OpenAI( api_key你的DeepSeek API Key, base_urlhttps://api.deepseek.com ) def ask_product_question(question, top_k5): # 1. 問題向量化 q_vector model.encode(question).tolist() # 2. 向量檢索 hits client.search( collection_nameproduct_knowledge, query_vectorq_vector, limittop_k, ) # 3. 拼候選上下文 context_lines [] for h in hits: p h.payload context_lines.append( f商品{p[name]}價格{p[price]}元促銷{p[promotion]} ) context \n.join(context_lines) # 4. 調 DeepSeek 生成 resp llm.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: ( 你是零售門店的商品導購助手。只能根據下面提供的候選商品回答 不要編造候選列表之外的商品。如果候選商品無法回答用戶問題 直接說“當前沒有找到匹配商品”。 )}, {role: user, content: f候選商品\n{context}\n\n用戶問題{question}} ], temperature0.2, ) return resp.choices[0].message.content邏輯說明temperature0.2是為了讓輸出穩(wěn)定導購場景不需要創(chuàng)意。system prompt 里明確“只能根據候選商品回答”這是防止模型拿訓練數據里的通用商品知識來編。參數說明top_k5是經驗值太少容易漏太多會引入不相關商品干擾模型判斷。如果商品描述很長可以調到 8但要注意 token 消耗。注意DeepSeek API 的base_url是https://api.deepseek.com不要寫成帶/v1的地址否則會 404。模型名用deepseek-chat不要用deepseek-reasoner導購場景不需要推理鏈用 reasoner 反而慢且貴。4. 避坑與排查商品知識引擎上線前必須處理的 5 個問題4.1 現象搜“無糖餅干”返回“無糖可樂”排序靠前原因embedding 模型對“餅干”和“可樂”的品類區(qū)分度不夠因為兩者在“無糖”這個維度上語義很近。解決在 payload 里加一個category字段檢索時用 Qdrant 的filter做品類硬過濾。比如用戶問題里識別到“餅干”就只搜category餅干的子集。識別品類可以用一個簡單的關鍵詞映射表不用上模型。4.2 現象促銷商品搜不出來明明今天在打折原因促銷字段是每天變的但向量是入庫時算的促銷信息變了向量沒變。解決促銷信息不要只放在向量文本里要同時放在 payload 里檢索后由 DeepSeek 根據 payload 里的實時促銷字段來回答。向量文本里的促銷只作為語義補充不作為事實來源。4.3 現象DeepSeek 回答里出現候選列表里沒有的商品原因system prompt 約束不夠強或者候選商品太少導致模型“自由發(fā)揮”。解決在 system prompt 里加一句“如果候選商品為空必須回答‘沒有找到’”。另外把top_k從 5 調到 8給模型更多候選減少它編造的動機。4.4 現象Qdrant 本地模式跑一段時間后檢索變慢原因path./qdrant_data的本地模式在數據量超過 5 萬條后每次檢索都要加載索引文件。解決數據量超過 5 萬就換成 Docker 跑 Qdrant 服務用QdrantClient(hostlocalhost, port6333)連接。本地模式只適合原型驗證。4.5 現象商品名里有生僻字embedding 后檢索不到原因部分 embedding 模型對生僻字會映射到 unknown token。解決在文本拼接時把生僻字商品名同時保留拼音字段比如“藜麥”拼成“l(fā)i mai”一起放進向量文本。這樣用戶搜“l(fā)imai”也能命中。5. 讓商品知識引擎越用越準兩個進階技巧和驗證方法5.1 用查詢日志做檢索效果回歸上線后把用戶問題和檢索到的 top_k 商品存一張日志表每周抽 50 條人工標注“檢索結果是否相關”。如果相關率低于 80%說明 embedding 模型或文本模板需要調。我一般會先調文本模板把用戶高頻問到的字段往前排比如顧客常問“適合什么人吃”就把target_audience放到商品名后面第二位。5.2 混合檢索向量加關鍵詞雙路召回純向量檢索在商品編碼、品牌名這類精確匹配上會翻車。比如顧客問“有沒有 6901234567890 這個條碼的商品”向量檢索基本召回不了。解決辦法是加一路關鍵詞檢索用 Qdrant 的scroll接口做 payload 精確匹配兩路結果合并去重后再交給 DeepSeek。代碼上就是在ask_product_question里加一個條碼正則判斷命中條碼就直接走精確查詢不走向量。5.3 驗證方法用 20 個真實顧客問題做冒煙測試上線前準備 20 個真實問題覆蓋品類查詢、成分查詢、促銷查詢、禁忌查詢四類。跑一遍看回答準確率。我自己的標準是20 個里至少 17 個回答正確且沒有編造。低于這個數就不要上線回去查是檢索漏了還是提示詞沒約束住。最后說個血淚經驗商品知識引擎最怕的不是技術選型是商品數據本身臟。配料表里寫“等”字、適用人群寫“詳見包裝”、促銷字段寫“以門店為準”這些臟數據進向量庫后DeepSeek 再強也救不回來。我現在的習慣是入庫前先跑一遍數據質量檢查空字段率超過 30% 的列直接不放進向量文本寧可少一個維度也不要讓模型學到垃圾。希望幫到你。本文還有配套的精品資源點擊獲取