Add concurrency and fast-stop to generate_answers#291
Conversation
Runs generate_answer() over search results concurrently (bounded by AnswerGeneratorSettings.concurrency) and, when fast_stop is enabled, skips results that haven't started once another has already produced a good answer. Mirrors answerGenerator.ts's concurrency/fastStop behavior for the array-of-search-results case. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds configurable concurrency and “fast stop” behavior to generate_answers() so multiple generate_answer() calls can run concurrently (bounded), and optionally stop starting new work once a good answer is found—aligning with the described TypeScript behavior. Tests are added to validate the concurrency cap and fast-stop skipping semantics.
Changes:
- Introduced
AnswerGeneratorSettingsand a concurrent implementation path forgenerate_answers(). - Implemented
_generate_answers_concurrently()using anasyncio.Semaphoreplus anasyncio.Eventto support fast-stop. - Added async tests covering concurrency limiting and fast-stop vs non-fast-stop behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/typeagent/knowpro/answers.py |
Adds settings + concurrent/fast-stop execution for answer generation. |
tests/test_answers.py |
Adds tests validating concurrency limiting and fast-stop behavior. |
robgruen
left a comment
There was a problem hiding this comment.
Can we address the two copilot comments? I think this is the preferred behavior and if it differs from what's in the TS implementation I'll update that to match.
Address PR microsoft#291 review feedback: AnswerGeneratorSettings previously defaulted to concurrency=2/fast_stop=True, silently changing behavior for existing callers that don't pass settings. Default to concurrency=1, fast_stop=False (matching the prior sequential, run-everything behavior), overridable via TYPEAGENT_ANSWER_CONCURRENCY and TYPEAGENT_ANSWER_FAST_STOP env vars or explicit settings. Also clarify the generate_answers() return-value comment now that fast_stop can return fewer answers than search_results. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Drop the bespoke _default_concurrency/_default_fast_stop helpers with try/except in favor of the plain os.getenv(NAME, default) style already used elsewhere in the codebase (e.g. outlook_dump.py). Document the new TYPEAGENT_ANSWER_CONCURRENCY / TYPEAGENT_ANSWER_FAST_STOP vars in .env-template alongside the other optional settings. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@robgruen thanks for your feedback. is fixed now |
robgruen
left a comment
There was a problem hiding this comment.
Looks good, thanks for this change/improvement!
Runs generate_answer() over search results concurrently (bounded by AnswerGeneratorSettings.concurrency) and, when fast_stop is enabled, skips results that haven't started once another has already produced a good answer. Mirrors answerGenerator.ts's concurrency/fastStop behavior for the array-of-search-results case.