Почему модель уверенно врёт, как это измерять, какие контуры защиты обязательны и как принимать работу подрядчика по качеству, а не по демонстрации.
Главный риск ИИ-системы не в том, что она ошибается, а в том, что ошибку невозможно отличить от правильного ответа по тону. Поэтому вокруг модели всегда строится система проверок, и именно она отличает рабочее внедрение от красивой демонстрации.
Здесь — механика ошибок, способы измерить качество на своих данных, обязательные ограничители и процедура приёмки, которую стоит записать в договор до начала работ.
Одна цифра в презентации почти всегда скрывает, на какой выборке она получена и какой ценой. Разбираем на модельном потоке в 1 000 обращений, как точность накручивают за счёт полноты, и даём три вопроса, которые проверяют заявленный процент за пятнадцать минут.
МетодикаРазметка нужна не для обучения модели, а для того, чтобы у компании появился эталон, с которым можно сравнивать. Ориентиры по объёму под разные задачи, норма согласованности двух специалистов и честный счёт часов предметного сотрудника.
МетодикаМетодика замера, которую компания проводит своими силами за два-три дня и повторяет каждый месяц. Выборку формирует заказчик, эталоны пишет предметный специалист, а критические ошибки считаются отдельно от общей доли правильных ответов.
МетодикаЧто именно ловит каждый контур, как проверить, что он включён, и сколько он стоит — 100 часов на внедрение и 28 часов в месяц на эксплуатацию. С чек-листом приёмки и разбором, почему без третьего контура первые два бесполезны.
ТехнологииЧетыре типовые выдумки на дословных формулировках, три разные причины с тремя разными ремонтами и четыре инженерных приёма. С расчётом: 82 часа защиты против 132 000 ₽ за один разобранный инцидент.
Раздел выходит частями. Ниже — темы, которые уже расписаны и ждут очереди. Если нужен ответ по одной из них прямо сейчас — напишите нам, разберём вашу ситуацию отдельно и без ожидания.
Механика ошибки без формул и без метафор про «сознание модели»: что происходит внутри, когда фактов не хватает, и почему результат звучит уверенно. Пять ситуаций-провокаторов, которые дают почти все выдуманные ответы в реальных проектах.
Промпт — это просьба, а не ограничение: модель может её проигнорировать, и в продуктиве это происходит регулярно. Разбираем, что обязано жить в коде, что нормально оставить в тексте инструкции и как проверить это у подрядчика за десять минут.
Отказ от ответа — не дефект, а проектное решение, которое дешевле неверного ответа в любом сценарии с деньгами и сроками. Разбираем, как настраивается порог, какая доля отказов нормальна и как отличить полезный отказ от бесполезного бота.
Рабочий регламент выборочного контроля: сколько диалогов смотреть на старте и в эксплуатации, по каким правилам их отбирать и по какому чек-листу оценивать. С расчётом часов в месяц, потому что этот контур почти всегда забывают заложить в бюджет.
Система, принятая с хорошими цифрами, через полгода отвечает заметно хуже — и почти всегда по одной из пяти причин, ни одна из которых не связана с поломкой. Разбираем, как это выглядит в метриках и что записать в договор поддержки заранее.
Правка одной строки в инструкции способна сломать сценарий, который работал полгода, и заметить это без набора контрольных примеров невозможно. Разбираем состав набора, порядок прогона и главное правило: набор принадлежит заказчику, а не подрядчику.
Демонстрация подрядчика — это не приёмка, потому что вопросы на ней задаёт он сам. Даём процедуру из шести шагов, где выборку формирует заказчик, и список артефактов, без передачи которых акт подписывать нельзя.
Четыре готовые формулировки, которые превращают обещание качества в проверяемое обязательство. Плюс объяснение, почему пункт «точность не менее 95%» без описания методики замера не значит ничего и не защищает заказчика в споре.
Перед клиентом отвечает компания, а не модель и не подрядчик — из этого следует вся инженерная защита денежных тем. Разбираем, что бот может сказать так, что это станет обязательством, и как построить систему, чтобы этого не произошло.
В диалог с ботом персональные данные попадают всегда, даже если их туда не планировали класть. Разбираем, что из требований 152-ФЗ закрывается архитектурой, а что документами, и почему зарубежная модель превращает обычную переписку в трансграничную передачу.
Клиенты быстро выясняют, что бота можно уговорить, и часть таких попыток стоит компании денег. Разбираем четыре класса манипуляций и защиту, которая работает, — не на уровне вежливой просьбы в промпте, а на уровне кода.
Предвзятость становится деловой проблемой не в абстрактных рассуждениях, а в четырёх конкретных местах, где модель принимает решение о человеке или контрагенте. Показываем, как обнаружить смещение сравнением долей и что делать, не переучивая модель.
Пять вопросов, которые ломают неготовую систему за десять минут, и правильные реакции на каждый. Материал для собственника, который идёт на демонстрацию без технического специалиста.
Продолжать проект, который не сходится, дороже, чем остановить его на третьем цикле. Даём шесть измеримых признаков, процедуру остановки без потери всего наработанного и список того, что остаётся полезным даже при закрытии.
и ещё 1 тем в этом разделе
Опишите процесс словами, голосом или файлами — вернёмся с картой процесса, вариантом решения и предварительной вилкой бюджета. Бесплатно и без обязательств.
