# Dify 搭建 ESP32 设备文档 RAG 问答助手## 一、为什么做这个项目日常开发中工程师经常要查阅 ESP32 系列芯片的技术文档——引脚定义、ADC 注意事项、深度睡眠功耗这些细节。官方文档以英文为主翻找费时而且很多关键信息比如ADC2 与 Wi-Fi 共用射频路径往往藏在大段文字里。于是我想做一个问答助手用户用自然语言提问系统基于技术文档给出**带依据**的答案。传统方案是维护一份 FAQ但覆盖不全、更新成本高。RAG检索增强生成正好解决这个问题先检索知识库再让大模型基于上下文作答答案可溯源还能自动覆盖新文档。## 二、为什么选 Dify选 Dify 有三个原因第一它内置知识库、向量检索、RAG 等开箱即用的能力不用自己写向量数据库和检索代码第二可视化编排工作流意图识别、条件分支、知识检索、LLM 节点可以拖拽串联迭代极快第三支持混合检索、Rerank 等高级能力方便后续优化。模型方面中文语料我选 bge-m3 做 Embedding生成模型用千问成本与效果比较均衡。## 三、知识库构建数据是根本RAG 的效果上限取决于语料质量。我把 ESP32 系列经典款、S2、S3、C3、C6的技术资料整理成一份结构化的《ESP32 设备技术文档》覆盖型号对比、引脚与 GPIO、电源与低功耗、内存、无线、外设接口、开发板、开发框架、FAQ 等章节语料采用段落式文章风格每段一个完整语义。上传 Dify 后分段参数设置为分段标识符 \n段落边界、最大长度 1024 字符、重叠 50 字符保证每个片段由完整段落组成、语义自包含。这里有一个重要教训**分段太小会从句子中间硬切导致检索片段语义残缺。** 我最初想把分段压到 300测试后发现长段落被切得支离破碎回答经常缺上下文最后统一用 1024命中质量明显提升。RAG 项目七分在数据真不是一句空话。## 四、工作流编排意图识别 两次分支工作流是项目的核心整体结构如下 用户输入 → 意图识别代码节点→ 条件分支①greeting / human_service / error 直接回复其余进入知识检索 → 条件分支②检索结果为空走闲聊 LLM有结果走 RAG LLM意图识别用一段基于短语匹配的 Python 代码实现输入用户 query输出 type、response、need_rag、original_query 四个字段把你好谢谢转人工这类寒暄和人工服务请求在检索前就拦截掉避免无意义的检索开销。分类结果用条件分支①判断三类意图直接回复对应话术其余才真正触发检索。知识检索节点的查询我特意用 original_query原文而非处理后的文本保持问题原貌。检索后再次分支result 为空说明知识库没覆盖走闲聊 LLM 兜底既答天气这类闲聊也用大模型自身知识补充result 非空走 RAG LLM提示词要求严格基于上下文回答、不添油加醋并对知识库未覆盖的情况给出仅供参考的说明。## 五、测试与踩坑测试围绕三条线意图识别是否走对分支、知识库命中是否相关、边界情况是否有合理出口。最典型的一个 bug问今天天气怎么样早期版本会误判成打招呼——因为短语匹配把怎么样这种短词也做了**包含匹配**被长句包含进去。修复方法是收紧规则只对 4 字以上的关键短语做包含匹配短词只做完全相等匹配问题立刻解决。另外还测了模糊缩写GPIO34、中英混问esp32 deep sleep 电流、知识库未覆盖的问题等确保每个分支都有合理出口。## 六、总结通过 Dify我用很少的代码搭起了意图识别 知识检索 RAG 闲聊兜底的完整问答助手。最大的体会**数据质量决定上限分支设计决定体验**。语料的结构和分段粒度直接决定命中质量工作流的关键是用分支把寒暄、技术问答、兜底拆开各走各的路互不干扰。后续我计划接入 Rerank 精排提升准确率并增加文档自动同步让知识库随官方文档持续更新。