Post

混合技术应用

本文通过9个典型场景，拆解RAG、Agent、多模态处理、工具调用、工程化部署等核心技术的混合应用逻辑。RAG构建企业知识库，解决幻觉与私有知识问题，生产端经文档解析、智能切片、向量化建库，消费端通过多路召回、重排、流式生成实现闭环。Agent通过意图路由、短期/长期记忆与工具调用形成对话记忆闭环；多Agent编排借助总控与子Agent分工处理复杂任务。FC、MCP与RAG构成“黄金三角”，分别负责动态工具调用、标准化接入与静态知识检索。多模态摘要降维、NL2SQL自助取数、高并发工程策略、数仓ETL及推荐系统三层链路进一步拓展应用边界。读者可掌握从技术选型到系统落地的完整思路，核心在于场景化组合RAG+向量库+大模型+工具链的底层逻辑。

AI 应用 阅读 13 点赞 0 评论 0

导语

在大模型应用开发中，单一技术（如纯大模型调用或简单RAG）往往难以满足复杂业务需求。本文将通过9个典型场景，拆解RAG、Agent、多模态处理、工具调用、工程化部署等核心技术的混合应用逻辑，帮助你理解不同技术如何协同解决实际问题（如企业知识库、智能问答、数据取数等），掌握从技术选型到系统落地的完整思路。

场景1 · 完整RAG生产链路：构建企业知识底座

核心目标

RAG（检索增强生成）是解决大模型“幻觉”和“私有知识”的核心架构，其生产端负责将非结构化文档转化为结构化向量数据，消费端负责实时检索并生成回答。我们先从离线建库（生产端） 和在线问答（消费端） 两部分展开。

1. 生产端：离线构建向量知识库

RAG的“知识基建”是将原始文档转化为可检索的向量数据，流程如下：

  1. 多模态文档加载
    我们需要处理企业内的各类文档：PDF（含表格/公式）、DOCX（排版复杂）、图片（截图/图表）等。这些文档是后续知识的“原材料”，需统一接入系统。

  2. 解析清洗
    原始文档格式复杂，需先解析和清洗：
    - MinerU：专业文档解析工具，支持复杂版面分析（如表格识别、段落结构提取），避免OCR误识别。
    - OCR：对图片中的文字进行提取（如扫描件、PPT截图），将“图片文本”转为“可编辑文本”。
    为什么需要解析清洗？ 直接喂模型会导致信息错位（如表格行列丢失），清洗后才能保证后续切片和向量化的准确性。

  3. 滑动窗口智能切片
    大模型上下文窗口有限（如GPT-4为8k tokens），需将长文档按规则切片：
    - 窗口大小：500字符（覆盖单段核心内容）
    - 滑动步长：100字符（避免信息断裂，同时控制窗口重叠度）
    示例：一篇1000字符的文档会被切为“500+100”“600+100”“700+100”... 直到覆盖全文。

  4. Embedding向量化
    将切片后的文本转为向量（数值化表示语义）：
    - 模型选择：M3E（开源强语义）、BGE（轻量高效）、豆包2048维模型（企业级精度）
    - 维度意义：2048维是当前主流选择，能平衡语义捕捉能力和存储成本。
    作用：文本→向量后，系统可通过“向量相似度”快速召回相关内容，替代传统关键词检索。

  5. 向量库持久化
    向量需存储在高效检索的数据库中：
    - Weaviate：支持语义检索+元数据过滤（如按文档类型/时间筛选），适合企业级复杂场景。
    - FAISS：轻量级、高性能，适合中小规模知识库（如个人项目）。
    图示：这个流程构建了RAG的“知识仓库”，为消费端提供“可检索的知识底座”。

flowchart LR
 subgraph 生产端
 A[多模态文档] --> B[解析清洗 MinerU/OCR]
 B --> C[滑动窗口切片 500/100]
 C --> D[Embedding M3E/BGE]
 D --> E[(向量库 Weaviate/FAISS)]
 end

2. 消费端：实时问答的完整闭环

