Skip to content

add use_web_search argument to merge#77

Merged
straeter merged 3 commits into
mainfrom
use_web_search_arg_for_merge
Jan 30, 2026
Merged

add use_web_search argument to merge#77
straeter merged 3 commits into
mainfrom
use_web_search_arg_for_merge

Conversation

@straeter
Copy link
Copy Markdown
Contributor

add use_web_search argument to merge

Values:

"auto" or None -> use web search if needed (default)
"yes" -> force web search for every row
"no" -> skip web search entirely

@straeter straeter requested a review from jackwildman January 29, 2026 00:12
Comment thread src/everyrow/generated/models/merge_operation.py Outdated
Copy link
Copy Markdown
Contributor

@jackwildman jackwildman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we were planning to put this all behind the abstract "effort level". Do you think this needs to be explicitly controlled beyond that? Happy to go ahead with whatever you think is best here, regardless

Comment thread everyrow-mcp/src/everyrow_mcp/server.py Outdated
Comment on lines +357 to +360
use_web_search: str | None = Field(
default=None,
description='Optional. Control web search behavior: "auto" tries LLM merge first then conditionally searches, "no" skips web search entirely, "yes" forces web search on every row. Defaults to "auto" if not provided.',
)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: We could more strictly type this by one of the following:

  • Literal["yes", "no", "auto"] | None
  • bool | None
    I think I'd go for bool | None here, as I don't think it'd be too surprising for the default on unset to be "do as you please" and an explicit bool setting covering forcing it to either do or not do the thing.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tbh I always assume that setting a bool | None flag to None means that it corresponds to the "more default-y looking" value of the bool setting, i.e. None either means true or false, not some other, third option.

Copy link
Copy Markdown
Contributor Author

@straeter straeter Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree to @petermuehlbacher this should not be a bool when it has 3 qualitatively different options. But I can make it a Literal

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair. Literal is fine then

@straeter
Copy link
Copy Markdown
Contributor Author

I thought we were planning to put this all behind the abstract "effort level". Do you think this needs to be explicitly controlled beyond that? Happy to go ahead with whatever you think is best here, regardless

yes I deliberately kept it separate from the effort level. Forcing web search or not really depends on the kind of data (so there are cases where more internet search would not help but using a stronger LLM would). For merge, the higher effort level should correspond to a better model + more reasoning

@petermuehlbacher
Copy link
Copy Markdown
Contributor

I thought we were planning to put this all behind the abstract "effort level". Do you think this needs to be explicitly controlled beyond that? Happy to go ahead with whatever you think is best here, regardless

yes I deliberately kept it separate from the effort level. Forcing web search or not really depends on the kind of data (so there are cases where more internet search would not help but using a stronger LLM would). For merge, the higher effort level should correspond to a better model + more reasoning

I thought effort level only regulated the number of iterations and the system prompt. Does it also switch the model used now?

@straeter
Copy link
Copy Markdown
Contributor Author

I thought we were planning to put this all behind the abstract "effort level". Do you think this needs to be explicitly controlled beyond that? Happy to go ahead with whatever you think is best here, regardless

yes I deliberately kept it separate from the effort level. Forcing web search or not really depends on the kind of data (so there are cases where more internet search would not help but using a stronger LLM would). For merge, the higher effort level should correspond to a better model + more reasoning

I thought effort level only regulated the number of iterations and the system prompt. Does it also switch the model used now?

https://futuresearch-ai.slack.com/archives/C06CN3KM98V/p1769612413034259 ---> I think we have not fully agreed on this (especially for the utilities) but when it comes to the merge LLM, using a model with more reasoning effort makes a biiig difference in accuracy for hard problems but is definitely overkill for a lot of simple ones

@straeter straeter merged commit d48f801 into main Jan 30, 2026
3 checks passed
@straeter straeter deleted the use_web_search_arg_for_merge branch January 30, 2026 01:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants