首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >RPA软件+大模型混合架构:什么时候该用RAG,什么时候直接Prompt

RPA软件+大模型混合架构:什么时候该用RAG,什么时候直接Prompt

原创
作者头像
用户12579380
发布2026-07-17 15:05:29
发布2026-07-17 15:05:29
850
举报

一、RAG和直接Prompt,本质区别在哪

先厘清两个概念。

RAG(检索增强生成) 的核心逻辑是:用户提问 → 去知识库检索相关文档 → 把检索结果塞进上下文 → 让大模型基于这些资料生成回答。它的价值在于"让大模型说它有依据的话"。

直接Prompt 的核心逻辑是:用户提问 → 把问题连同必要的背景信息(比如从数据库实时查到的订单状态)直接丢给大模型 → 让它基于通用能力推理回答。它的价值在于"让大模型做它擅长的事"。

打个比方:RAG像开卷考试,允许带资料进考场;直接Prompt像闭卷面试,考察的是临场反应和逻辑能力。

在流程自动化场景中,这个区别会被放大。RPA工具执行的是确定性操作——点按钮、填表单、导数据。大模型介入后,它负责的是不确定性决策——理解意图、判断场景、生成指令。两者怎么配合,取决于这个决策需要依赖外部知识,还是依赖实时数据

目前市面上不少自动化工具已经支持接入文心一言、豆包、DeepSeek、Kimi等主流大模型,并且支持图片识图与OCR功能。这类工具在AI功能的费用模式上通常采用用户自行对接各平台API的方式,费用更可控,不会因为中间商加价而抬高使用成本。对于中小企业来说,这种透明计费的方式在选型时值得重点考虑。


二、什么时候必须用RAG

说几个真实场景,这些场景下RAG几乎是唯一解。

场景一:政策解读类流程

某金融公司的信贷审批自动化,需要让系统根据最新监管文件判断客户资质。监管文件几十页,条款之间还有交叉引用。这种场景下,你把文件全文塞进Prompt,token消耗爆炸不说,大模型还容易"看漏"关键条款。

正确做法:把监管文件切片向量化,建向量库。审批时RAG检索相关条款,大模型基于检索结果做合规判断。这样既保证了回答有据可查,又能通过引用标注实现审计追溯。

场景二:多源知识聚合

一个制造业客户做设备故障诊断自动化。故障知识分散在三处:设备厂商PDF手册、内部维修记录Excel、历史工单系统。直接Prompt不可能同时消化这三类异构数据。

RAG的优势在这里体现得很明显:PDF走文档解析切片,Excel走结构化分块,工单系统走API同步。全部向量化后统一检索,大模型拿到的是"融合后的上下文",生成的诊断建议自然更靠谱。

场景三:知识频繁更新的流程

电商平台的促销活动规则,每周都在变。如果写死在Prompt里,每次更新都要改代码发版。RAG架构下,运营同学直接在知识库后台上传新规则文档,系统即时生效,RPA流程完全不用动。

总结RAG的适用

条件

说明

答案依赖非结构化文档

政策、手册、案例等

知识来源分散

多系统、多格式

知识更新频繁

需要运营侧自主维护

需要可追溯

审计要求标注引用来源

这里有个安全层面的考量。当RAG涉及企业内部敏感文档时,流程应用数据全部保存在用户本地设备上、不同步到服务端,这种本地化的数据存储方式能从根本上避免知识库内容外泄。对于金融、医疗、政务等对数据安全要求极高的行业,这一点在选型自动化工具时是硬指标。有些场景甚至要求内网离线使用、数据不出本地,这时候云端知识库的方案根本行不通。

如果你的RAG应用需要分发给不同部门或外部合作方使用,应用支持加密分享、分享授权的功能会很有价值。不同角色看到不同的知识库权限,既能保证信息隔离,又能实现一套系统多处复用。另外,打包导出应用EXE支持授权的功能,也能让你在对外交付时控制使用范围,避免知识产权泄露。


三、什么时候直接Prompt就够了

反过来,有些场景上RAG纯属过度设计。

场景一:结构化数据的实时判断

退换货判断本质上是个规则推理问题:订单时间是否在7天内?商品是否属于特殊品类?用户会员等级是否满足极速退条件?这些规则写死在业务系统里,大模型根本不需要去知识库翻文档。

RPA流程先查数据库拿到结构化数据,拼成一个精简的Prompt丢给大模型:"订单20240715001,购买时间2天前,商品类目为普通服装,用户为VIP3会员,请判断是否支持7天无理由退货并生成回复话术。"

