rag-pipeline

Bright Data — RAG / 搜索引擎流水线

将 Discover 用作 LLM 应用或自定义搜索引擎的检索层。 Discover 已经返回按意图排序并经过相关性评分的结果，其中包含解析后的页面 content，因此它会替你完成 RAG 中的“搜索 + 获取 + 清理”阶段。这是一项基于 discover-api 技能的代码/架构技能 — API 的具体机制（触发/轮询、模式、参数、限制）请参阅该技能。

选择合适的相邻技能：书面简报 → live-research；已有特定 URL 的 Markdown 内容 → scrape；结构化的平台记录 → data-feeds。

两种架构 — 先做选择

Does the corpus change every query, or is it a stable knowledge base?

  ├── Per-query, always-fresh ("ground each answer in live web data")
  │     → LIVE RETRIEVAL: Discover(include_content) at query time → top-k → LLM
  │       Pros: always current, no storage. Cons: per-query latency + cost.
  │
  └── Reused across many queries ("build a knowledge base / search engine")
        → INGESTION: Discover(include_content) → chunk → embed → vector store
          then at query time: embed query → vector search → (rerank) → LLM
          Pros: fast queries, cacheable. Cons: can go stale (re-ingest on a schedule).

许多系统会同时采用两者：用于覆盖广度的已摄取知识库 + 用于保证新鲜度的实时 Discover 调用，并在传给 LLM 前合并结果。

实时检索（基于 Web 的回答）

模式：每次收到用户问题时，都用明确的 intent 运行 Discover，取 relevance_score 最高的前 k 个结果，并将其 content 作为上下文传给 LLM。LLM 引用这些结果的 link。

import { bdclient } from '@brightdata/sdk';
const client = new bdclient(); // BRIGHTDATA_API_TOKEN

async function retrieve(question, k = 6) {
  const res = await client.discover(question, {
    intent: `authoritative sources that directly answer: ${question}`,
    includeContent: true,
    numResults: Math.min(k * 2, 20),  // over-fetch, then trim
  });
  // NOTE: the JS SDK returns a WRAPPER object, not a bare array:
  //   { success, data: [ {link,title,description,relevance_score,content?} ], totalResults, cost, taskId, ... }
  // The result rows are in `.data` (CLI/REST use `.results` instead — see discover-api).
  if (!res.success) throw new Error(`discover failed: ${res.error ?? 'unknown'}`);
  return (res.data ?? [])
    .filter(r => r.content && !/just a moment|captcha|access denied|not found/i.test(r.content) && r.content.length > 200)
    .sort((a, b) => b.relevance_score - a.relevance_score)
    .slice(0, k);
}
// → build a prompt from sources[].content, ask the LLM to answer WITH [n] citations to sources[].link

完整的提示词组装和引用模式见：references/code.md。

摄取（构建向量知识库/搜索引擎）

模式：广泛发现内容（高吞吐量 — 通过 REST 使用 zeroRanking 是理想选择），对每个页面的 content 分块，将这些块转换为向量，并以来源 URL 作为元数据写入向量存储。查询时：将查询转换为向量，执行向量搜索，可选择重新排序，然后将结果传给 LLM。

阶段：发现 → 去重 → 分块 → 转换为向量 → 写入（摄取），然后是 查询转向量 → 搜索 → 重新排序 → 生成（服务）。references/code.md 中提供了适用于两个阶段的服务商无关代码，包括分块和元数据处理。

批量构建语料库时，优先使用 discover-api 技能中的原始 REST "mode":"zeroRanking" 流程（原始结果数量最多，且不排序）— 但请注意，该模式会忽略 num_results，且不支持 include_content，因此需要单独获取内容（使用带内容的 Discover standard/deep，或 scrape 技能）。

设计规则

• 保存来源信息。 每个块都要保留来源 link（最好也保存标题和 relevance_score）。没有引用的 RAG 无法验证。
• 根据模型而非页面来分块。 每块约 500–1500 个 token，并设置重叠；按标题/段落分割，不要在句子中间切分。
• 在转换为向量前验证 content。 跳过拦截页面和空内容（过大的 PDF 会返回 null 内容）。无效内容会污染检索结果。
• 先多获取，再按 relevance_score 精简。 在重新排序之前（或取代重新排序），Discover 的评分是筛选前 k 个结果的重要依据。
• 如果新鲜度很重要，请定期重新摄取 — Web 内容会变化。已摄取的知识库会过时；实时检索则不会。
• 限制数量并去重。 每次调用的 num_results ≤ 20；跨调用按规范化后的 URL 去重，避免同一篇文章经由三个聚合站出现而被重复加权。
• 让嵌入模型/向量存储保持可插拔。 Discover 是检索来源；嵌入模型和向量数据库由你选择 — 不要将其写死。

验证关卡

1. 对已知测试查询，检索结果应包含非空且切题的内容块（人工检查前 k 个结果的链接）。
2. 索引中没有拦截页面或空的 content — 抽查已存储的内容块。
3. 引用可解析 — LLM 输出的每个 [n] 都能映射到检索结果集中的真实来源 link。
4. 确保新鲜度 — 如果应用承诺提供当前数据，请确认使用了实时检索（或近期重新摄取），而非过时索引。
5. 检查回答依据 — 回答应由检索到的内容支持，而非依赖模型已有知识；使用答案只存在于某个检索页面中的问题进行测试。

危险信号

• 用户需要最新答案时却构建摄取流水线（应使用实时检索），或在缓存索引足以满足需求时反复实时调用 Discover。
• 未过滤屏蔽页面／空值就嵌入 content。
• 丢弃来源 URL——未存储的内容无法引用或刷新。
• 将 num_results 当作没有上限（上限为 20），或期望在 zeroRanking 下使用 include_content。
• 让大模型根据训练数据作答——强制要求“仅根据提供的来源作答；如果没有相关信息，请明确说明。”
• 每个页面只切分为一个大块（会降低检索精度），或在句子中间切分。

参考资料

• references/code.md — 两种架构均提供可运行的 JS + Python 示例：通过提示词和引用组装实现实时检索，以及完整的摄取流水线（发现 → 去重 → 切分 → 嵌入 → upsert → 查询），并提供与供应商无关的嵌入器／向量存储接口。

相关技能

• discover-api — 检索 API（触发／轮询、模式、include_content、限制）。请先阅读。
• live-research — 生成一次性综合报告，而非构建常驻系统。
• scrape — 获取你已有的特定 URL 对应的 Markdown。
• js-sdk-best-practices / python-sdk-best-practices — client.discover() 选项详情和批处理模式。