LLM TREND

大模型技术趋势分享：LLM、RAG、Prompt、Agent、Fine-tuning等

RAG

抛弃RAG，打造高效“哑瓜”AI问答机器人：无需向量数据库，用简单策略解决复杂问题

By llmtrend #RAG

还在为搭建AI问答机器人而苦恼于RAG（检索增强生成）、向量数据库、LangChain等复杂技术吗？本文将带你打破迷思，揭示构建一个实用、高效、且无需繁琐技术栈的“哑瓜”AI问答机器人的秘诀。我们将深入探讨如何在没有RAG的情况下，仅利用简单逻辑和小数据集，打造一个能智能回答问题的AI助手。无需向量数据库、无需复杂的chunking策略，让你在30分钟内拥有一个真正能解决实际问题的AI应用。

一、AI FOMO与过度复杂化的陷阱：重新审视问答机器人的本质

AI技术日新月异，许多人急于“用AI做点什么”，避免自己的简历显得落伍。于是，他们开始研究聊天机器人的构建，却立刻被RAG、向量数据库、LangChain、Pinecone等术语淹没。原本简单的问答机器人想法，瞬间变成了一项艰深的prompt工程研究。

然而，事实并非如此。对于基础的问答机器人，特别是那些旨在回答关于文档、产品或博客文章的问题的应用场景，很多复杂的RAG技术并非必需。现代AI教程中的许多复杂性，是为了解决你可能根本不会遇到的边缘案例。举例来说，如果你只是想创建一个针对公司FAQ的问答机器人，可能根本不需要动态检索或复杂的语义理解，一个基于关键词匹配的方法就能很好地工作。

二、RAG的迷思与替代方案：为什么“简单”才是王道

RAG听起来像是钢铁侠用来升级贾维斯的黑科技，但实际上，它本质上是一种让LLM（大型语言模型）“相信外部信息”的方式，即“嘿，LLM，我不信任你的记忆，这里有一些信息，用这些代替”。RAG在处理海量、分散或不断变化的数据时非常强大。但是，开发者常常陷入一个陷阱：

互联网告诉你，构建一个简单的问答机器人需要：向量数据库、chunking策略、混合检索器、OpenAI API、Hugging Face transformers，以及将它们粘合在一起的LangChain代码。这就像只想烤面包，却被告知要建一家面包店。

RAG假设：你的数据足够大，以至于关键词搜索失败；你的用例需要动态上下文注入；你有时间和金钱和基础设施来管理多个组件。但是，大多数早期项目并不需要这些。你可能只是在回答有限的问题（常见问题解答、文档等），处理干净、结构化的内容，而不是试图构建下一个Perplexity.ai克隆。在这种情况下，添加RAG只会增加维护负担、成本和混乱。这就像软件开发中的过早优化，而且往往不会提高质量。

举例说明，一个小型律师事务所想创建一个问答机器人，方便员工快速查找法律条款。他们的数据量不大，法律条款也相对稳定。如果采用RAG，需要搭建向量数据库，对法律条款进行chunking和embedding，并定期更新。然而，采用关键词匹配的方法，只需要建立一个简单的关键词与法律条款的对应表，就能满足需求，大大降低了开发和维护成本。

三、构建问答机器人的核心要素：精简才是关键

在充斥着RAG教程的互联网世界里，很少有人告诉你真正需要什么：

你不需要：像Pinecone或Weaviate这样的向量数据库，LangChain、LlamaIndex或任何编排库，chunking策略、元数据过滤器或reranking管道。

你只需要：问题及其答案的列表（真的！），将这些答案转化为embeddings（表示含义的向量）的方法，用户查询和存储问题之间的相似性检查，以及一个能够用最佳匹配响应的大型语言模型（LLM）。

以下是构建流程：

步骤1：构建知识库

硬编码20-50个关于你的产品、服务或文档的常见问答。每个问答存储为一个文本对：问题 → 答案。更进一步，可以只存储答案，让LLM找出哪个答案最接近用户的查询。

步骤2：Embed答案

使用任何embedding模型（例如OpenAI的text-embedding-3-small或Hugging Face的all-MiniLM-L6-v2）。这将把你的答案变成向量。请注意，你只需要embedding一次，并缓存它们。

步骤3：比较查询

当用户提问时，也要embedding他们的查询。然后使用余弦相似度（一种衡量两个向量相似程度的数学方法）将其与所有存储的向量进行比较。最接近的答案就是你的回复。

步骤4：将其发送到LLM（如果需要）

你可以直接返回原始答案，也可以通过LLM传递，并附带一条简单的指令，例如：“这是我找到的最接近的答案。用自然的语言为用户重述它。” 这为你提供了ChatGPT的润色，而无需让它思考太多。

这并不是魔法。它是数学。它速度很快。而且对于小型、静态数据集，它的效果比预期的要好得多。例如，一个小型电商网站，他们只有几十个关于退货政策、支付方式和运输的常见问题。使用上述方法，他们能够快速创建一个问答机器人，帮助用户快速找到答案，减少客户支持的压力。