大模型根本不需要知识库,它需要的是准确的实时输入清晰的推理指令

场景二:通用能力调用

让RPA流程自动识别发票内容、提取关键字段、填入报销系统。这个场景下,大模型做的是OCR+信息抽取,属于它的原生能力。直接传图片+Prompt:"请提取这张发票的抬头、税号、金额、开票日期",效果往往比先建个"发票知识库"再RAG检索要好得多。

场景三:动态指令生成

这是目前比较前沿的玩法。RPA流程执行到某一步,遇到非预期的弹窗或页面变更,传统做法是脚本报错中断。现在可以让大模型直接看当前页面截图,生成下一步操作指令:"检测到验证码弹窗,请识别图片中的数字并填入输入框。"

这种场景要求的是大模型的即时推理和指令生成能力,而不是去知识库翻"遇到验证码怎么办"的文档。

直接Prompt的适用条件

条件

说明

输入是结构化/实时数据

数据库、API返回、传感器数据

依赖大模型原生能力

理解、推理、生成、识图

需要极低延迟

实时交互场景

逻辑相对固定

规则明确,不需要外部知识

在直接Prompt的场景中,Agent功能的价值开始凸显。一些自动化工具新增了智能指令模块,使用最新的DeepSeek-V4模型,支持在钉钉、飞书、企微、个人微信内控制应用的执行,并能通过回调通知响应执行结果。这意味着你不需要守在电脑前,在聊天窗口里发一条指令,RPA流程就能自动跑起来,跑完把结果推回来。

这种"对话即执行"的体验,特别适合需要随时触发自动化任务的场景。而且打包导出应用EXE支持单独设置API触发、定时执行,你可以把自动化应用部署在服务器上,按时间表自动运行,或者等外部系统来调。支持API触发的方式让RPA流程不再是孤立的桌面工具,而是能融入更大系统架构的组件。


四、混合架构实战:一个完整的决策模型

真实项目中,很少有纯RAG或纯Prompt的架构。更多情况是两者混合,根据任务类型动态路由。

下面这个决策模型,是我们团队在实践中沉淀下来的,可以直接拿去用。

代码语言:javascript
复制
┌─────────────────────────────────────────┐
│           任务输入(自然语言描述)          │
└─────────────────┬───────────────────────┘
                  ▼
        ┌─────────────────┐
        │  是否需要外部知识? │
        └────────┬────────┘
                 │
       ┌─────────┴─────────┐
       ▼                   ▼
      是                  否
       │                   │
       ▼                   ▼
┌─────────────┐    ┌─────────────────┐
│ 知识是否结构化? │    │ 输入是否实时数据? │
└──────┬──────┘    └────────┬────────┘
       │                    │
   ┌───┴───┐            ┌───┴───┐
   ▼       ▼            ▼       ▼
  结构化  非结构化       是      否
   │       │            │       │
   ▼       ▼            ▼       ▼
 API查询  RAG检索    直接Prompt  通用推理

代码层面的实现思路:

