方案一：低代码组件智能匹配型 RAG（Component-Centric RAG）
典型场景
- 低代码 / 无代码平台（amis、私有 UI 库、Illacloud、Formily、低代码 SaaS 等）
- 将自然语言需求直接转化为可渲染、可落地的页面 / 表单 / 流程 / 报表配置
- 平台已沉淀大量真实使用案例与结构化组件文档
核心思路
需求理解先行 → 明确“该用什么组件 + 为什么” → 用「组件名 + 选择理由」作为高质量查询 → 在组件维度做精准案例检索 → 强化 Agent 上下文，避免自由生成失控
使用流程
-
用户输入自然语言需求
示例：
“做一个支持多条件搜索、分页、批量导出、行内编辑和状态切换的后台用户管理列表” -
AI 输出结构化组件规划（强约束）
- 组件列表（如：crud、search-box、pagination、action-export-excel、operation-column）
- 每个组件的功能性 + 交互性 + 数据规模选择理由
-
构造组件级精准检索 Query
单组件单查询（必要时少量合并）：组件：CRUD 选择理由：数据量较大，需要支持多条件搜索、分页浏览、批量导出 Excel， 同时要求行内编辑与状态快速切换，减少跳页成本 -
在“组件使用案例库”中做向量检索
知识库组织（以组件为最小原子，里面有很多不同的api使用案例）：- 一个组件 = 一个主文档
- 文档内容包含：
- 使用说明文档
- 可直接复用的 JSON 配置片段（或者完整的代码）
检索策略：
- 每个组件召回 Top2
- 默认 Top1 进入生成上下文，Top2 作为备选参考
-
最终生成输入（强上下文约束）
- 原始用户需求
- 组件清单 + 选择理由
- 每个组件的最佳实践 JSON（必要时拼装）
方案二：迭代精炼式 Chunk Selection RAG
典型场景
- 中长文档（10–60 页 PDF / Word / 技术规范 / 法规 / 合同 / 审计报告 经典案例）
- 对事实准确性、上下文完整性要求极高
- 法律合规、风控审计、关键条款定位、核心结论抽取
核心思想
不追求“一次召回命中”，而是通过多轮 AI 判断，持续缩小上下文范围，
把整篇文档压缩到唯一且干净的事实片段
使用流程
-
初始切割
- 450–550 tokens / chunk
- 轻微 overlap
- 得到 20–40 个粗粒度块
-
第一轮粗选（全局扫描）
- LLM 对所有 chunk 打分
- 评分维度：相关性 / 信息密度 / 噪声
- 保留 Top 3–5 个候选块
-
第二轮中选（局部聚焦）
- 将候选 chunk 再切为 250–300 tokens
- 再次打分
- 选出 Top 1–2（可附带原大块作为背景）
-
第三轮精选（事实级压缩）
- 切至 80–120 tokens
- Prompt 强制约束：
“只保留直接回答问题的客观事实，删除解释性、铺垫性内容” - 输出唯一最佳片段（或极少数备选）
-
最终上下文拼装（总控）
- 核心事实片段（100–120 tokens）
- 前后各 1 个相邻片段（防断句）
- 章节标题 / 条款编号 / 页码
方案三：多查询重写 + 融合重排型 RAG（Multi-Query Fusion RAG）
典型场景
- 知识库规模中到大（几十～几千篇文档）
- 用户问题模糊、多意图、非标准表达
- 需要在召回率与精度之间稳定平衡的通用问答系统
- 企业内部知识库 / 技术文档 / 售后支持 / 运营 FAQ
核心思想
不要相信用户的“第一句话”。
通过多视角问题变体扩大召回面，再用强重排模型压回精度。
使用流程
-
查询扩展 / 重写（1 → 6–12）
组合使用以下 3–4 种即可：- 同义 / 口语化改写
- 用户视角 vs 专家视角
- Step-back 抽象问题
- 子问题拆分
- HyDE（假想答案反推查询）
-
多路并行检索
- 每个变体独立向量或 Hybrid 检索
- 每路 Top5–10
-
融合与重排
- 融合：RRF / MMR / 加权合并
- 重排：高质量 cross-encoder
（bge-reranker-v2 / Cohere Rerank / mxbai-rerank-large） - 输出 Top4–8 高置信 chunk
-
可选后处理
- LLM 上下文压缩
- 相似内容去重
- 原始问题作为引导前缀注入
