ai-exchange/docs/AI_ICT_Sweep_Identification_Spec_v1.md

AI ICT Sweep 识别规格书 v1

1. 文档目标

本文档定义 AI ICT 项目第一阶段 MVP 的 sweep identification 规则，用于指导：

• sweep_events 识别模块开发
• liquidity pool 与 sweep 的交互判定
• wick / close 行为判断
• displacement、MSS、signal 等下游模块引用
• 本地验证、抽样复盘与后续回测

本文档只覆盖 sweep 的识别与状态维护，不覆盖 displacement、MSS、FVG 的完整规则实现。

关联文档：

1. AI_ICT_MVP_规则规格书_v1.md
2. AI_ICT_PostgreSQL_Schema_v1.md
3. AI_ICT_开发路线图_v1.md
4. AI_ICT_执行检查清单_v1.md
5. AI_ICT_Dealing_Range_Spec_v1.md

---

2. 设计目标

sweep 模块需要满足以下目标：

1. 只围绕结构化 liquidity pool 识别，不做自由解释
2. 能区分 wick-only 刺穿与 close-back-inside 的行为差异
3. 能对 sweep 做分层验证，而不是一刀切二元判断
4. 能与后续 displacement 事件建立明确链接
5. 能维护 sweep 的状态流转，避免同一 pool 被重复误判
6. 输出结构化、可回测、可审计

---

3. 核心定义

3.1 Liquidity Pool

sweep 的前提是存在已识别的 liquidity pool。

第一版 pool 来源：

• prior_high
• prior_low
• equal_highs
• equal_lows
• session_high
• session_low

每个 pool 至少有：

• side
• price_low
• price_high
• status
• timeframe

3.2 Sweep

sweep 是价格对某一侧 liquidity pool 的刺穿与清理行为。

第一版中，sweep 必须满足：

• 有明确目标 pool
• 价格对 pool 发生有效交互
• 交互后能够输出结构化结果

3.3 Side Swept

sweep.side_swept 表示被清理的是哪一侧流动性：

• buy_side：上方流动性被清理，通常对应扫高
• sell_side：下方流动性被清理，通常对应扫低

3.4 Wick Sweep

价格仅用 wick 刺穿 pool 区间，但收盘没有稳定站在区间外，可记为 wick sweep 候选。

3.5 Close Back Inside

价格刺穿 pool 后，最终收盘重新回到 pool 内侧或原结构区间内，记为 close_back_inside = true。

这通常是第一版更优先关注的 sweep 形态。

---

4. pool 交互规则

4.1 sweep 必须依赖 pool

第一版不允许没有 pool 就直接定义 sweep。

即：

• 先有 liquidity_pools
• 再判断 candles 是否与 pool 发生 sweep 交互

4.2 交互方向

扫 buy-side liquidity

若目标 pool 的 side = buy_side，则价格必须向上刺穿 pool：

• high 触及或突破 pool.price_low
• 并进一步进入或突破 pool.price_high

扫 sell-side liquidity

若目标 pool 的 side = sell_side，则价格必须向下刺穿 pool：

• low 触及或跌破 pool.price_high
• 并进一步进入或跌破 pool.price_low

4.3 第一版触发判定

为了兼容区间型 pool，第一版将“发生交互”定义为：

对 buy_side pool

候选 candle 满足：

• high >= pool.price_low
• 且至少有一部分价格行为进入或突破 pool.price_high

对 sell_side pool

候选 candle 满足：

• low <= pool.price_high
• 且至少有一部分价格行为进入或突破 pool.price_low

更简化地说：

• 上方池要被“扫进去/扫过去”
• 下方池要被“打进去/打过去”

4.4 pool 优先级

若同一 candle 同时与多个 pool 交互，第一版建议按如下优先级选择主 sweep 对象：

1. 时间更近的 pool
2. timeframe 更接近当前规则处理周期的 pool
3. equal_highs / equal_lows 优先于普通 prior_high / prior_low
4. session pool 在 session 相关策略中可优先
5. 若仍冲突，取离当前价格更近者

MVP 最小实现建议：

• 一根 candle 只认一个主 pool
• 其余命中记录到 meta.candidate_pool_ids

---

5. wick / close 行为规则

5.1 wick 刺穿

候选 candle 只要 wick 进入或越过目标 pool，即可形成 sweep 候选。

例如：

• 扫 buy-side：high 突破 pool 上沿
• 扫 sell-side：low 跌破 pool 下沿

5.2 close_back_inside

第一版更强的 sweep 条件是 close_back_inside = true。

对 buy_side pool

候选 candle 扫高后，收盘重新回到 pool 下方或回到结构内部，记为 close back inside。

对 sell_side pool

候选 candle 扫低后，收盘重新回到 pool 上方或回到结构内部，记为 close back inside。

5.3 close-outside 的处理

