TL;DR
- 网页数据的新鲜度是您的产品提供的信息的年龄，而不仅仅是其最后爬取的时间戳。
- 每小时获取一次并不能保证每小时都有新鲜的答案；提取、验证、索引、缓存和检索每个步骤都会增加延迟。
- 定义特定来源的新鲜度目标。产品价格、可用性、文档和存档页面不需要相同的刷新间隔。
- 优先考虑变更感知的重新爬取和版本记录，而不是盲目地在定时器上替换整个语料库。
- Nstdata Crawl 可以通过其 API 重新获取和转换选定网页；您的应用程序必须调度刷新并测量端到端延迟。
数据新鲜度对网页数据产品意味着什么？
数据新鲜度意味着用户看到的信息与源的当前状态足够接近，以做出所需的决策。获取页面上的时间戳仅能证明何时发生了获取。如果解析器提取了旧的缓存元素、新记录在队列中等待，或检索索引仍然提供先前版本，则新获取对用户来说仍然可能是过时的。Nstdata Crawl 产品 是此处讨论的获取和转换步骤的管理选项。
免费尝试 Nstdata →
为记录定义三个时间戳：source_observed_at 代表页面被获取的时间，processed_at 代表验证后的记录生成时间，以及 served_at 或索引版本代表产品提供该信息的时间。源的实际更改时间通常是未知的。当源暴露出可靠的 Last-Modified 头或变更推送时，记录它，但不要假设它反映每个内容的变更。
RAG 刷新指南 显示源版本进入索引的位置。
为什么实时网页数据流仍然可能是过时的？
端到端路径包含多个延迟：调度、获取、渲染、解析、验证、排队、索引、缓存失效和答案生成。每分钟获取一次但每天仅索引一次的产品大致上有每天的新鲜度。立即索引但未能注意到更改的 URL 的产品也存在同样的问题。
测量 served_at - source_observed_at 作为管道延迟，now - source_observed_at 作为读取时的年龄。单独看这两者并不能证明源的实时性，因为页面在获取后可能发生了变化。对于高风险使用案例，比较样本与实时源并估计检测延迟。按源类别跟踪第 95 百分位，而不是在所有页面中取平均。
MDN 条件请求指南 解释了 ETag 和修改时间信号，对于那些暴露这些信号的源。