消费端负责将用户问题转化为精准回答，流程如下：

  1. 用户Query预处理
    用户输入问题后，先做“查询重写”（如将口语化问题转为结构化提问）和“关键词提取”（如提取核心词“产品参数”“售后政策”），为后续召回做准备。

  2. 多路召回：精准+语义双保险
    同时调用两种召回策略，避免单一方法的局限性：
    - BM25关键词召回：基于传统TF-IDF的关键词匹配，适合“字面匹配”场景（如“我的订单号是XXX”）。
    - 向量语义召回：从向量库中检索与Query语义最相似的TopN片段（如Weaviate/FAISS的ANN检索）。
    核心：两者结合覆盖“关键词匹配”和“语义理解”，提升召回率。

  3. Cross-Encoder重排
    对多路召回的TopN片段（如BM25返回50条+向量返回50条），用BGE-Reranker模型打分排序，选出最相关的Top5片段（避免“信息过载”）。
    为什么需要重排？ 原始召回结果可能包含重复或不相关内容，重排后回答质量显著提升。

  4. 上下文组装与生成
    将召回片段、系统提示词（如“基于以下文档回答”）、历史对话（如用户之前的问题）拼接成完整上下文，输入大模型：
    - 大模型生成：用SSE（Server-Sent Events）流式输出，降低用户等待感（如ChatGPT的实时打字效果）。
    - 后处理：过滤敏感内容、格式美化（如Markdown转HTML）。

flowchart LR
 subgraph 消费端
 Q[用户Query] --> QR[查询重写+关键词]
 QR --> MR[多路召回 BM25+向量]
 E --> MR
 MR --> RR[Rerank BGE-Reranker]
 RR --> CTX[上下文组装]
 CTX --> GEN[LLM生成 SSE流式]
 end

场景1总结

  • 融合技术：RAG（检索增强）+ 向量库/Embedding（知识存储）+ 大模型调用/流式（生成）+ 提示词工程（上下文控制）
  • 典型项目：企业内部知识库（如“产品手册问答系统”“员工培训知识库”）

场景2 · Agent记忆闭环：让对话系统具备“思考能力”

核心目标

Agent的核心是“意图路由+记忆管理”，通过短期记忆（对话连贯性）、长期记忆（知识沉淀）、工具调用（动态能力）形成闭环，解决“单次对话无法持续思考”的问题。

1. 对话Agent的核心链路

一个完整的对话Agent包含6个环节：
用户输入 → 意图识别 → 短期记忆 → 长期记忆 → 模型生成 → 记忆更新

2. 关键环节拆解

  1. 意图识别：用户问“我的订单进度”还是“如何退款”，需分类到不同能力模块（如“订单查询”“售后处理”），避免系统“盲目回答”。
  2. 短期记忆：存储最近对话上下文，用MySQL存储前5轮对话（用户/助手消息），每5轮生成摘要（如“用户询问了3次退款流程，当前关注退款时效”），避免对话过长导致上下文爆炸。
  3. 长期记忆：存储企业知识或历史对话中的关键信息，用Weaviate按语义召回（如“用户之前问过‘产品A的参数’，需召回相关文档”），支持6类元数据过滤（如“仅召回2023年后的文档”）。
  4. 模型路由：根据任务类型选择模型（如“快速问答用小模型，复杂分析用GPT-4”），生成后通过SSE流式输出。
  5. 记忆更新：对话结束后，评估回复的“重要性”：
    - 关键事实（如“退款时效为3个工作日”）写入长期库；
    - 主题脉络（如“退款流程优化建议”）沉淀为摘要，用于后续对话。
  6. 可观测性：记录会话ID、token消耗、关键操作日志，便于问题排查和成本分析。

场景2总结

  • 融合技术：Agent框架（意图路由）+ 向量库（长期记忆）+ 关系型数据库（短期记忆）+ 模型路由 + 日志落库
  • 典型项目：智能客服（如“小智平板”的多轮对话系统）

场景3 · 多Agent编排：复杂任务的“分工协作”

核心目标

当单一Agent无法处理复杂任务（如“同时处理订单查询+数据分析+生成报告”）时，需通过总控Agent+子Agent+工具链实现分工协作，提升系统效率。