若价格刺穿 pool 后收盘仍留在外部：

• 可视为已发生 liquidity interaction
• 但第一版不优先定义为高质量 sweep
• 更可能属于延续突破，而不是清扫后回收

因此：

• wick sweep + close outside = 弱候选
• wick sweep + close back inside = 更强候选

5.4 多根 K 线确认

第一版 sweep 的发生时点以首根有效交互 candle 为准，不要求等待多根 K 线才能记录 sweep event。

但后续验证等级可以引用后续 1~N 根 candle 的行为。

---

6. 验证分层

6.1 设计原则

第一版不把所有 sweep 都视为同质量信号，而是分层：

• L1：弱 sweep
• L2：有效 sweep
• L3：强 sweep

6.2 L1 弱 sweep

满足：

• 与 pool 有明确 wick 交互
• 但未出现 close back inside
• 或缺少后续 displacement 支持

用途：

• 可记录
• 默认不直接作为入场依据

6.3 L2 有效 sweep

满足：

• 与 pool 发生明确刺穿
• close_back_inside = true
• pool 原始状态为 untouched
• 没有明显数据缺口或结构冲突

用途：

• 可进入后续 displacement / MSS 观察链路

6.4 L3 强 sweep

满足：

• 已满足 L2
• 在限定窗口内出现有效 displacement
• displacement 方向与 sweep 后预期反应一致
• 可形成后续 MSS / FVG 链路候选

用途：

• 可作为 SWEEP_MSS_FVG 模型的高质量前置条件

6.5 第一版最小实现建议

若系统复杂度有限，可先实现：

• weak
• valid

两层，然后把强 sweep 通过 displacement_after = true 额外标记。

---

7. displacement linkage 规则

7.1 sweep 与 displacement 的关系

sweep 本身只表示流动性被清理；是否具有更高质量，要看后续是否出现 displacement。

7.2 方向一致性

扫 buy-side 之后

若 sweep 清理的是上方 buy-side liquidity，则高质量后续反应通常是向下 displacement。

扫 sell-side 之后

若 sweep 清理的是下方 sell-side liquidity，则高质量后续反应通常是向上 displacement。

7.3 displacement 窗口

第一版建议在 sweep 之后的有限窗口内寻找 displacement：

• M1 / M5：后续 3~5 根 candle
• M15 / H1：后续 2~4 根 candle
• H4 及以上：后续 1~3 根 candle

若窗口内没有有效 displacement：

• sweep 仍可保留
• 但验证等级不升为强 sweep

7.4 链接方式

若 sweep 已匹配 displacement，则建议记录：

• displacement_after = true
• meta.displacement_event_id
• meta.displacement_delay_bars

若未来正式建 sweep_events 表，也建议保留显式 displacement_event_id 字段。

---

8. 状态流转规则

8.1 pool 状态

pool 原始状态：

• untouched
• swept
• consumed

8.2 sweep 对 pool 的影响

第一版建议：

• 识别到有效 sweep 后，目标 pool 更新为 swept
• 若后续结构继续完全消耗该区域，可进一步更新为 consumed

8.3 sweep 自身状态建议

若使用独立 sweep_events 存储，建议状态：

• candidate
• weak
• valid
• confirmed
• invalidated
• archived

含义

• candidate：仅发生初步 pool interaction
• weak：发生 wick sweep，但不够强
• valid：close back inside 成立
• confirmed：已获得 displacement 或后续链路确认
• invalidated：后续价格行为证明该 sweep 不再有参考意义
• archived：历史保留

8.4 最小状态机

MVP 第一版若要降复杂度，至少支持：

• weak
• valid
• confirmed

并允许：

weak -> valid -> confirmed
weak -> invalidated
valid -> invalidated
confirmed -> archived

8.5 防重规则

同一 pool 在未重置前，不应被重复生成多条同向主 sweep 事件。

第一版建议：

• 同一 pool_id + direction_window 只保留一条主 sweep
• 若后续出现更高质量版本，可更新状态或新增更高版本并归档旧记录

---

9. 边界与异常情况

9.1 只触及不刺穿

若价格只触碰 pool 边缘但没有进入区间，不记 sweep。

9.2 同时扫上下两侧

极端大波动 candle 可能同时扫到上下两侧 pool。

第一版处理：

• 不在同一根 candle 上同时生成两个主 sweep
• 标记为冲突场景
• meta.conflict = 'dual_side_sweep'
• 默认不作为高质量 sweep

9.3 已被 swept 的 pool

若 pool 已是 swept 状态，第一版默认不重复生成新的主 sweep。

除非：

• 明确发生新一轮结构重置
• 或 pool 被重新生成了新 id

9.4 数据缺口

若 sweep 发生窗口存在明显缺失 candle：

• 可记录 candidate
• 但不升级为高质量 sweep
• meta.data_gap = true

9.5 假突破与延续突破

