Модели, контекст и неверные ответы

Отделяйте возможности от доступной информации

Языковая модель использует усвоенные закономерности и информацию, полученную во время задачи. Современные модели способны решать сложные задачи рассуждения и выполнять полезную работу с ПО. Они также могут дать подробный ответ, основанный на неверном предположении.

«Frontier-модель» обозначает меняющийся уровень возможностей. Этот термин не доказывает, что модель прочитала ваш репозиторий. Он не показывает, знает ли она версии зависимостей или неписаные бизнес-правила. Эти сведения должно предоставить окружение задачи.

Агент с подходящими инструментами может получить информацию. Чат без доступа не может изучить репозиторий. Если ответ кажется неверным, задайте два вопроса. Способна ли модель решить эту задачу с нужной информацией? Получила ли она эту информацию?

С первой проблемой может помочь другая модель. Вторую может решить недостающее правило или проверка зависимости.

Определите контекст задачи

Контекст — информация, доступная для текущего ответа. В него входят инструкции, предоставленные файлы, относящаяся к задаче переписка и результаты инструментов. Продукты по-разному выбирают и сохраняют эту информацию. Они могут также сокращать предыдущий материал до краткого изложения.

Не предполагайте, что модель читает каждый файл загруженной папки. Не предполагайте, что ранняя инструкция остаётся доступной на протяжении длинной сессии. Попросите инструмент перечислить использованные файлы и инструкции.

Увеличение контекста не всегда улучшает ответ. Актуальное архитектурное решение может помочь больше, чем не относящиеся к задаче исходные файлы. Устаревшее руководство по миграции может привести к ошибке, если выглядит авторитетным.

Рассмотрим вымышленную функцию настройки аккаунта. Предоставьте маршрут запроса, middleware авторизации, соответствующую модель данных и существующий тест. Добавьте конкретное ограничение: «Участник может изменить своё отображаемое имя. Участник не может изменить свою роль в организации». Теперь у модели есть явное правило, которое нужно сохранить.

Проверяйте утверждения в объяснении

В ответе может быть сказано, что endpoint безопасен, поскольку middleware проверяет принадлежность ресурса. Проверьте каждую часть этого утверждения.

1. Убедитесь, что endpoint использует указанное middleware.
2. Убедитесь, что middleware проверяет принадлежность ресурса, а не только аутентификацию.
3. Определите источник идентификационных данных пользователя.
4. Выполните отрицательный тест от имени другого пользователя.

Ссылка на репозиторий показывает, где искать. Она не доказывает, что объяснение соответствует коду.

Так же проверяйте рекомендации по API. Сгенерированный код может вызывать метод, который установленный пакет не экспортирует. Перед заменой зависимостей проверьте версию пакета и официальную документацию. Иначе неподтверждённое предположение может привести к ненужной миграции.

Превращайте неопределённость в проверку

«Будь точным» — не план проверки. Определите предположение, нужное подтверждение и последствия неверного результата.

Например: «Мы не проверили изоляцию тенантов в этом endpoint. Изучи обработчик запроса. Добавь тест, в котором пользователь из другого тенанта запрашивает ту же запись». Такая инструкция задаёт агенту конкретное исследование и наблюдаемый результат.

В вопросах реализации изучайте фактическую версию системы. Документ может описывать ожидаемое поведение. Анализ кода и тесты помогают установить текущее поведение. При расхождении зафиксируйте его, пока ответственный не разрешит вопрос. Не выбирайте молча более удобный ответ.

Руководители могут применять этот подход, не читая каждое изменение кода. Спрашивайте, какие предположения команда проверила. Определяйте открытые предположения и ответственных за них. Эта информация даёт более прямое основание для решения о выпуске, чем название модели.