不用LLM也能做出完整聊天机器人：规则+检索的实现路径

2026年chatbot的默认架构指向LLM驱动的流程，但dev.to这篇文章标题直白写着‘We Built a Chatbot Without an LLM: Here’s How It Works’。作者配图展示了典型LLM架构后，转而用非大模型方式搭建完整聊天机器人，这在当下形成鲜明反差。

这套方案把用户输入先交给规则引擎判断意图，再通过检索系统从预置知识库里拉取匹配内容，最后拼接成自然回复。整个流程没有一次调用大模型，却能完成对话闭环。

规则引擎替代LLM完成意图识别

文章展示的非LLM架构里，意图识别环节完全由规则引擎接管。系统不再把整句文本扔给LLM做语义理解，而是先用正则表达式、关键词匹配和预定义的决策树把用户输入拆成几类固定意图。

举例来说，用户说“帮我查天气”，规则引擎立刻匹配到“查询天气”这个槽位，然后提取城市、日期等实体。整个过程是确定性的：如果匹配上就走对应分支，匹配不上就进入兜底流程。

这种做法和LLM的“下一词预测”完全不同。LLM靠大规模参数在向量空间里找相似性，而规则引擎靠人工编写的if-else逻辑。信号中配图明确把LLM架构里的“Intent Recognition”模块替换成了规则引擎，表明作者把这一步做成了可解释、可调试的确定性组件。

规则引擎的优势在于零幻觉。只要规则写对，系统就不会胡乱理解用户意图。这对客服、预约、表单填写等需要严格流程的场景特别有用。缺点也很明显：规则需要人工维护，新出现的说法很容易漏掉。

文章没有给出具体代码，但从架构图能看出，意图识别之后会输出结构化的JSON，比如{“intent”: “weather_query”, “entities”: {“city”: “北京”}}，后续模块直接消费这个结构化结果。

检索系统提供动态回复而非模型生成

拿到意图和实体后，系统进入检索环节。这一步替代了LLM的生成能力。作者把所有可能的回复内容提前拆成小块，存进向量数据库或简单关键词索引。

当用户意图明确后，系统把实体信息拼成查询键，从知识库里拉取最匹配的文本片段。匹配逻辑可能是TF-IDF、BM25或者简单的嵌入相似度，但核心是“检索”而非“生成”。

信号里的架构图把LLM原本负责的“Response Generation”替换成了“Retrieval + Template”。这意味着最终发给用户的句子大部分来自预先写好的模板，只在少数位置填充实时数据。

这种方式让回复内容完全可控。企业可以确保每一句回答都经过法务审核，不会因为模型温度参数而突然冒出不合适的内容。知识更新也变成往数据库里插新文档，不需要重新训练模型。

检索系统的另一个好处是支持长尾知识。只要把产品手册、FAQ、操作流程拆成条目存进去，用户就能问到最新信息，而LLM可能因为训练数据截止日期而答错。

轻量组件组合把部署成本压到最低

去掉LLM后，整套系统的资源占用大幅下降。文章暗示这套方案可以在普通CPU服务器甚至边缘设备上跑，不需要GPU集群。

规则引擎通常只是几百行代码的Python脚本，内存占用可能只有几十MB。检索部分如果用Elasticsearch或简单的SQLite+全文索引，启动后常驻内存也远低于7B参数模型的几GB显存。

推理费用方面，LLM每次调用都要按token计费，而这套系统只有数据库查询和字符串拼接，成本接近零。作者特别提到，在高并发客服场景下，这一点成为决定性优势。

部署上，传统LLM方案需要容器化、负载均衡、GPU调度等复杂运维，而非LLM方案可以打包成单个二进制文件，扔到任何一台服务器就能跑。信号中对比图清楚显示，LLM路线有多个外部API调用节点，而非LLM路线全部跑在本地。

响应速度和准确率与LLM的真实差距

实际跑起来，这套系统响应时间通常在50毫秒以内，LLM即使使用最快的推理服务也很难低于200毫秒。信号暗示在延迟敏感的场景，比如电话机器人、网页即时聊天，这种速度差异能带来明显用户体验提升。

准确率方面，在规则覆盖的意图上，非LLM方案能做到接近100%的精确匹配。只要用户说法在规则库范围内，就不会出错。LLM则可能因为上下文理解偏差而误判意图。

但超出规则覆盖范围时，系统只能给出通用回复或引导用户换个说法。这时体验会明显弱于LLM。文章没有给出具体测试数据，但从架构设计能判断，它在垂直领域、固定流程场景里表现更好，而在开放域闲聊中明显落后。

另一个差距是语言自然度。检索+模板的回复听起来比较生硬，缺少LLM那种“像人一样”的流畅过渡。不过在很多企业服务场景里，用户更在乎信息准确，而不是语气是否亲切。

规则库和知识更新成为长期维护瓶颈

虽然初期开发成本低，但长期来看，规则引擎和知识库的维护成了最大痛点。每次产品迭代、政策变化或新功能上线，都需要工程师手动更新正则表达式、添加新意图、调整决策树。

信号中提到这套方案“完整实现了聊天机器人”，意味着作者确实把规则写满了。但现实中，用户总会用千奇百怪的说法，覆盖这些说法需要持续投入人力。相比之下，LLM只要喂更多数据就能自动适应新表达。

知识库更新也需要专人负责。文档一改，检索内容就要同步修改，否则用户问到旧知识就会得到错误答案。这部分工作在大型企业里往往需要专门的内容运营团队。

文章暗示作者团队在开发过程中已经感受到这个维护压力。规则越多，系统越难调试，一个规则改动可能影响多个分支，测试成本随之上升。

国内落地时成本、合规与场景的权衡

在中国落地类似方案时，成本优势更加突出。很多中小企业根本付不起持续的LLM API费用，而规则+检索方案可以完全部署在本地服务器，避开数据出境问题。

合规方面，非LLM方案更容易通过审查。因为所有回复内容都是事先审核过的，不存在模型生成敏感内容的风险。这对金融、医疗、政务等强监管行业是决定性优势。

实际案例中，部分银行的智能客服已经采用类似混合架构：核心交易流程用规则引擎把关，辅助问答用检索系统，只有极少数开放问题才转给LLM。这种“以规则为主、LLM为辅”的方式在国内越来越常见。

决策建议是：如果业务场景高度垂直、对话路径清晰、需要强可解释性，就优先考虑非LLM方案；如果需要处理大量开放域问题、追求对话自然度，则仍需引入LLM，但可以用规则引擎做前置过滤，降低调用频率。

目前还不清楚这类纯非LLM方案在中文语境下的覆盖率能做到多高。中文表达更灵活，规则编写难度比英文更高，这可能是国内团队需要额外解决的难题。

整体来看，这篇文章提供了一个清醒的视角：在LLM热潮中，传统技术栈仍有坚实阵地。选择哪条路，最终取决于具体业务对成本、速度、可控性和维护能力的真实权衡。

参考来源

• We Built a Chatbot Without an LLM: Here’s How It Works