AI PLAY玩法更新持续收录
← 回到更新流

2026-10-03 · 原文发布日

n8n模板:爬取批次入库前先做时效性把关

免费n8n模板:在把爬取的文档批次送入RAG入库前,手动触发一次时效检查。流程先构造或接收含抓取时间等元数据的批次,校验格式后只把记录ID、时间戳和来源发给Apify的Dataset Recency & Evidence Gate Actor评估,再核对报告的通过判定。通过的批次逐条放行给下游入库节点并带上门禁记录ID;不通过的整批拦截,输出报告摘要和每条记录的结果,便于排查过期数据。

原文要点

这是作者Saim发布的免费n8n模板:手动触发后,构造或接收一个含抓取时间等元数据的爬取批次(如crawl.loadedTime),先校验批次结构,再只把记录ID、观测时间戳和来源引用发给Apify的"Dataset Recency & Evidence Gate"Actor评估;随后核对HTTP响应与报告中的策略设置、记录对齐和整批通过/拦截判定;通过则逐条放行原始文档给下游入库并附门禁记录ID,不通过则整批拦截并输出报告摘要与逐条结果。需在Apify订阅该Actor并生成API token,以HTTP Header Auth(Authorization: Bearer)方式调用。

这次做成什么

在爬取数据入RAG库之前加一道时效闸门:整批过检才放行,过期记录整批拦截并给出逐条诊断。本站练习方案:用模板自带的演示批次生成器替换为本站合成批次(3条记录,其中1条过期),手动触发走通通过与拦截两种结果,再考虑接下游入库节点。

准备什么

  • 一个n8n实例(自托管或云端)并已导入该模板
  • 一个Apify账号,已可使用"Dataset Recency & Evidence Gate"Actor并生成API token(Actor可能产生费用,以Apify页面为准)
  • 理解你的批次信封字段:as_of(判定基准时间)、max_age_seconds(最大允许时效)、dataset_id、offset及每条记录的crawl.loadedTime

具体怎么做

  1. 配置Apify凭据

    在n8n新建HTTP Header Auth凭据,Header名Authorization、值Bearer <你的Apify token>,在调用Actor的HTTP请求节点中选中它。token只放凭据里,不写进任何节点参数。

  2. 替换演示批次为合成批次

    把模板中的演示批次生成节点替换为你的真实批次信封:as_of填当前时间、max_age_seconds如86400、dataset_id、offset,以及items数组(每条含id与crawl.loadedTime)。可先用本站artifact中的合成数据。

  3. 手动触发并观察结构校验

    点Execute Workflow手动运行,确认批次通过schema校验后,发往Actor的输入只包含记录ID、时间戳和来源引用这三类字段,不含正文。

  4. 核对报告与分支

    检查HTTP响应状态与报告中的策略回显、记录对齐(发出的每条记录都有对应结果)和aggregate通过判定;通过分支应逐条输出原始文档并带gate记录ID,拦截分支输出报告摘要与逐条结果。

  5. 接入下游入库

    确认通过行为符合预期后,把你的RAG入库节点(向量库写入等)接到通过输出上;拦截输出接日志或通知,便于排查哪条记录过期。

可直接复制的材料

合成测试批次(本站独立编写)

本站虚构数据:以as_of为基准、上限24小时时,doc-c已过期约71小时,应导致整批拦截;字段名需与Actor实际输入约定核对。

{
  "as_of": "2026-10-03T09:00:00Z",
  "max_age_seconds": 86400,
  "dataset_id": "demo-crawl-001",
  "offset": 0,
  "items": [
    {"id": "doc-a", "source": "https://example.com/a", "crawl": {"loadedTime": "2026-10-02T20:00:00Z"}},
    {"id": "doc-b", "source": "https://example.com/b", "crawl": {"loadedTime": "2026-10-03T07:30:00Z"}},
    {"id": "doc-c", "source": "https://example.com/c", "crawl": {"loadedTime": "2026-09-30T10:00:00Z"}}
  ]
}

输入与输出示例

本站虚构演示,说明预期分支行为;实际判定逻辑以该Apify Actor为准,本站未运行。

输入

手动触发工作流,批次含doc-a(13小时前抓取)、doc-b(1.5小时前)、doc-c(约71小时前),max_age_seconds=86400。

对应输出

期望走向拦截分支:输出报告摘要显示aggregate判定为fail,逐条结果中doc-a、doc-b为pass,doc-c为fail(超过最大时效);无任何文档进入下游入库输出。若把doc-c的loadedTime改为2026-10-03T06:00:00Z后重跑,则三条全过,通过分支逐条输出三份文档并各带一个gate记录ID。

做完检查这些

  • 发往Actor的输入中只有记录ID、时间戳、来源引用,不含文档正文
  • 过期记录存在时整批被拦截,且逐条结果能指出是哪条记录过期
  • 全部记录合格时通过分支逐条输出文档且每条带gate记录ID
  • HTTP非200或报告记录数与发出数不一致时不会误判放行

容易卡住的地方

  • 该Actor是第三方Apify服务,需自行订阅且可能计费,模板本身免费不代表Actor免费
  • 拦截是整批语义:一条过期会挡住整批,需靠逐条结果定位问题记录后重跑
  • as_of与max_age_seconds的时区和单位填错会让全部记录误判过期
  • 下游入库节点模板未附带,需自行接入到通过输出

原文与作者资料 ↗

本站借助AI整理来源事实,独立编写中文操作指南与示例。示例不代表实际运行结果;来源效果尚未由本站独立复现。付费模板与模型、服务费用分别计算。

原文标题
Gate saved crawl batches before RAG ingestion with Apify Recency Actor
原作者
Saim
原始发布日期
2026-10-03T05:42:08.500Z
来源
https://n8n.io/workflows/20375