R1.2:Tasks1 - Задание: Оцените заземлённость постановки задачи из руководства R1. Распожаризация: как не «тушить пожары», а избегать их появления

Задание R1.2:Tasks1 — применил схему заземления к рабочей задаче.

Взял задачу из работы: «Обрезать количество токенов для вывода в корпоративном мессенджере ответов». Формулировка моя, ровно в том виде, в каком она у меня была до заземления.

Помогло ли заземление выявить ошибки?

Первый шаг схемы просит назвать, что изменится в физическом мире. Написал я там вот что: «ответ модели начнёт появляться в ответ на вопрос пользователя», «сейчас дребезжит то, что качество ответов в этой задаче не учитывается, они могут быть обрезаны настолько, что часть ответа пользователь не увидит».

Исходная формулировка задачи и то, что я написал на первом шаге, оказались про разное. В формулировке - обрезать токены. На первом шаге - про полноту ответа у пользователя.

Расхождение, что в формулировке было дано решение, а не описание проблемы

Разбор моделью с опорой на FPF добавил ещё три замечания:

  • Выбранный рычаг работает против цели. Уменьшение верхней границы генерации не делает ответ короче и целым, а обрывает его посреди мысли.

  • Замер не может увидеть заявленный дефект. Я мерил длину через len() с порогом 4000 символов, а короткий ответ и целый ответ - разные вещи: обрубок на 800 символов эту проверку проходит.

  • Условия в четвёртом шаге написаны как одно утверждение в двух видах.

Согласен с находками.

Помогло ли составить план решения?

Думаю, что да, но мотивации что-то делать уже нет :slight_smile:

Стоило ли напрягаться или радар сработал вхолостую?

Наверное, стоило. Про агентов мне подсветил хорошо. Я почему-то с такой точки зрения не посмотрел. Ну и ещё во время разбора выяснил, что не до конца понял работа параметра max-tokens.

Что не получилось.

Не сошлось понимание дребезга. Модель в каждом ответе говорила, что дребезг относится к другой задаче, и я так и не понял, ошибаюсь я в самом понятии или не могу объяснить модели, что имею в виду. Работа с моделью тоже далась тяжело: перегенерировал ответ 3-4 раза, уставал уточнять запрос и начинал заново.

Хорошо, Анатолий! Отдохните от ответов LLM, усиленной FPF, а потом вернитесь к ним.
Мы часто тратим ресурсы вовсе не на то решение, которое реально принесло бы пользу компании, потому что не выделили время на разбирательство с проблемой и вместо этого много внимания уделили решению (как будто бы понимаем, какую проблему решаем).

Здесь часто бывает полезно восстановить проблему. Это можно делать даже тогда, когда к вам приходят с запросом на фичу. Вообще говоря, трансформация в настоящую продуктовую команду (не фичекоманду) начинается как раз с того, что команда начинает задавать вопросы “а какую проблему бизнеса мы решаем” (и предлагать более удачные решения, чем “обрезать токены”).

1 лайк