若刺穿后持续单边离开 pool，且没有 close back inside：

• 更偏向 breakout / continuation
• 仍可记为弱 interaction
• 默认不视为有效 sweep

9.6 多个 timeframe 冲突

若低周期识别 sweep，但高周期叙事不支持：

• sweep 事件本身仍可记录
• 是否进入 signal 链路交给 bias / structure 层过滤

---

10. 存储模型

10.1 MVP 第一版建议

虽然当前 schema 文档未正式定义 sweep_events 表，但 sweep 属于核心信号层，建议新增独立存储模型，而不是只塞进 JSON。

建议新增 sweep_events 表，至少包含：

• instrument_id
• timeframe
• pool_id
• side_swept
• sweep_high
• sweep_low
• close_back_inside
• validation_tier
• status
• ts
• meta
• created_at
• updated_at

10.2 字段语义

• pool_id：被扫 liquidity pool
• side_swept：buy_side / sell_side
• sweep_high：本次 sweep 涉及的最高价格
• sweep_low：本次 sweep 涉及的最低价格
• close_back_inside：是否收回结构内部
• validation_tier：weak / valid / strong
• status：事件当前状态
• ts：首个成立 sweep 的 candle 时间

10.3 meta 建议内容

适合放入 meta：

• candidate_pool_ids
• pool_type
• close_outside
• displacement_event_id
• displacement_delay_bars
• data_gap
• conflict
• selection_reason
• recalc_batch_id

不应只放在 meta：

• pool_id
• side_swept
• close_back_inside
• validation_tier
• status
• ts

10.4 若暂不建独立表

若第一版暂时不能新增 sweep_events 表，可临时把 sweep 结果写入：

• trade_signals.evidence
• 或规则引擎中间结果存储

但这只应作为过渡方案，不应作为长期主方案。

---

11. 处理流程建议

11.1 基础识别流程

1. 读取当前 timeframe 的 active liquidity pools
2. 检查新 candle 是否与某个 pool 发生交互
3. 判断是否进入/突破 pool 区间
4. 记录 wick 行为与 close 行为
5. 生成 candidate / weak / valid sweep
6. 在后续窗口中检查 displacement
7. 更新 validation tier 与 status
8. 同步更新目标 pool 状态

11.2 最小 MVP 实现

建议先做：

1. pool interaction 判定
2. wick 与 close back inside 判定
3. weak / valid 两层验证
4. displacement_after 标记
5. pool 状态从 untouched 到 swept 的更新

再增强：

• 独立 sweep_events 表
• 更完整状态机
• 多 pool 冲突管理
• 与 MSS / FVG 的强绑定引用

---

12. 验证检查点

12.1 功能验证

• 能从已有 liquidity pool 中识别 sweep
• 同一批输入重复运行结果一致
• wick 行为与 close 行为能正确区分
• displacement linkage 可正确标记

12.2 规则验证

• 没有 pool 不会生成正式 sweep
• 只触碰不进入 pool 区间不会误判为 sweep
• close back inside 成立时会升级验证等级
• close outside 默认不会误判为高质量 sweep
• pool 已 swept 时不会重复生成主 sweep

12.3 状态验证

• sweep 生成后 pool 状态可更新为 swept
• 高质量 sweep 可升级为 confirmed
• 无效后续行为可把 sweep 标记为 invalidated
• 历史 sweep 可归档但不丢失

12.4 存储验证

• pool_id 能正确关联 liquidity pool
• side_swept 与 pool.side 逻辑一致
• validation_tier 与 status 可正确查询
• meta 能记录 displacement 和异常信息

12.5 人工抽样验证

每个核心 timeframe 至少抽查：

• 1 个扫 buy-side 的有效样例
• 1 个扫 sell-side 的有效样例
• 1 个 wick-only 弱 sweep 样例
• 1 个 close back inside 的有效 sweep 样例
• 1 个后续带 displacement 的强样例
• 1 个假突破但非有效 sweep 的反例

12.6 与路线图对齐的完成标准

满足以下条件才算完成：

• 能识别流动性刺穿
• 能识别 close back inside
• 能区分弱 sweep 与有效 sweep
• 可作为 displacement / MSS / signal 的上游输入

---

13. MVP 范围内不做的事

第一版暂不包含：

• 基于订单流或逐笔成交的微观 sweep 识别
• AI 自由叙事判定 sweep
• 多市场 SMT 联动 sweep 作为核心条件
• 同一事件跨多个 timeframe 自动合并
• 复杂置信度模型打分

---

14. 推荐的最小实现顺序

1. 先实现 pool interaction
2. 再实现 wick / close back inside 判定
3. 再实现 weak / valid 分层
4. 再实现 displacement_after 标记
5. 最后补 sweep 独立存储与完整状态机

这样可以先满足阶段 3 的最小可用目标，再逐步增强。