Почему dspy.context не меняет модель внутри стороннего Python-потока

Порядок действий

1. Настройте глобальную LM один раз при старте процесса.
2. Создайте другую LM с доступом к тому же или другому подтверждённому endpoint.
3. Выполните контрольный вызов с with dspy.context(lm=alternate) и проверьте settings.lm внутри блока.
4. После блока убедитесь, что глобальная модель восстановилась.
5. При использовании сторонних Python-потоков не предполагайте наследование override; передавайте настройки работникам явно либо пользуйтесь механизмом DSPy.

Для сетевого запуска установите пакет командой pip install dspy, подготовьте свой доступ к модели и задайте DSPY_MODEL в форме provider/model и DSPY_API_KEY в окружении. Исключение — код, который только проверяет локальные настройки без сетевого вызова. Шаблон ниже содержит вымышленные входные данные и не включает секретов; перед запуском сверьте, что выбранная вами модель подходит для задачи и разрешена правилами провайдера.

Готовый пример программы

import os
import dspy
global_lm = dspy.LM(os.environ["DSPY_MODEL"], api_key=os.environ["DSPY_API_KEY"])
alternate = dspy.LM(os.environ["DSPY_ALT_MODEL"], api_key=os.environ["DSPY_ALT_API_KEY"])
dspy.configure(lm=global_lm)
assert dspy.settings.lm is global_lm
with dspy.context(lm=alternate):
    assert dspy.settings.lm is alternate
    # Вызывайте здесь программу для контролируемого сравнения.
assert dspy.settings.lm is global_lm
print("Локальная подмена и восстановление проверены")

Вход и ожидаемый результат

Вход — два валидных клиента LM. Ожидаемый детерминированный результат кода — сообщение о локальной подмене и восстановлении без вызова провайдера. Затем задайте двум моделям один и тот же вымышленный вопрос в разных контекстах; сами ответы сравнивайте отдельно. Пример не доказывает, что bare ThreadPoolExecutor автоматически унаследует override: согласно документации, это не так.

Проверка качества, а не только запуска

В документации отдельно уточнено, что await и asyncio.create_task наследуют контекст ожидаемым образом, а обычный threading.Thread или голый ThreadPoolExecutor не получают override автоматически. Поэтому результаты запросов в worker-потоке могут неожиданно относиться к глобальной LM. Для своей очереди задач явно пронесите нужную конфигурацию и протестируйте её в worker; документация называет dspy.Parallel альтернативой с передачей контекста. Не пытайтесь перенастраивать configure одновременно из каждого потока: руководство описывает ограничение владельца настроек.

Контекст модели стоит тестировать с разными идентификаторами конфигурации, не делая дорогостоящих сетевых запросов. Зафиксируйте значение в основном потоке до входа в блок, внутри блока и после выхода: ожидается возврат исходного состояния. Затем создайте обычный поток и проверьте его независимо; не переносите туда ожидание, основанное на поведении асинхронной задачи. Если приложение передаёт работу в пул потоков, явно задавайте конфигурацию в каждой рабочей единице и отдельно проверяйте очистку после исключения. Такой тест выявляет утечки настроек между запросами клиентов. Не используйте один глобальный переключатель для разных пользователей одновременно, если изоляция конкретного способа запуска не проверена.

Особые случаи и границы

Параметры temperature, max_tokens, api_base и повторов живут у конкретного объекта dspy.LM, а не становятся произвольными глобальными настройками context. Если вы сравниваете две LM, фиксируйте эти параметры для честного сопоставления и измеряйте фактическое качество на одном отложенном наборе. Для публичного сервиса проверьте, что данные одного пользователя не попадают по ошибке в чужой выбранный провайдер. Тест без сетевого вызова защищает от случайного расхода API-лимита на этапе диагностики области действия.