四、“哑瓜”AI的优势：可靠性与可控性

大多数AI agent不需要思考，它们只需要检索。这就是我们的“哑瓜”问答agent的闪光点。它不会产生幻觉，不会链接思维，也不会试图解决你的人生问题。它只是一个“查找最接近的答案”的函数，而这就是它的超能力。

其工作原理如下：

  1. 初始化：你有一个已知答案的小列表。把它想象成一个迷你FAQ列表。
  2. 一次性Embed所有内容：使用你最喜欢的embedding模型将所有答案转换为向量，并将它们存储在内存或简单文件中。
  3. 用户查询传入：用户输入：“如何重置我的密码？” → 也对这个进行Embed。
  4. 使用余弦相似度进行比较：遍历所有存储的向量，并选择相似度得分最高的向量。
  5. 返回或重述：只需返回该答案。或者选择性地运行一个prompt，例如：“使用此答案回复用户，但使其听起来人性化且有帮助。”

这种方法之所以有效，是因为：

  • 你的知识是固定的和明确的（没有模糊的互联网垃圾）
  • 用户没有试图问哲学问题
  • 它速度很快，毫秒级的
  • 它很便宜，没有数据库成本，没有API流媒体废话
  • 它是可调试的，你知道底层发生了什么
  • 它不模拟认知，而这正是重点。你不需要一个有知觉的预言机。你需要一个不会编造东西的可靠助手。

想想Stack Overflow搜索结果。但它是自动的。而且很有礼貌。

五、代码实现：手把手构建你的“哑瓜”问答机器人

现在，让我们将理论转化为代码。我们将使用不到100行的代码构建这个完整的问答agent，使用：

  • 一个基本的embedding模型（OpenAI或Hugging Face）
  • 用于我们的问答对的纯JSON
  • 用于对答案进行排序的余弦相似度
  • 一个简单的LLM调用（可选）来清理响应

步骤1：你的知识库

假设你有一组像这样存储的答案：

[
  {
    "id": 1,
    "question": "如何重置我的密码？",
    "answer": "要重置你的密码，请点击登录屏幕上的“忘记密码”。"
  },
  {
    "id": 2,
    "question": "如何联系客服？",
    "answer": "你可以通过support@example.com向我们的支持团队发送电子邮件。"
  }
]

将其保存为faq.json。

步骤2：Embed你的答案

为了简单起见，我们将在此处使用OpenAI，但你可以使用任何embedding模型：

import openai
import json

def embed_text(text):
    response = openai.Embedding.create(
        model="text-embedding-3-small",
        input=text
    )
    return response["data"][0]["embedding"]

# 加载并Embed所有答案
with open("faq.json") as f:
    faqs = json.load(f)

for faq in faqs:
    faq["embedding"] = embed_text(faq["answer"])

# 如果你不想每次都消耗token，请在本地缓存这些embeddings。

步骤3：余弦相似度

比较向量：

import numpy as np

def cosine_similarity(vec1, vec2):
    v1, v2 = np.array(vec1), np.array(vec2)
    return np.dot(v1, v2) / (np.linalg.norm(v1) * np.linalg.norm(v2))

步骤4：匹配最佳答案

以下是我们如何选择最接近的答案：

def find_best_answer(user_query, faqs):
    query_embedding = embed_text(user_query)
    ranked = sorted(
        faqs,
        key=lambda faq: cosine_similarity(query_embedding, faq["embedding"]),
        reverse=True
    )
    return ranked[0]["answer"]

步骤5（可选）：使用LLM重述

如果你想要“ChatGPT润色”，请让模型清理它：

def rephrase_answer(user_query, raw_answer):
    prompt = f"用户提问：{user_query}\n请使用以下信息礼貌地回答：\n{raw_answer}"
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    )
    return response["choices"][0]["message"]["content"]

全部放在一起

user_input = input("问点什么：")
raw_answer = find_best_answer(user_input, faqs)
final_answer = rephrase_answer(user_input, raw_answer)
print(final_answer)

完成。你刚刚构建了一个可以处理真实用户提出的真实问题的问答agent。没有pipeline。没有编排。没有RAG兔子洞。只需几个步骤，你就上线了。

六、“哑瓜”AI的适用场景与局限性

让我们坦诚地说：你刚刚构建的这个小“哑瓜”agent的能力超出了它的级别。但与所有粗放的MVP一样，它具有优势和非常真实的弱点。

它的优点

  • 小型、干净的知识库：当你的数据是有限的、可靠的并且不会每小时都更改时，此agent就会发光。想想常见问题解答、产品手册、内部SOP、入职文档等。
  • 快速响应：没有外部数据库调用。没有链条。只是内存匹配。整个往返行程（包括重述）不到一秒。
  • 低成本：Embeddings很便宜。使用GPT重述只需几美分。你可以跳过昂贵的向量数据库、agent和消耗token的上下文填充。
  • 易于调试：你可以检查embedding分数。你可以打印每个匹配项。你永远不会怀疑“它为什么要这么说？”
  • 即插即用堆栈：想要将OpenAI换成Hugging Face？没问题。想要用CSV甚至Notion API替换JSON？去吧。它很灵活。

