Задание R1.2:Tasks1 — применил схему заземления к рабочей задаче.
Взял задачу из работы: «Обрезать количество токенов для вывода в корпоративном мессенджере ответов». Формулировка моя, ровно в том виде, в каком она у меня была до заземления.
Помогло ли заземление выявить ошибки?
Первый шаг схемы просит назвать, что изменится в физическом мире. Написал я там вот что: «ответ модели начнёт появляться в ответ на вопрос пользователя», «сейчас дребезжит то, что качество ответов в этой задаче не учитывается, они могут быть обрезаны настолько, что часть ответа пользователь не увидит».
Исходная формулировка задачи и то, что я написал на первом шаге, оказались про разное. В формулировке - обрезать токены. На первом шаге - про полноту ответа у пользователя.
Расхождение, что в формулировке было дано решение, а не описание проблемы
Разбор моделью с опорой на FPF добавил ещё три замечания:
-
Выбранный рычаг работает против цели. Уменьшение верхней границы генерации не делает ответ короче и целым, а обрывает его посреди мысли.
-
Замер не может увидеть заявленный дефект. Я мерил длину через
len()с порогом 4000 символов, а короткий ответ и целый ответ - разные вещи: обрубок на 800 символов эту проверку проходит. -
Условия в четвёртом шаге написаны как одно утверждение в двух видах.
Согласен с находками.
Помогло ли составить план решения?
Думаю, что да, но мотивации что-то делать уже нет ![]()
Стоило ли напрягаться или радар сработал вхолостую?
Наверное, стоило. Про агентов мне подсветил хорошо. Я почему-то с такой точки зрения не посмотрел. Ну и ещё во время разбора выяснил, что не до конца понял работа параметра max-tokens.
Что не получилось.
Не сошлось понимание дребезга. Модель в каждом ответе говорила, что дребезг относится к другой задаче, и я так и не понял, ошибаюсь я в самом понятии или не могу объяснить модели, что имею в виду. Работа с моделью тоже далась тяжело: перегенерировал ответ 3-4 раза, уставал уточнять запрос и начинал заново.