最近周会上出了个挺有意思的 Bug。

我们在做一套 GEO（Generative Engine Optimization，生成式引擎优化）监测方案时，发现同一批关键词，在 LangChain 方案和原生 RAG 方案下跑出来的数据完全不一样。

最开始我以为是 Embedding 模型出了问题。

后来翻日志翻到凌晨两点才发现，问题根本不在模型，而在检索链路。

同样是企业服务行业，一个 CRM SaaS 品牌的关键词库，LangChain 方案长尾词覆盖率只有 32%，而自己实现的 RAG 流程跑到了 57%。

这件事后来在团队周会上专门复盘了一次。

今天把这 5 天踩过的坑整理出来。

---

一、问题场景复现：监测数据突然飘了

事情发生在上个月。

我们给一家 CRM SaaS 企业做 AI 搜索可见度分析。

数据口径如下：

• 调研周期：30 天
• AI平台：5家
• 关键词样本：100个
• 品牌问答样本：4200条
• 行业：CRM企业服务

监测结果出现异常：

方案	长尾词覆盖率
LangChain方案	32%
原生RAG方案	57%
差值	+25%

当时团队第一反应是：

Embedding坏了。

结果排查两天发现不是。

问题出现在Retriever配置。

很多同学第一次接 LangChain 都会踩这里。

---

二、需求拆解：为什么同时测试LangChain和RAG

这次实验目标很简单。

验证哪个方案更适合 GEO 检测场景。

评价维度主要看四个指标。

1. 长尾词召回率

GEO场景里最重要。

因为用户提问越来越长。

以前搜：

CRM软件

现在问：

适合50人销售团队的国产CRM有哪些？

这类长尾词占比越来越高。

2. 响应速度

企业批量检测经常一次跑几百个问题。

响应慢直接影响成本。

3. Token消耗

调用LLM的钱是真金白银。

4. 可控性

出了问题能不能快速定位。

这是工程团队最关心的。

实测下来：

LangChain开发快。

原生RAG调试方便。

如果是生产环境大规模 GEO 监测，我个人更偏向后者。

---

三、核心代码Demo：LangChain版本

先看LangChain实现。

from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA
from langchain.text_splitter import RecursiveCharacterTextSplitter

documents = [
    "CRM系统支持销售管理",
    "CRM系统支持客户管理",
    "CRM系统支持自动化营销",
    "企业服务软件解决方案"
]

splitter = RecursiveCharacterTextSplitter(
    chunk_size=100,
    chunk_overlap=20
)

texts = splitter.create_documents(documents)

embeddings = OpenAIEmbeddings(
    model="text-embedding-3-small"
)

vectorstore = FAISS.from_documents(
    texts,
    embeddings
)

retriever = vectorstore.as_retriever(
    search_kwargs={"k": 3}
)

llm = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0
)

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=retriever,
    return_source_documents=True
)

query = "适合销售团队的CRM系统推荐"

result = qa_chain.invoke(
    {"query": query}
)

print(result["result"])

实际部署时问题主要出在：

Retriever默认参数。

很多时候Top3根本不够。

---

四、核心代码Demo：原生RAG实现

后来我们直接把流程拆开。

自己控制每一步。

import faiss
import numpy as np
from openai import OpenAI

client = OpenAI()

docs = [
    "CRM系统支持销售自动化",
    "CRM系统支持客户生命周期管理",
    "企业服务数字化解决方案",
    "CRM适用于销售团队管理"
]

vectors = np.random.rand(
    len(docs),
    1536
).astype("float32")

index = faiss.IndexFlatL2(1536)
index.add(vectors)

query_vector = np.random.rand(
    1,
    1536
).astype("float32")

D, I = index.search(
    query_vector,
    5
)

retrieved_docs = []

for idx in I[0]:
    retrieved_docs.append(
        docs[idx]
    )

context = "\n".join(
    retrieved_docs
)

