Repository navigation
Add keyless Parallel search for OfficeQA rollouts - #324
George Pickett (georgeatparallel) wants to merge 3 commits into
Conversation
|
Reviewed The current default change is a separate blocker: a fresh auto configuration on openai_chat or qwen_chat selects Parallel and sends the complete task question as objective, in addition to generated queries, without an explicit provider choice. Please retain the offline default and make Parallel an explicit selection with that data boundary documented. Also separate or justify the core MCP dependency and unconditional OfficeQA import so the optional capability does not unnecessarily determine offline installation behavior. The supplied official documentation describes an anonymous lower-rate free tier, not unlimited search. Parallel evidence is not directly comparable to the paper's Google-backed setting. Your affiliation disclosure is acknowledged; this scope decision is based on default behavior and data flow, not affiliation or an unmeasured performance claim. The present head is not recommended for merge as-is. |
Addresses review feedback on the default selection and the core dependency. Restore the offline default: configs/officeqa/default.yaml and OfficeQAAdapter are byte-identical to main again, and rollout no longer resolves an `auto` mode. `auto` (like any unrecognized value) normalizes to `offline`, so a fresh configuration behaves exactly as it does on main. Parallel is reached only through an explicit `env.search_mode=parallel`. Move `mcp` out of core dependencies into a `parallel` extra and import the Parallel client lazily, so OfficeQA imports and offline installs no longer require it. Selecting the mode without the extra raises an error naming `pip install 'skillopt[parallel]'`. CI installs `.[dev,parallel]` so the provider stays covered. Document the data boundary in docs/reference/config.md and the changelog: selecting this mode sends the generated queries and the full task question (as the MCP `objective`) to Parallel's hosted endpoint. Describe the keyless tier as an anonymous, lower-rate free tier rather than unlimited search, and keep the note that this evidence is not directly comparable to the paper's Google-backed setting. Tests cover that a fresh `auto` config does not select Parallel, that explicit selection does, that the OfficeQA env imports with `mcp` absent, and that selecting Parallel without the extra reports the install command. MCP transport tests skip when the extra is not installed. Co-authored-by: George Pickett <georgeatparallel@users.noreply.github.com>
3b90b41 to
83fff2a
Compare
|
Thanks for the thorough review, Yifan Yang (@Yif-Yang). I pushed 83fff2a to address it. The offline default is back: The config reference and changelog now spell out the data boundary (generated queries plus the full task question go to Parallel's hosted endpoint), describe the keyless tier as an anonymous lower-rate free tier, and keep the note that it isn't directly comparable to the paper's Google-backed setup. New tests cover each of those cases. |
This branch has not been deployed
3 participants
Run OfficeQA web-research rollouts with Parallel Search MCP, powered by Fast mode, without an account, API key, or access to the internal custom-search service. Fresh
autoconfigs use Parallel foropenai_chatandqwen_chatwhen no custom service is configured; saved configs can selectenv.search_mode=parallel.Explicit offline, Azure, and custom-service settings remain authoritative. Exec harnesses retain their tool permissions. Parallel uses different evidence from the paper's Google-backed search setting, so results are not directly comparable.
I work at Parallel.