它的缺点（以及何时切换）

  • 语义模糊性：提出与参考措辞截然不同的问题，你可能会得到奇怪的匹配。Embeddings有所帮助，但它们不是读心术者。
  • 不断增长的数据集：有数千个文档？在某个时候，线性相似度搜索会变慢，你需要批量处理、修剪或升级到真正的检索器。
  • 变化的数据：静态embeddings = 过时的答案。如果你的知识库每天更新，你需要一个后台作业来重新embedding和刷新。
  • 推理和链接：此agent不推理。它不“思考”。如果你的用户想要一个3步教程或想要提出后续问题…是时候重新考虑架构了。
  • 幻觉过滤器：这不是RAG。你没有将上下文注入到LLM prompt中。因此，它不擅长即时事实合成。它更像是“最佳匹配”自动完成。

那么它是否有限制？当然。但对于80%的常见问题，它是否也出奇地有效？是的。

七、何时升级到RAG？

最终，你可爱的100行问答agent可能会开始呻吟。也许你的数据集爆炸了。也许用户提出了奇怪的、切题的问题。也许你团队中的某人会低声说，“我们…应该使用LangChain吗？”

在你恐慌并重建一切之前，先问自己三个棘手的问题：

  1. 你的数据是否庞大或混乱？

    • 如果你的知识库：
      • 有1000+个文档
      • 包含长的PDF或markdown文件
      • 需要段落级别的搜索
    • → 你将受益于对段落进行chunk、embedding和动态搜索的检索系统。
    • 这就是RAG真正闪耀的地方：在非结构化混乱的海洋中实现精确。

  2. 你的内容是否频繁更改？

    • 如果你的数据每天或每小时更新（例如支持工单、变更日志、维基百科），你需要：
      • 随时重新embedding
      • 将embeddings存储在持久性位置
      • 使所有内容保持同步
    • 在这种情况下，轻量级RAG设置（带有像Weaviate或Qdrant这样的向量数据库）是有意义的。否则，你只是在提供过时的信息。

  3. 你的bot是否需要思考，而不仅仅是匹配？

    • 如果你希望你的agent：
      • 链接逻辑步骤（例如，总结 + 比较 + 解释）
      • 处理后续问题（上下文聊天）
      • 从多个文档中综合答案
    • 那么…你的“哑瓜”agent可能会退出。
    • 这就是你需要：
      • 用于相关上下文的检索
      • Prompt填充或多轮记忆
      • 可能具有Agent推理能力

但如果你的用户只是想从已知数据集中获得快速、真实的信息？坚持使用“哑瓜”路径。它更快。更便宜。更可靠。老实说，它通常已经足够好。（只是不要告诉LinkedIn上的RAG思想领袖。）

八、结论：构建能工作的“无聊”产品

让我们面对现实：并非每个AI项目都需要成为prompt架构方面的博士论文。有时，你只需要：

  • 一组已知的答案
  • 一些基本的向量数学
  • 少量LLM润色

仅此而已。

你不需要“对所有事物进行RAG”。你不需要一个包含向量数据库、chunker、检索器、reranker、路由器和12个pipeline的堆栈，仅仅为了回答“如何重置我的密码？”

“哑瓜”问答agent之所以有效，是因为它专注。它快速、便宜，并且围绕实际用户需求而非AI炒作构建。你可以在一天内部署它，在一分钟内调试它，并根据需要进行扩展。

当你的用例增长时？当然，如果合理，请使用完整的RAG。但不要默认从那里开始。

构建无聊的产品。快速交付。仅在痛苦需要时才进行迭代。

这就是开发之道。

现在去构建你的小型agent。让它回答问题。也许只是也许，不要再使用LangChain了。拥抱简单逻辑，用最少的资源实现最大的价值。打造一个真正服务于用户的AI问答机器人，而不是被复杂技术所束缚。在没有RAG的情况下，也能构建高效实用的AI应用。

By llmtrend

Related Post

RAG

利用 LangSmith 追踪 LLM 工作流：构建 RAG 动漫应用案例

llmtrend
RAG

MovieRag：基于GraphRAG的智能电影推荐聊天机器人，告别流媒体选择困难症

llmtrend
RAG

本地化 SearxNG：为你的大模型保驾护航，打造私有化AI数据检索系统

llmtrend

You Missed

Agent

从微服务到 Agentic Mindset：大模型时代下的架构变革

RAG

抛弃RAG，打造高效“哑瓜”AI问答机器人：无需向量数据库，用简单策略解决复杂问题

AI News

超越人类中心的认知：AI发展的“非人类”议程

AI Tools

Vocavia：从语音到文字的跃迁——利用Whisper赋能智能对话分析