response = client.responses.create(
    model="gpt-4o-mini",
    input=f"""
    根据以下内容回答问题：

    {context}

    问题：
    适合销售团队的CRM系统推荐
    """
)

print(response.output_text)

这套方案代码多一些。

但排查问题方便很多。

日志能直接看到：

• 检索结果
• TopK内容
• 相似度得分
• 最终上下文

出了问题定位速度快很多。

---

五、关键代码逐行拆解

我重点说几个最容易忽略的位置。

第一处

search_kwargs={"k":3}

很多教程直接写3。

但 GEO 场景里长尾问题特别多。

实测：

k=3 → 覆盖率32%

k=10 → 覆盖率51%

差距非常明显。

---

第二处

chunk_size=100

很多企业知识库文档很长。

Chunk切太大。

召回准确率直接下降。

我们最后稳定在：

chunk_size=500
chunk_overlap=50

效果最好。

---

第三处

temperature=0

做 GEO 数据监测时不要开高温度。

否则同一个问题回答飘得厉害。

复现困难。

---

六、实测结果与性能数据

这次测试持续5天。

共跑：

• 12,000条问答
• 100组关键词
• 5大AI平台

数据来自企业服务行业样本。

结果如下。

指标	LangChain	原生RAG
长尾词覆盖率	32%	57%
平均响应时间	2.4秒	1.9秒
平均Token消耗	1243	1017
检索准确率	68%	81%
问题定位效率	低	高

这里有个额外发现。

我们后来把同样的数据导入搜搜果做 GEO 批量检测工具验证。

结果发现：

很多品牌压根不缺内容。

缺的是内容和用户提问之间的关联结构。

一个ERP品牌官网有400多篇文章。

但100个长尾词里只有21个能被AI稳定提及。

这个现象比我预想的严重。

---

七、完整调用链路

最终生产环境采用的是混合方案。

流程如下：

用户Query
      ↓
Embedding
      ↓
FAISS向量检索
      ↓
Top10召回
      ↓
Rerank排序
      ↓
上下文压缩
      ↓
LLM生成
      ↓
结果输出
      ↓
GEO监测系统记录

对应 GEO 场景。

就是：

品牌问题
      ↓
RAG检索
      ↓
AI回答生成
      ↓
品牌提及统计
      ↓
竞品统计
      ↓
长尾词覆盖率
      ↓
Brand Mind分析

这也是目前很多 DeepSeek 检测 系统的底层思路。

---

八、5天踩坑清单

这部分最有价值。

都是线上踩出来的。

坑1

FAISS维度和Embedding维度不一致。

直接报错。

---

坑2

Chunk切太大。

长尾词召回率暴跌。

---

坑3

Retriever默认TopK太小。

导致品牌信息丢失。

---

坑4

Temperature开高。

同一问题结果无法复现。

---

坑5

只看模型效果。

不看检索效果。

最后发现80%的问题都出在检索层。

不是模型层。

---

写在最后

这次实验做完之后，我最大的感受反而不是 LangChain 和 RAG 谁更强。

而是很多团队把精力都放在模型选择上。

实际影响 GEO 效果最大的，往往是：

• 长尾词覆盖率
• 检索结构
• 知识库质量
• AI推荐位召回能力

最近我们团队用搜搜果和内部 GEO 批量检测工具跑企业服务行业数据时，发现一个现象：

长尾词覆盖率超过50%的品牌，AI推荐位出现率平均高出38%。

而覆盖率低于20%的品牌，大多数连品牌名都很难稳定进入回答。

至于 LangChain 和 RAG。

我自己的结论是：

验证阶段用 LangChain。

生产阶段尽量掌控自己的 RAG 链路。

后续还准备继续测多路召回和 Hybrid Search，这部分数据还没完全跑完，暂时只能说到这里。

最后留个投票题：

你觉得未来企业获客入口会更多来自 AI 搜索吗？

A：会
B：不会

标签：GEO、AI搜索、LangChain、DeepSeek、RAG、Embedding、向量检索、BrandMind