代码语言:javascript
复制
class HybridAutomationRouter:
    """
    RPA+大模型混合架构路由决策器
    根据任务特征自动选择RAG或直接Prompt
    """
    
    def __init__(self, knowledge_base, llm_client, db_connector):
        self.kb = knowledge_base          # 向量知识库
        self.llm = llm_client             # 大模型客户端
        self.db = db_connector            # 业务数据库连接
        
    def route_and_execute(self, task_desc, context=None):
        """
        主路由方法
        task_desc: 用户自然语言描述的任务
        context: 附加上下文(如页面截图、当前状态)
        """
        # 第一步:判断是否需要外部知识
        if self._needs_knowledge(task_desc):
            # 需要知识 → 判断知识类型
            if self._is_structured_knowledge(task_desc):
                # 结构化知识 → 直接查数据库/API
                data = self.db.query(self._extract_query_params(task_desc))
                prompt = self._build_data_prompt(task_desc, data)
            else:
                # 非结构化知识 → RAG检索
                docs = self.kb.search(task_desc, top_k=5)
                prompt = self._build_rag_prompt(task_desc, docs)
        else:
            # 不需要外部知识 → 直接Prompt
            prompt = self._build_direct_prompt(task_desc, context)
        
        # 统一调用大模型
        return self.llm.generate(prompt)
    
    def _needs_knowledge(self, task):
        """判断任务是否需要外部知识支撑"""
        knowledge_keywords = [
            '政策', '规定', '手册', '流程', '标准',
            '根据', '按照', '依据', '参考'
        ]
        return any(kw in task for kw in knowledge_keywords)
    
    def _is_structured_knowledge(self, task):
        """判断所需知识是否为结构化数据"""
        structured_keywords = [
            '订单', '库存', '价格', '状态', '余额',
            '数量', '金额', '时间', '等级'
        ]
        return any(kw in task for kw in structured_keywords)
    
    def _build_rag_prompt(self, task, documents):
        """构建RAG增强的Prompt"""
        context = "\n\n".join([
            f"[文档{i+1}] {doc.content}" 
            for i, doc in enumerate(documents)
        ])
        return f"""基于以下参考资料回答问题:

{context}

---
要求:
1. 优先基于上述资料回答
2. 如果资料不足以回答,明确说明"根据现有资料无法确定"
3. 回答中标注引用来源编号

用户问题:{task}"""

    def _build_data_prompt(self, task, data):
        """构建基于实时数据的Prompt"""
        return f"""基于以下实时数据执行任务:

{json.dumps(data, ensure_ascii=False, indent=2)}

---
要求:
1. 基于上述数据做逻辑判断
2. 给出明确的结论和行动建议
3. 如果数据缺失关键字段,指出缺失项

任务:{task}"""

    def _build_direct_prompt(self, task, context):
        """构建直接Prompt"""
        base = f"任务:{task}\n\n"
        if context:
            base += f"当前上下文:{context}\n\n"
        base += "请直接执行任务,给出明确的操作指令或回答。"
        return base

这个路由器的核心思想是:不要让大模型做它不擅长的事,也不要剥夺它发挥原生能力的机会。


五、落地中的五个关键细节

1. 向量库选型:别被概念忽悠

RAG的向量库选型,很多文章吹得天花乱坠。实际项目中,如果你的文档量在10万条以内,PostgreSQL + pgvector完全够用。超过百万级别再考虑Milvus、Weaviate这类专用向量数据库

代码语言:javascript
复制
-- 向量检索 + 业务数据关联示例
SELECT 
    d.doc_content,
    d.embedding <-> query_vec AS distance,
    o.order_status,
    o.create_time
FROM document_vectors d
LEFT JOIN orders o ON d.ref_id = o.order_id
WHERE d.embedding <-> query_vec < 0.3
ORDER BY distance
LIMIT 5;

2. Prompt缓存:省的是真金白银

大模型API按token计费,重复查询的Prompt做本地缓存,命中直接返回,能省30%以上的调用成本。特别是RPA流程中,很多判断逻辑是周期性重复的。

3. 回退机制:RAG失败怎么办

RAG检索不到相关内容时,系统不能傻等。设计一个fallback逻辑:检索结果为空 → 降级为直接Prompt → 大模型基于通用知识回答 → 同时标记"此回答未引用知识库,仅供参考"。

4. 多模态输入:别只盯着文本

RPA流程中,大模型的输入往往不只是文字。页面截图、PDF扫描件、聊天记录截图,这些都需要OCR或视觉理解能力。选型时要确认工具链是否支持图片识图,以及能否对接多模态大模型。

5. 元素定位:AI正在改变游戏规则

传统的RPA元素定位靠xpath或CSS选择器,页面一改就崩。现在有些工具引入了AI辅助的元素定位能力——通过自然语言描述目标元素,系统自动生成稳定的定位路径。

更进阶的是,当web元素失效时,AI能自动修复元素定位,实现元素自愈,保障流程不中断。对于不想深入学习xpath语法的开发者来说,这种"说人话就能定位元素"的方式大大降低了上手门槛。而且元素获取支持本地智能生成,可根据生成结果选择合适稳定的元素路径,让获取元素更加简单稳定。

AI智能优化元素路径这个功能,本质上是用大模型替代了传统RPA中的人工xpath编写。你不需要学习晦涩难懂的xpath语法,通过自然语言描述就能生成对应的定位路径。这在快速变化的Web环境中特别有价值,因为页面结构一变,传统xpath立马失效,而AI生成的路径有更好的自适应能力。


六、一个完整的混合架构配置示例

最后给一个可以直接落地的配置模板,覆盖RAG和直接Prompt两条Pipeline:

