Haystack 与 Parallel 集成指南构建带实时网络研究能力的 RAG 与 Web Search 组件【免费下载链接】haystackOpen-source AI orchestration framework for building context-engineered, production-ready LLM applications. Design modular pipelines and agent workflows with explicit control over retrieval, routing, memory, and generation. Built for scalable agents, RAG, multimodal applications, semantic search, and conversational systems.项目地址: https://gitcode.com/GitHub_Trending/ha/haystack本文以 Haystack 官方集成的 Parallel 适配文档为核心系统讲解ParallelChatGenerator基于 Parallel Responses API 的实时网络研究型对话生成器与ParallelWebSearch基于 Parallel Search API 的网络搜索组件的初始化参数、调用方式、序列化与生命周期管理。读完本文你将能在 Haystack 管道中集成带内置信引用grounded citations的联网问答能力以及支持会话上下文延续session_id的结构化网络搜索并理解其底层与 OpenAI Responses 兼容 API 的继承关系。集成总览Parallel 为 Haystack 提供什么Parallel 的集成包含两个互补的 Haystack 组件分别负责研究型对话生成与结构化网络搜索组件模块路径定位ParallelChatGeneratorhaystack_integrations.components.generators.parallel调用 Parallel Responses API完成带实时网络研究的对话补全ParallelWebSearchhaystack_integrations.components.websearch.parallel调用 Parallel Search API把搜索结果包装为 HaystackDocument从 平台组件总览 可以看到Haystack 官方将其列为 Generator 与 Component 两类组件均可直接用于管道编排。两者均需要 parallel.ai 提供的 API Key默认从PARALLEL_API_KEY环境变量读取。ParallelChatGenerator基于实时网络研究的对话生成继承关系与 API 兼容性ParallelChatGenerator直接继承自 Haystack 核心的OpenAIResponsesChatGenerator源码见 openai_responses.py这意味着它在消息格式、流式回调、重试与超时机制上完全复用 OpenAI Responses 客户端的既有实现只是将请求指向 Parallel 的 Responses 端点端点POST /v1/responses与 OpenAI Responses API 兼容默认模型parallelSUPPORTED_MODELS [parallel]即 Parallel 的 Web Research 模型输入输出格式统一使用 Haystack 的ChatMessage数据类见 chat_message.py可直接与其他使用ChatMessage的组件、Agent 串联。研究等级reasoning.effort延迟与质量的取舍与普通 LLM 生成器不同Parallel 的模型在返回答案前会执行真实网络检索回答质量取决于研究深度。通过generation_kwargs中的reasoning.effort参数选择研究等级等级耗时说明low约 5–10 秒快速研究适合对时效性要求不高的问题medium约 15–20 秒默认等级研究与响应速度的平衡点high约 30–60 秒深度研究适合需要多源交叉验证的复杂问题文档特别强调内置 Web Grounding所以tools、temperature、top_p等采样参数虽被接受为保持 SDK 兼容但会被 API 静默忽略组件在检测到这些参数时会发出警告。这意味着 ParallelChatGenerator 不适合作为需要自定义工具调用的 Agent 主干它的定位是把联网研究 带引用的回答封装为一次原子调用。超时与重试的默认值设计由于单次调用需要运行真实研究文档对timeout与max_retries的默认值做了针对性调整timeout默认 120 秒而非从 OpenAI 客户端继承的 30 秒——目的是让high研究等级约 30–60 秒留出充足余量max_retries默认 3低于 OpenAI 客户端默认的 5——因为每次重试都会完整跑一遍研究调用成本高、耗时长需要保守设置。这两个默认值的底层逻辑可以追溯到 openai_responses.py 中OpenAIResponsesChatGenerator的实现当传入None时超时回退到OPENAI_TIMEOUT环境变量默认 30 秒最大重试回退到OPENAI_MAX_RETRIES环境变量默认 5。对于研究型调用30 秒默认超时明显偏短这正是 Parallel 组件把默认值提升到 120 秒的原因。初始化参数详解__init__( *, api_key: Secret Secret.from_env_var(PARALLEL_API_KEY), model: str parallel, api_base_url: str | None https://api.parallel.ai/v1, streaming_callback: StreamingCallbackT | None None, generation_kwargs: dict[str, Any] | None None, timeout: float | None 120.0, extra_headers: dict[str, Any] | None None, max_retries: int | None 3, http_client_kwargs: dict[str, Any] | None None ) - None参数类型默认值说明api_keySecretSecret.from_env_var(PARALLEL_API_KEY)Parallel API Key建议通过环境变量注入modelstrparallel使用的 Parallel Responses API 模型api_base_urlstr \| Nonehttps://api.parallel.ai/v1Parallel API 基础地址一般无需修改streaming_callbackStreamingCallbackT \| NoneNone流式输出时收到新 token 的回调函数generation_kwargsdict[str, Any] \| NoneNone直接透传给 Responses API 的附加参数如reasoning例{effort: low}选择研究等级或text做结构化输出timeoutfloat \| None120.0请求超时秒。传None回退到 OpenAI 客户端默认OPENAI_TIMEOUT或 30 秒对多数研究调用过短extra_headersdict[str, Any] \| NoneNone附加 HTTP 请求头max_retriesint \| None3内部错误后的最大重试次数保持较低因为每次重试都是一次完整研究调用。传None回退到 OpenAI 客户端默认OPENAI_MAX_RETRIES或 5http_client_kwargsdict[str, Any] \| NoneNone用于配置自定义httpx.Client/httpx.AsyncClient的关键字参数字典使用示例from haystack.dataclasses import ChatMessage from haystack_integrations.components.generators.parallel import ParallelChatGenerator messages [ChatMessage.from_user(What did Parallel Web Systems announce this year?)] client ParallelChatGenerator(generation_kwargs{reasoning: {effort: low}}) response client.run(messages) print(response)示例中通过generation_kwargs{reasoning: {effort: low}}将研究等级调至low适合演示或对响应速度敏感的场景生产环境可按问题复杂度在low/medium/high间选择。序列化to_dictto_dict() - dict[str, Any]ParallelChatGenerator继承了 Haystack 组件的标准序列化能力to_dict()返回可 JSON 序列化的字典包含组件类型、初始化参数API Key 以 Secret 引用形式安全序列化等完整信息。这使组件可以被Pipeline.dumps()/ YAML 编解码见 yaml.py持久化配合from_dict()从配置还原便于管道模板化与版本管理。ParallelWebSearch结构化网络搜索组件设计定位ParallelWebSearch包装 Parallel Search API把搜索结果转换为面向 LLM 优化的摘录excerpts输出为带内容与链接的结构化Document并返回**会话标识符session_id**用于串联相关搜索。它解决的是 RAG 场景中检索最新网络信息的最后一公里问题——搜索结果天然是 LLM 友好的摘要形态可直接喂给生成组件。基础用法与会话延续from haystack_integrations.components.websearch.parallel import ParallelWebSearch from haystack.utils import Secret websearch ParallelWebSearch( api_keySecret.from_env_var(PARALLEL_API_KEY), top_k5, ) result websearch.run(queryWhat is Haystack by deepset?) documents result[documents] links result[links] # Pass the session back on follow-up searches that are part of the same task # to get better contextual results. follow_up websearch.run( queryWho maintains Haystack?, search_params{session_id: result[session_id]}, )run()的返回字典包含三个键documents搜索结果摘录构成的Document列表links搜索结果中的 URL 列表session_id本次搜索的会话标识符。如果请求时在search_params[session_id]中传入了该值则原样回显否则由 API 服务端生成。把它传给同一任务后续搜索的search_params可以获得更好的上下文相关性——非常适合多轮调研型 Agent 使用。初始化参数详解__init__( *, api_key: Secret Secret.from_env_var(PARALLEL_API_KEY), top_k: int | None 10, search_params: dict[str, Any] | None None, timeout: float 30.0 ) - None参数类型默认值说明api_keySecretSecret.from_env_var(PARALLEL_API_KEY)Parallel API Keytop_kint \| None10最大返回结果数映射到 API 的advanced_settings.max_results参数search_paramsdict[str, Any] \| NoneNone透传给 Parallel Search API 的附加参数见下表timeoutfloat30.0请求超时秒search_params支持的键与 Parallel Search API 参考文档对应键说明objective自然语言描述的搜索目标默认取查询语句本身mode搜索模式turbo、fast、basic、advanced按此顺序延迟与质量递增API 默认advancedmax_chars_total结果总字符数上限session_id会话标识符把多次搜索串联为同一任务client_model客户端模型标识advanced_settings嵌套设置source_policy域名与日期过滤、fetch_policy、excerpt_settings、location、max_results等其中session_id无论是由调用方传入还是服务端生成都会始终在输出中回显这是实现多轮连续调研的关键机制。生命周期与异步支持ParallelWebSearch实现了完整的同步/异步生命周期方法便于在服务端场景如 FastAPI中管理与复用 HTTP 连接方法作用warm_up()初始化同步 HTTP 客户端。首次使用时自动调用也可显式调用避免冷启动延迟warm_up_async()在服务事件循环上初始化异步 HTTP 客户端同样自动或显式调用close()释放同步 HTTP 客户端close_async()释放异步 HTTP 客户端run(query, search_paramsNone)同步执行网络搜索返回documents/links/session_idrun_async(query, search_paramsNone)异步版本返回结构相同run与run_async中的search_params是按次调用的覆盖参数若提供则完全替换初始化时的search_params而非合并。这在多轮会话中很有用——例如首轮用默认配置搜索后续轮次仅传{session_id: ...}即可延续上下文。Haystack 管道运行时支持run_async的异步执行机制可参考核心 async_utils.py。将 Parallel 组件接入 Haystack 管道两个组件可以协同工作构成搜索 → 生成的实时研究管道。以ParallelWebSearch作为检索器、ParallelChatGenerator作为生成器的组合为例管道核心 API 见 pipelinefrom haystack import Pipeline from haystack_integrations.components.generators.parallel import ParallelChatGenerator from haystack_integrations.components.websearch.parallel import ParallelWebSearch websearch ParallelWebSearch(top_k5) generator ParallelChatGenerator(generation_kwargs{reasoning: {effort: medium}}) pipeline Pipeline() pipeline.add_component(websearch, websearch) pipeline.add_component(generator, generator) # 将搜索结果摘录作为提示上下文输入生成器 # 实际接线需结合 PromptBuilder 等组件完成文本拼装实践要点由于 ParallelChatGenerator 忽略工具调用参数推荐把它作为研究型单步生成器使用而非多工具 Agent 的执行节点在多轮调研任务中务必把上一轮返回的session_id传入下一轮search_params以获得上下文相关的结果对响应延迟敏感的场景优先reasoning.effortlowmodefast组合对报告级任务使用highadvanced并把timeout相应调大默认 120 秒已能覆盖high等级生产服务中显式调用warm_up_async()预热连接结束时调用close_async()释放资源。总结Parallel 集成以两个组件覆盖了实时联网研究这一 RAG 与 Agent 场景的关键能力ParallelChatGenerator继承 OpenAI Responses 客户端的成熟实现通过reasoning.effort三档研究等级在延迟与质量间取舍所有回答均基于实时网络研究并附引用ParallelWebSearch则输出 LLM 友好的结构化摘录与可回传的session_id天然适配多轮调研工作流。两者配合 Haystack 的管道编排与序列化机制即可在数行代码内构建具备实时事实核查能力的生产级应用。更详尽的版本化 API 参考可查阅 version-2.20 集成文档 与 最新版集成参考。【免费下载链接】haystackOpen-source AI orchestration framework for building context-engineered, production-ready LLM applications. Design modular pipelines and agent workflows with explicit control over retrieval, routing, memory, and generation. Built for scalable agents, RAG, multimodal applications, semantic search, and conversational systems.项目地址: https://gitcode.com/GitHub_Trending/ha/haystack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考