1. 多Agent架构拆解

  1. 总控Agent：负责“意图识别+任务分发”，如“用户问‘我的销售数据’，总控判断需调用‘数据分析子Agent’”。
  2. 子Agent：按领域分工，如“写作子Agent”（擅长生成长文本）、“判题子Agent”（擅长逻辑推理）、“多模态子Agent”（处理图文）。
    - 子Agent内部策略：ReAct（边思考边执行，如“先确认数据来源，再调用API”）或Plan-and-Execute（先规划步骤，再执行）。
  3. 工具层：
    - Function Calling：模型自主决定调用工具（如“查询订单API”），输出JSON格式参数（如{"order_id": "12345"}）。
    - MCP Server：将工具封装为标准化服务（如“工单查询API”“OCR识别服务”），跨项目复用，解耦总控与工具。
  4. 编排框架：用LangGraph搭建状态机，支持循环逻辑（如“用户追问→重新判断→子Agent再次调用”）、人机协同（敏感问题转人工审批）。

2. 实例：LangGraph客服回复流程

flowchart LR
 Q[用户输入] --> IR[意图识别]
 IR -->|简单问题| W[工作流处理]
 IR -->|复杂/敏感| A[人工审批]
 W --> GEN[生成回复]
 A --> GEN
 GEN --> L[日志记录]

场景3总结

  • 融合技术：Agent框架（总控+子Agent）+ Function Calling（工具调用）+ MCP（工具标准化）+ Dify（低代码平台）
  • 典型项目：企业级多任务系统（如“小智平板”的跨部门协作工具）

场景4 · FC/MCP/RAG技术边界：三者协同的“黄金三角”

当开发大模型应用时，常遇到“RAG解决知识、FC解决工具、MCP解决标准化”的分工问题，但三者如何协同？

1. 技术职责边界

  • Function Calling（FC）：模型的“手脚”——理解意图后，自主调用工具（如“查订单”“生成图表”），是行为路由机制。
  • MCP（多端通信网关）：工具与系统的“连接器”——将工具封装为标准化服务（如“工单API→MCP Server”），跨平台可复用，解耦工具与调用方。
  • RAG：知识检索的“大脑”——回答前“检索私有知识库”，避免大模型幻觉，是静态知识增强架构。

2. 协同流程示例（企业客服场景）

用户问：“我的工单进度是多少？”
1. RAG先检索：从知识库查“工单查询流程”（静态知识），若有结果则优先回答；
2. 需实时数据则FC调用工具：若知识库无结果，FC调用工单API（该API通过MCP Server封装）；
3. MCP标准化接入：工单API作为MCP的一个服务，总控Agent无需关心API细节，只需调用/api/workorder?order_id=123；
4. 生成回复：将工具返回的“工单状态”注入上下文，生成最终回答。

场景4总结

  • 融合技术：Function Calling（动态工具调用）+ MCP（工具标准化）+ RAG（知识检索）
  • 典型项目：企业智能工作台（支持“知识查询+工具操作+数据生成”的一站式服务）

场景5 · 多模态摘要降维：解决图文视频的上下文爆炸

核心目标

当处理大量图文/视频时，直接喂模型会因上下文窗口限制导致“信息过载”，需通过“先摘要降维再生成”控制成本同时保留核心信息。

1. 多模态处理流程

  1. 原始数据预处理：公众号文章（含图片）、学员图文视频（含截图）→ OCR提取文字，MinerU清洗版面（如“合并重复段落”），分段为500字符块。
  2. 大文件分流策略：
    - 视频>50MB：调用Files API（支持≤512MB，7天内临时存储）；
    - 图片>10MB：过滤或压缩（如保留关键图表，删除冗余背景）。
  3. 生成结构化摘要：调用大模型生成“高密度短文本”（如“用户上传的视频标题为‘2023产品发布会’，摘要：‘发布会发布了3款新品，重点功能包括XXX’”），向量化存Weaviate。
  4. 按需召回生成：用户提问时，向量匹配召回Top5摘要（阈值0.7），融合生成最终内容；若失败则降级（仅文本重试）。

场景5总结

  • 融合技术：大模型生成（摘要）+ 向量库（存储）+ 多模态处理（OCR/MinerU）
  • 典型项目：商学咨询AI（处理学员上传的课程视频/图文资料）

场景6 · NL2SQL自助取数：让非技术人员也能查数据

核心目标

解决企业“数据孤岛”问题，让业务人员通过自然语言直接生成SQL取数，无需依赖技术团队支持。