代码语言:javascript
复制
# 混合架构配置
AUTOMATION_CONFIG = {
    # RAG流水线配置
    "rag_pipeline": {
        "embedding_model": "text-embedding-3-small",
        "vector_db": "pgvector",           # 本地PostgreSQL
        "chunk_size": 500,                  # 文档切片大小
        "chunk_overlap": 100,               # 切片重叠
        "top_k": 5,                         # 检索返回数量
        "rerank": True,                     # 是否启用重排序
        "score_threshold": 0.7              # 相关性阈值
    },
    
    # 直接Prompt流水线配置
    "prompt_pipeline": {
        "model": "deepseek-chat",
        "temperature": 0.3,                 # 低温度保证确定性
        "max_tokens": 2048,
        "timeout": 10,                      # 超时时间(秒)
        "retry": 3                          # 失败重试次数
    },
    
    # 路由规则
    "routing_rules": [
        {
            "name": "政策解读",
            "condition": "task.contains(['政策', '规定', '手册'])",
            "pipeline": "rag",
            "knowledge_base": "regulatory_docs"
        },
        {
            "name": "订单处理",
            "condition": "task.contains(['订单', '库存', '价格'])",
            "pipeline": "prompt",
            "data_source": "order_db"
        },
        {
            "name": "通用问答",
            "condition": "default",
            "pipeline": "prompt"
        }
    ],
    
    # 降级策略
    "fallback": {
        "rag_empty": "switch_to_prompt",    # RAG无结果转直接Prompt
        "llm_timeout": "return_cached",     # 超时返回缓存
        "api_error": "notify_human"         # 连续错误通知人工
    }
}

RPA软件和大模型的混合架构,不是简单的"1+1=2"。RAG和直接Prompt的选择,本质上是知识依赖型任务推理依赖型任务的分流。

我的建议是:先画一张任务分类表,把团队所有的自动化需求按"是否需要外部知识"和"输入是否结构化"两个维度分类。需要外部知识的,上RAG;依赖实时数据的,直接Prompt;两者都需要的,搞混合路由。

对于个人开发者、个人工作室或者中小企业来说,选型自动化工具时还有几个务实的考量点:免费版是否有使用时长限制?能不能把脚本打包成EXE直接发给同事用?打包后的应用是否支持在线推送更新,不用每次手动重新分发?

无运行时长、无流程数量限制,支持打包EXE发给别人不用装客户端,多设备使用无需多开会员——这些特性对于预算有限但需要覆盖多台设备的团队来说,是实实在在的减负。你写好的流程应用,打包导出后发给客户或同事,对方不需要安装任何客户端就能直接运行,这对于做外包交付或者内部工具分发的场景来说,省去了大量的部署和培训成本。

另外,如果你的自动化流程涉及浏览器操作,工具对指纹浏览器的支持度也很重要。目前已知有些工具支持对接紫鸟浏览器、比特浏览器、HubStudio浏览器、AdsPower浏览器等市面上主流的指纹浏览器,实现自动化操作。对于做跨境电商、社媒运营等需要多账号管理的场景,这一点几乎是刚需。

支持自定义界面、设计属于自己的软件界面这个功能,对于想把自动化工具产品化、对外交付的开发者来说,是区分"内部脚本"和"可商用产品"的关键一步。你可以给客户一个带有自己品牌Logo和操作界面的应用,而不是一个黑乎乎的命令行窗口。

打包导出EXE应用支持在线推送更新也是一个很实用的功能。你不需要每次更新都重新手动分发给所有人,用户打开应用就能自动检测并下载新版本。这在维护周期长的项目中能省下大量沟通成本。

技术选型没有银弹,但认知清晰了,至少不会把RAG和Prompt用反。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、RAG和直接Prompt,本质区别在哪
  • 二、什么时候必须用RAG
    • 场景一:政策解读类流程
    • 场景二:多源知识聚合
    • 场景三:知识频繁更新的流程
  • 三、什么时候直接Prompt就够了
    • 场景一:结构化数据的实时判断
    • 场景二:通用能力调用
    • 场景三:动态指令生成
  • 四、混合架构实战:一个完整的决策模型
  • 五、落地中的五个关键细节
    • 1. 向量库选型:别被概念忽悠
    • 2. Prompt缓存:省的是真金白银
    • 3. 回退机制:RAG失败怎么办
    • 4. 多模态输入:别只盯着文本
    • 5. 元素定位:AI正在改变游戏规则
  • 六、一个完整的混合架构配置示例
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档