[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-what-to-do-when-an-ai-feature-gets-something-wrong::ru":3,"guide-related-what-to-do-when-an-ai-feature-gets-something-wrong::ru":18},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":8,"meta_description":9,"keywords":10,"category":16,"published_at":17,"updated_at":17},"what-to-do-when-an-ai-feature-gets-something-wrong","Что делать, когда ИИ-функция ошиблась","ИИ-функции ломаются иначе, чем обычное ПО: уверенно, правдоподобно и без ошибки. Это руководство о том, как проектировать с учётом этого заранее и что реально делать, когда неверный ответ дошёл до клиента.","\u003Ch2>Отказ другого рода\u003C\u002Fh2>\n\u003Cp>Обычное ПО ломается громко. Запрос падает, страница отдаёт ошибку, срабатывает мониторинг, кого-то будят. ИИ-функция ломается тихо: она возвращает гладкий, аккуратно оформленный, вполне правдоподобный ответ, который оказывается неверным. Ничто в ответе не отличает его от правильного, исключение не выбрасывается, а первым сигналом обычно становится клиент, который по нему уже действовал. Проектирование с учётом этого различия и составляет всю работу, потому что предотвратить каждый неверный ответ нельзя, а решить, что произойдёт при его появлении, можно.\u003C\u002Fp>\n\u003Ch2>Заранее оцените, чего стоит неверный ответ\u003C\u002Fh2>\n\u003Cp>Прежде всего расклассифицируйте функцию по последствиям. Черновик сообщения, которое человек прочтёт и отредактирует, — низкая ставка: ошибки ловит тот, кто и так в контуре. Резюме документа, по которому кто-то будет действовать без проверки, — выше. Отправка сообщения, изменение записи, оформление возврата или прямой ответ клиенту — ещё выше. Дизайн для этих категорий должен резко различаться, а самая частая продуктовая ошибка — применять ко всем один и тот же паттерн взаимодействия.\u003C\u002Fp>\n\u003Ch2>Проектируйте так, чтобы ошибку можно было поймать\u003C\u002Fh2>\n\u003Cp>Несколько приёмов делают ошибки заметными, а не поглощёнными. Показывайте источник: если ответ собран из найденных документов, дайте на них ссылки, чтобы читатель проверил утверждение в один клик, а не доверял фразе. Держите человека в контуре там, где действие необратимо: предложить действие на утверждение — совсем другой продукт, чем выполнить его. Где возможно, делайте вывод структурированным, потому что схему можно проверить механически, а на прозу остаётся только надеяться. И говорите, чего система не знает: функция, отказывающаяся отвечать вне своей области, стоит гораздо дороже той, что всегда что-нибудь выдаёт.\u003C\u002Fp>\n\u003Cp>Выражение неуверенности требует аккуратности. Расплывчатые оговорки в каждом ответе приучают людей их игнорировать. Полезнее чётко разделять случаи, под которые система сделана, и те, под которые нет, и на вторых останавливаться заметно.\u003C\u002Fp>\n\u003Ch2>Когда ошибка дошла до клиента\u003C\u002Fh2>\n\u003Cp>Относитесь к этому как к инциденту, теми же шагами, что и к любому другому. Зафиксируйте точный вход, точный вывод и версии всего задействованного — промпта, модели, найденного контекста — до того, как что-либо изменится: восстановить это позже трудно, а тот же промпт может не воспроизвести тот же ответ. Скажите клиенту прямо, что произошло и на что это повлияло: ошибка ИИ-функции в 2026 году никого не удивляет, а вот обнаружение того, что о ней знали и промолчали, удивляет.\u003C\u002Fp>\n\u003Cp>Затем найдите настоящую причину, прежде чем менять промпт. Неверный ответ может быть следствием нехватки контекста, поиска, вернувшего не тот фрагмент, двусмысленной инструкции, запроса, под который функция не задумывалась, или действительно устаревших исходных данных. У каждого своё лечение, а правка промпта рефлексом обычно сдвигает отказ, а не устраняет его.\u003C\u002Fp>\n\u003Ch2>Превратите инцидент в покрытие\u003C\u002Fh2>\n\u003Cp>Каждый настоящий сбой должен стать постоянным тестовым случаем: точный вход добавлен в ваш набор для оценки вместе с записанным правильным ответом. Это самый дешёвый надёжный источник тестовых данных, какой у вас будет, потому что он взят из того, что действительно пошло не так, а не из того, что вы вообразили. За год этот набор становится тем, что позволяет менять модели и промпты без страха, и накапливается он только если пополнение входит в закрытие инцидента.\u003C\u002Fp>\n\u003Ch2>Что сказать пользователям заранее\u003C\u002Fh2>\n\u003Cp>Скажите, что функция сгенерирована ИИ, скажите, для чего она годится, и прямо скажите, что она может ошибаться и её стоит проверять там, где это важно. Это не юридическая формальность: так задаётся ожидание, от которого зависит, будет ли один плохой ответ поводом пожать плечами или подрывом доверия. Дайте людям очевидный способ сообщить о плохом ответе и убедитесь, что эти сообщения доходят до человека: элемент обратной связи, ведущий в никуда, хуже его отсутствия — он собирает нужные вам доказательства и выбрасывает их.\u003C\u002Fp>","Когда ИИ-функция ошиблась","ИИ-функции ломаются без сообщения об ошибке. Как заранее проектировать под неверные ответы, реагировать при инциденте и превращать его в тестовое покрытие.",[11,12,13,14,15],"надёжность ии","галлюцинации","разбор инцидентов","человек в контуре","проектирование ии","fundamentals","2026-08-14T03:45:01+00:00",[19,24,28,32,37,42],{"slug":20,"title":21,"excerpt":22,"updated_at":23},"ai-tool-pricing-models-seat-vs-usage-vs-credits","Модели ценообразования AI-инструментов: за место, за использование и по кредитам","Три распространённых способа тарификации AI-инструментов — за место, за использование и по кредитам — и как понять, какой из них окажется дешевле именно для того, как работает ваша команда.","2026-08-05T14:32:26+00:00",{"slug":25,"title":26,"excerpt":27,"updated_at":23},"how-ai-image-generators-differ-diffusion-vs-the-rest","Чем различаются ИИ-генераторы изображений: диффузия и всё остальное, простыми словами","Нетехническое объяснение того, как работают ИИ-генераторы изображений, почему диффузионный подход стал доминирующим и каких практических различий стоит ждать от разных инструментов.",{"slug":29,"title":30,"excerpt":31,"updated_at":23},"how-to-automate-your-workflow-without-code","Как автоматизировать процесс без кода","Практическая последовательность для автоматизаций, которые выживают: выбрать подходящий процесс, описать его до того, как открывать инструмент, и предусмотреть сбои, ломающие большинство первых попыток.",{"slug":33,"title":34,"excerpt":35,"updated_at":36},"how-to-build-a-chatbot-without-coding","Как собрать чат-бота без программирования","Практический путь к работающему чат-боту на no-code инструментах: определить границы, подключить свой контент, обработать вопросы без ответа и понять реальную стоимость.","2026-08-05T14:32:27+00:00",{"slug":38,"title":39,"excerpt":40,"updated_at":41},"how-to-change-a-prompt-without-breaking-production","Как менять промпт, не ломая прод","Промпты правят в текстовом поле и выкатывают за секунды — поэтому они ломают вещи тихо: ни компилятора, ни стектрейса, ни очевидного момента сбоя. Дайте им релизную дисциплину кода.","2026-08-24T03:30:02+00:00",{"slug":43,"title":44,"excerpt":45,"updated_at":23},"how-to-choose-an-ai-writing-assistant","Как выбрать ИИ-ассистента для письма","Практическая схема выбора инструмента ИИ для письма — как соотнести его с той работой, которую вы реально пишете, проверить возможности редактирования и не попасть на инструменты, выдающие уверенный, но обезличенный текст."]