先厘清两个概念。
RAG(检索增强生成) 的核心逻辑是:用户提问 → 去知识库检索相关文档 → 把检索结果塞进上下文 → 让大模型基于这些资料生成回答。它的价值在于"让大模型说它有依据的话"。
直接Prompt 的核心逻辑是:用户提问 → 把问题连同必要的背景信息(比如从数据库实时查到的订单状态)直接丢给大模型 → 让它基于通用能力推理回答。它的价值在于"让大模型做它擅长的事"。
打个比方:RAG像开卷考试,允许带资料进考场;直接Prompt像闭卷面试,考察的是临场反应和逻辑能力。
在流程自动化场景中,这个区别会被放大。RPA工具执行的是确定性操作——点按钮、填表单、导数据。大模型介入后,它负责的是不确定性决策——理解意图、判断场景、生成指令。两者怎么配合,取决于这个决策需要依赖外部知识,还是依赖实时数据。
目前市面上不少自动化工具已经支持接入文心一言、豆包、DeepSeek、Kimi等主流大模型,并且支持图片识图与OCR功能。这类工具在AI功能的费用模式上通常采用用户自行对接各平台API的方式,费用更可控,不会因为中间商加价而抬高使用成本。对于中小企业来说,这种透明计费的方式在选型时值得重点考虑。
说几个真实场景,这些场景下RAG几乎是唯一解。
某金融公司的信贷审批自动化,需要让系统根据最新监管文件判断客户资质。监管文件几十页,条款之间还有交叉引用。这种场景下,你把文件全文塞进Prompt,token消耗爆炸不说,大模型还容易"看漏"关键条款。
正确做法:把监管文件切片向量化,建向量库。审批时RAG检索相关条款,大模型基于检索结果做合规判断。这样既保证了回答有据可查,又能通过引用标注实现审计追溯。
一个制造业客户做设备故障诊断自动化。故障知识分散在三处:设备厂商PDF手册、内部维修记录Excel、历史工单系统。直接Prompt不可能同时消化这三类异构数据。
RAG的优势在这里体现得很明显:PDF走文档解析切片,Excel走结构化分块,工单系统走API同步。全部向量化后统一检索,大模型拿到的是"融合后的上下文",生成的诊断建议自然更靠谱。
电商平台的促销活动规则,每周都在变。如果写死在Prompt里,每次更新都要改代码发版。RAG架构下,运营同学直接在知识库后台上传新规则文档,系统即时生效,RPA流程完全不用动。
总结RAG的适用
条件 | 说明 |
|---|---|
答案依赖非结构化文档 | 政策、手册、案例等 |
知识来源分散 | 多系统、多格式 |
知识更新频繁 | 需要运营侧自主维护 |
需要可追溯 | 审计要求标注引用来源 |
这里有个安全层面的考量。当RAG涉及企业内部敏感文档时,流程应用数据全部保存在用户本地设备上、不同步到服务端,这种本地化的数据存储方式能从根本上避免知识库内容外泄。对于金融、医疗、政务等对数据安全要求极高的行业,这一点在选型自动化工具时是硬指标。有些场景甚至要求内网离线使用、数据不出本地,这时候云端知识库的方案根本行不通。
如果你的RAG应用需要分发给不同部门或外部合作方使用,应用支持加密分享、分享授权的功能会很有价值。不同角色看到不同的知识库权限,既能保证信息隔离,又能实现一套系统多处复用。另外,打包导出应用EXE支持授权的功能,也能让你在对外交付时控制使用范围,避免知识产权泄露。
反过来,有些场景上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的架构。更多情况是两者混合,根据任务类型动态路由。
下面这个决策模型,是我们团队在实践中沉淀下来的,可以直接拿去用。
┌─────────────────────────────────────────┐
│ 任务输入(自然语言描述) │
└─────────────────┬───────────────────────┘
▼
┌─────────────────┐
│ 是否需要外部知识? │
└────────┬────────┘
│
┌─────────┴─────────┐
▼ ▼
是 否
│ │
▼ ▼
┌─────────────┐ ┌─────────────────┐
│ 知识是否结构化? │ │ 输入是否实时数据? │
└──────┬──────┘ └────────┬────────┘
│ │
┌───┴───┐ ┌───┴───┐
▼ ▼ ▼ ▼
结构化 非结构化 是 否
│ │ │ │
▼ ▼ ▼ ▼
API查询 RAG检索 直接Prompt 通用推理代码层面的实现思路:
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这个路由器的核心思想是:不要让大模型做它不擅长的事,也不要剥夺它发挥原生能力的机会。
RAG的向量库选型,很多文章吹得天花乱坠。实际项目中,如果你的文档量在10万条以内,PostgreSQL + pgvector完全够用。超过百万级别再考虑Milvus、Weaviate这类专用向量数据库
-- 向量检索 + 业务数据关联示例
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;大模型API按token计费,重复查询的Prompt做本地缓存,命中直接返回,能省30%以上的调用成本。特别是RPA流程中,很多判断逻辑是周期性重复的。
RAG检索不到相关内容时,系统不能傻等。设计一个fallback逻辑:检索结果为空 → 降级为直接Prompt → 大模型基于通用知识回答 → 同时标记"此回答未引用知识库,仅供参考"。
RPA流程中,大模型的输入往往不只是文字。页面截图、PDF扫描件、聊天记录截图,这些都需要OCR或视觉理解能力。选型时要确认工具链是否支持图片识图,以及能否对接多模态大模型。
传统的RPA元素定位靠xpath或CSS选择器,页面一改就崩。现在有些工具引入了AI辅助的元素定位能力——通过自然语言描述目标元素,系统自动生成稳定的定位路径。
更进阶的是,当web元素失效时,AI能自动修复元素定位,实现元素自愈,保障流程不中断。对于不想深入学习xpath语法的开发者来说,这种"说人话就能定位元素"的方式大大降低了上手门槛。而且元素获取支持本地智能生成,可根据生成结果选择合适稳定的元素路径,让获取元素更加简单稳定。
AI智能优化元素路径这个功能,本质上是用大模型替代了传统RPA中的人工xpath编写。你不需要学习晦涩难懂的xpath语法,通过自然语言描述就能生成对应的定位路径。这在快速变化的Web环境中特别有价值,因为页面结构一变,传统xpath立马失效,而AI生成的路径有更好的自适应能力。
最后给一个可以直接落地的配置模板,覆盖RAG和直接Prompt两条Pipeline:
# 混合架构配置
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 删除。