Flowise 实战：Web Scraping 与文档问答一体化方案

准备工作：启动 Flowise 并加载本地模型

你提到已用 vLLM 部署了本地模型（如 Qwen2-7B-Instruct），这是关键一步。Flowise 本身不运行模型，它需要一个兼容 OpenAI API 格式的后端。vLLM 正好提供这个能力：

python -m vllm.entrypoints.openai.api_server \
  --model /models/qwen2 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2

然后在 Flowise 的 LLM 节点中，选择 OpenAI 类型，把 Base URL 填为 http://localhost:8000/v1，Model Name 填 qwen2。这样，Flowise 就'认出'了你的本地大模型。

搭建 Web Scraping + RAG 工作流

打开 Flowise 界面（http://localhost:3000），新建一个空白流程，按以下顺序添加并连接节点。

首先处理网页抓取与清洗部分。添加 Web Scraper 节点，设置 URL 为项目文档首页（如 https://xxx.github.io/docs/）。接着连接到 HTML to Text 节点，勾选'Remove navigation elements'和'Preserve headings'以去除干扰项。最后连到 Text Splitter 节点，设置 Chunk Size = 500，Chunk Overlap = 50，Split By 设为 Paragraph。

小技巧：Web Scraper 节点支持 XPath，如果首页是目录页，可以用 //a[contains(@href, 'guide')]/@href 提取所有指南子页面链接，实现全站抓取。

随后进入向量化与存储环节。接 Embeddings 节点，选择 HuggingFace Embeddings，Model Name 填 BAAI/bge-m3（中英双语强，免费）。再接 Vector Store 节点，选择 In-Memory Vector Store（测试用）或 PostgreSQL（生产用）。最后接 Save to Vector Store 节点，完成入库。

构建问答链时，添加 LLM 节点指向你本地的 vLLM 服务，以及 Retrieval 节点连接前面的 Vector Store，设置 Top K = 3。按顺序连：Retrieval → Prompt Template → LLM。

添加 Prompt Template 节点，输入标准 RAG 提示词：

你是一个专业的技术文档助手。请基于以下上下文回答问题，不要编造信息。 如果上下文没提及相关内容，请直接回答'未在文档中找到相关信息'。 上下文： {context} 问题：{question}

如果需要对外提供服务，可以在流程末尾加 API Response 节点。部署后，你会得到一个类似 /api/v1/prediction/xxx 的端点，前端或后端系统直接 POST JSON 调用即可：

{"question": "如何配置代理？"}

整个流程搭建完成后，点击右上角'Deploy'，等待几秒，状态变为'Active'，就可以开始测试了。

效果实测：不只是'能答'，而是'答得准'

我们用几个真实问题测试这个工作流：

对比纯 ChatGPT 直接提问同文档 PDF，后者常混淆不同版本特性，而 Flowise 因强制依赖检索上下文，答案边界清晰、可追溯。

进阶玩法：让工作流真正'活'起来

Flowise 的潜力远不止于静态文档问答。结合其节点灵活性，你可以解锁更多业务场景：

动态知识同步：网页内容自动更新

很多文档是持续更新的。Flowise 支持 Cron Trigger 节点（需启用插件），你可以设置每天凌晨 2 点自动触发整个 Web Scraping 流程：重新抓取、重新向量化、自动覆盖旧向量库。这样，你的问答机器人永远'知道最新版文档在说什么'。

多源融合问答：网页 +PDF+ 数据库三位一体

一个典型场景：销售同事想查'某客户签约合同中的 SLA 条款，以及该客户最近三次工单的解决时长'。

• 用 Web Scraper 抓取合同管理系统公开页（如有）
• 用 PDF Loader 加载本地合同扫描件
• 用 SQL Agent 节点连接工单数据库，执行 SELECT * FROM tickets WHERE customer_id = ? ORDER BY created_at DESC LIMIT 3
• 最后用 LLM 节点综合三路信息生成摘要

这在传统 RAG 架构里需要三套独立 pipeline，而在 Flowise 里，只是多拖几个节点、多连几条线。

权限与审计：谁问了什么，系统记得清清楚楚

Flowise 企业版（或自研扩展）支持在 API Request 节点前加 Authentication 节点，对接 LDAP 或 JWT；在 API Response 节点后加 Log to Database 节点，把每次提问、返回、耗时、命中 chunk 全部记入日志表。这对金融、医疗等强合规场景至关重要——你不仅能回答问题，还能证明'这个答案是基于哪几段原文生成的'。

总结：Flowise 不是替代工程师，而是放大工程师的价值

回看开头那句'不会写 LangChain，却想 10 分钟把公司知识库变成问答 API'，它说对了一半。Flowise 真正的价值，不在于让非技术人员取代开发者，而在于让资深工程师从重复劳动中解放出来。

过去，一个 RAG 项目可能花 2 周在环境配置、向量库选型、分块策略调优上；现在，这些变成画布上的标准节点，2 小时就能跑通 MVP。省下的时间，可以用来思考：

• 用户真正卡在哪一步？是提问方式不对，还是知识库覆盖不全？
• 答案是否需要附带原文链接、责任人、更新日期？
• 能不能把问答结果自动推送到飞书群，触发下一步审批？

Flowise 把'构建 AI 能力'的成本，从'人天'级拉到了'分钟'级。它不承诺'完美答案'，但保证'快速验证'；不追求'全自动'，但做到'全可控'。当你不再为技术细节焦头烂额，才能真正聚焦于那个最本质的问题：这个 AI，到底在帮人解决什么实际困难？