3 урока о работе с LLM, которые пригодятся всем
Эти уроки я вынес из работы над кодом, но они годятся для любого, кто каждый день ставит задачи ИИ-инструменту — пишет им тексты, планирует, разбирает почту, готовит презентации.
1. Не доверяй ИИ длинные цепочки шагов без проверки. Просишь модель сделать восемь связанных действий за один раз — и часть из них теряется по дороге, особенно если задача длинная. Это похоже на то, как если бы вы надиктовали кому-то список из десяти дел подряд: середина списка запоминается хуже начала и конца. Работает не идеально не потому, что модель «плохая», а потому что внутри одного ответа у неё нет обратной связи между шагами — она не может проверить шаг три, уже сделав шаг семь. Что помогает: там, где это возможно, просить не серию отдельных шагов, а один чёткий результат целиком — например, не «сначала сделай раз, потом два, потом три», а «дай сразу готовый список из всех пунктов». Меньше промежуточных шагов — меньше шансов что-то потерять по пути.
2. Если результат можно проверить — проверяй правилом или чек-листом, а не честным словом модели. ИИ может звучать уверенно и ошибаться одновременно — это не обман, просто так работает предсказание текста. Если есть чёткий способ проверить результат — формула, правило, конкретный критерий — надёжнее заложить эту проверку отдельно, а не полагаться на то, что модель сама себя перепроверила и не соврала. Пример из практики: когда в одном сообщении смешивались признаки сразу двух разных категорий задачи, я перестал просить модель «разберись сама, что имелось в виду» — вместо этого решение, какая категория побеждает, теперь принимается по чёткому правилу до того, как сообщение вообще доходит до модели. Дороже ошибиться — значит, дешевле сразу прописать правило.
3. Неоднозначность лучше закрывать чёткими правилами, чем полагаться на «разберётся сама». Можно попросить модель «не делай X» — и в девяти случаях из десяти это сработает, а в десятом она всё равно сделает X, потому что инструкция в промпте — это просьба, а не гарантия. Если ошибку легко проверить и поправить уже после того, как ответ готов, — надёжнее ловить её кодом или правилом на выходе, чем повторять просьбу другими словами. Живой пример: модель периодически дублировала приветствие, хотя её прямо просили этого не делать. Решило не более убедительное объяснение в промпте, а простая проверка на выходе, которая автоматически убирает повтор, если он всё же проскочил. Общий смысл всех трёх: там, где ошибка стоит дорого, лучше не уговаривать модель, а построить процесс так, чтобы ошибиться было структурно сложнее.