1. NL2SQL链路拆解

  1. 训练数据准备：
    - 业务术语映射表（如“订单量”→orders.count，“用户数”→users.count）；
    - 问题→SQL示例对（如“用户问‘2023年销售额’，对应SQL：SELECT SUM(amount) FROM orders WHERE year=2023”）。
  2. 向量检索增强：将问题和示例对向量化存ChromaDB，用户提问时召回Top3相似示例，辅助生成SQL。
  3. 安全校验：
    - 只读账号：仅允许查询，禁止DML/DDL操作；
    - 白名单：仅允许访问指定表（如“销售表”“用户表”）；
    - 注入检测：过滤;等危险字符，强制LIMIT 1000防止数据泄露。
  4. 执行自校正：若SQL执行报错（如语法错误），回喂模型重写（最多3次），成功后返回结果。

场景6总结

  • 融合技术：RAG（知识检索）+ 向量库（存储示例）+ 关系型数据库（执行）+ 安全工程（权限/注入防护）
  • 典型项目：企业BI自助取数工具（如“EAST5数仓”的NL2SQL模块）

场景7 · 高并发AI服务工程化：让系统稳定支撑百万级用户

核心目标

大模型服务面临“高并发、低延迟、低成本”的挑战，需通过异步化、批处理、缓存等工程手段保障系统稳定。

1. 高并发工程策略

  1. 异步全链路：FastAPI异步框架（async/await），大模型调用和向量检索非阻塞，用户等待时间缩短50%。
  2. 批处理减压：对话累计200条后批量异步写MySQL（用BackgroundTasks），避免频繁IO。
  3. 流式响应：SSE（Server-Sent Events）流式输出，用户看到“正在输入...”的实时反馈，感知延迟降低30%。
  4. 任务队列化：长任务（如“生成50页报告”）丢入Celery+Redis队列，返回task_id异步执行，避免用户等待超时。
  5. 多级缓存：
    - Redis短期记忆：缓存高频问题答案（如“退款流程”）；
    - 语义缓存：用向量相似度匹配相似问题的回答，减少重复计算。
  6. 成本控制：
    - 滑动窗口：长文本自动截断为摘要；
    - 提示词缓存：重复问题的Prompt复用，节省token。
  7. 监控告警：Graylog日志聚合，Token消耗/响应时间/错误率实时监控，支持服务降级（如高负载时切换小模型）。

场景7总结

  • 融合技术：异步框架（FastAPI）+ 消息队列（Celery）+ 缓存（Redis）+ 流式（SSE）+ 监控（Graylog）
  • 典型项目：高并发智能助手（如“商学AI”的多用户同时提问场景）

场景8 · 数仓ETL全链路：RAG数据管道的“基建支撑”

核心目标

企业数据往往分散在MySQL/Oracle等数据库中，需通过ETL工具构建“数据仓库→向量库→大模型”的完整管道，为RAG和NL2SQL提供高质量数据。

1. ETL流程与分层设计

  1. 数据接入：MySQL/Oracle等源数据→Shell脚本ETL（提取、转换、加载）。
  2. 调度与分层：
    - 调度：XXL-Job定时任务，按日/周执行；
    - 分层：ODS（原始数据）→ CDM（中间层，清洗后）→ RPT（报表层，聚合后）。
  3. 存储优化：ClickHouse存储高频查询数据（如“近1年销售数据”），ReplacingMergeTree引擎实现增量去重（避免重复数据）。
  4. 质量校验：空值检查（如“订单表不能有空的用户ID”）、格式校验（如“日期必须为YYYY-MM-DD”）、统计校验（如“销售额总和=各产品销售额之和”）。
  5. 数据报送：自动压缩传输至目标库，支持增量同步（仅传变化数据）。

场景8总结

  • 融合技术：数据库（MySQL/Oracle）+ 调度工具（XXL-Job）+ 列式存储（ClickHouse）+ 数据校验
  • 典型项目：企业数据中台（如“EAST5数仓”）

场景9 · 推荐系统三层链路：大模型与推荐的技术同构

核心目标

推荐系统的“召回→精排→重排”三层链路，与RAG/Agent的检索链路高度同构，可借鉴其设计思路优化大模型应用的“内容分发”能力。

1. 推荐系统与大模型的技术映射

推荐系统环节 大模型应用对应环节 技术细节
召回（粗筛） 向量检索 双塔模型（DSSM/YouTubeDNN）+ ANN/HNSW检索（如Weaviate的近似最近邻）
精排（细排） Cross-Encoder重排 特征交叉（FM/DeepFM）+ 注意力机制（DIN），对候选内容打分排序
重排（业务调整） 后处理 MMR（平衡相关性与多样性）、DPP（行列式度量）

场景9总结

  • 融合技术：双塔模型（召回）+ 注意力机制（精排）+ 多样性优化（重排）
  • 典型项目：个性化知识推荐（如“企业知识库的热门文档推荐”）

小结

本文通过9个场景，覆盖了大模型混合技术应用的核心方向：
- RAG 解决“知识检索”问题，通过生产端建库、消费端检索实现闭环；
- Agent 解决“对话记忆”问题，通过短期/长期记忆、意图路由实现动态协作；
- 多模态与工具链 解决“复杂任务处理”问题，通过子Agent分工、Function Calling调用工具实现能力扩展；
- 工程化部署 解决“系统稳定性”问题，通过异步化、缓存、监控保障服务质量。

这些技术的核心是“场景化组合”：没有放之四海而皆准的方案，但每个场景都可复用“RAG+向量库+大模型+工具链”的底层逻辑，结合业务需求灵活调整。掌握这些技术后，你将能快速落地企业级大模型应用，从“技术选型”到“工程化落地”全流程打通。

#综合应用#架构设计
峰

作者

峰
↗

继续阅读

全部归档
OpenClaw 自托管 Agent 网关
OpenClaw 自托管 Agent 网关

OpenClaw是一个自托管开源AI助手网关，将飞书、钉钉、微信等聊天软件统一接入本地LLM Agent，实现多渠道统一接入、自托管安全可控。其核心三层架构（Channel/Brain/Body）实现关注点分离：Gateway层负责消息路由与鉴权，从不调用模型；Brain层负责指令解析、人格定义和LLM推理，支持Claude/GPT等模型无缝切换；Body层提供工具调用（如天气、日程）和文件操作。消息处理遵循七阶段Agentic循环（归一化、路由、上下文组装、LLM推理、ReAct工具循环、技能加载、持久化记忆）。记忆采用Markdown+YAML文件存储，支持人工编辑和Git备份，通过检索式访问避免上下文窗口爆炸。自动化任务支持Heartbeat心跳、Cron定时和Webhook事件触发。安全设计三道权限闸：入口闸（本地连接与配对码）、工具闸（默认拒绝白名单）、执行闸（Docker沙箱隔离）。实践踩坑提示包括记忆选择性遗忘、技能依赖耦合、Cron时区问题及Docker权限控制。核心优势：透明可控、安全隔离、灵活扩展。
Claude Code 原理与优化
Claude Code 原理与优化

Claude Code 的核心是单线程 while 主循环（ReAct 模式），通过工具调用触发循环，纯文本回复终止；支持实时打断（h2A 双缓冲队列）。为应对上下文窗口限制，设计五层压缩流水线（从丢弃旧消息到语义压缩），并强调状态外化到文件（如 CLAUDE.md）避免依赖内存。持久记忆由跨会话的 CLAUDE.md 和会话级扁平消息历史构成。四大扩展机制（MCP、Skills、Plugins、Hooks）与子代理（仅返回摘要）实现可控扩展。成本优化需分级选模型、主动压缩（/compact）、回退隔离及切换镜像。Agent SDK 复用核心 harness 加速开发。掌握工具触发循环、压缩策略和状态外化，可构建可控、可调试的生产级 AI 代理系统。
Vanna 与 NL2SQL
Vanna 与 NL2SQL

Vanna 是一个基于 RAG 的开源 NL2SQL 框架，不微调模型，而是通过向量化存储 DDL、业务文档和示例 SQL 对，在用户提问时检索相关上下文，由 LLM 生成 SQL 并执行，支持安全校验和自校正。其核心优势在于低成本、可增量更新、可解释且框架无关（支持多种 LLM、向量库和数据库）。训练阶段仅需向量化语料，提问阶段自动完成检索、生成、执行和结果可视化。针对 Schema Linking、业务口径歧义、SQL 方言差异和安全风险等难点，Vanna 提供两级检索、业务文档定义、方言指定和三层安全防御等方案。评估应使用执行结果准确率而非文本匹配。Vanna 2.0 转向 Agent 化架构，支持多轮交互、用户权限和流式富 UI。读者可快速落地低成本、可扩展的文本转 SQL 方案，连接业务人员与数据库。

评论