Твоему ИИ нужен бортовой самописец, и ты создаёшь его в первый же день.
Небольшой набор записей, позволяющий объяснить любой вывод ИИ через несколько месяцев и выявить изменение качества до того, как это заметит клиент.
Когда искусственный интеллект выходит на производственный уровень: первые вопросы и ответы
Когда система искусственного интеллекта (ИИ) выходит на стадию производства, первый важный вопрос не касается того, как она работает, а почему она дала именно такой ответ. Клиент оспаривает цитату, аудитор спрашивает, как было принято решение, или член вашей команды замечает, что в этом месяце резюме ухудшились, но не может вспомнить, когда это началось.
В этот момент вы либо обладаете необходимой информацией, либо нет, и позже восстановить ее будет сложно. Повторное задавание того же вопроса сегодня даст вам ответ от сегодняшней модели, с использованием сегодняшнего запроса и данных. Это не является доказательством чего-либо.
Ведение журнала — это решение, принятое с самого начала. Добавленное позже, оно охватывает только то, что происходит дальше.
Шесть факторов, влияющих на ответ ИИ
Ответ ИИ является результатом небольшого набора входных данных. Запишите все они при каждом вызове, начиная с первого запроса:
- Запрос — уникальный идентификатор, временная метка, информация о том, кто или что запросило систему и точный текст или данные, представленные пользователем.
- Контекст — каждый документ, запись или строка, извлеченная системой и размещенная перед моделью, с индивидуальным идентификатором и версией каждого документа.
- Инструкции — шаблон запроса плюс любая информация, собранная в реальном времени, и версия шаблона.
- Модель — точный идентификатор модели (не только название семейства) вместе с используемыми настройками: температурой, ограничениями токенов, инструментами, которые она может вызывать.
- Вывод — сырой ответ до любой очистки и обработанный вариант, если они отличаются.
- Последствия — что произошло дальше: отображение пользователю, отправка по электронной почте клиенту, использование для одобрения требования и т.д., а также то, принял ли человек ответ, отредактировал или отклонил его.
Если вы исключите контекст и инструкции, у вас останется половина разговора. Вы сможете увидеть, что система ответила, но не сможете установить, почему этот ответ был разумным.
Версии — это то, что обычно упускают из виду
Три вещи могут измениться под системой ИИ без того, чтобы кто-либо подал заявку на изменение. Кто-то редактирует шаблон запроса во вторник после обеда. Поставщик обновляет модель за тем же API-имя. Базы знаний переиндексируются, и система начинает извлекать разные документы для одного и того же вопроса.
Каждое из этих изменений может повлиять на качество, и ни одно из них не отображается в журнале вывода. Записывайте идентификатор версии шаблона, модели и индекса данных при каждом вызове, и вопрос "что изменилось между хорошей и плохой неделей" можно будет ответить за несколько минут. Без этих записей это займет неделю догадок, обычно пока кто-то из старшего руководства не подождет.
Корректировки человека — ваш лучший сигнал
Когда человек редактирует черновик ИИ перед отправкой, он точно указывает, что было неправильно, используя самые конкретные термины. Храните оригинал вместе с отредактированным вариантом.
Если вы это сделаете, два важных момента последуют: скорость редактирования станет показателем качества, который можно отслеживать еженедельно, и коррективы будут накапливаться в наборе примеров, созданных вашей собственной работой, а не приобретенных или изобретенных.
Отклонение — это сравнение, а не тревожный сигнал
Ничто не уведомит вас о том, что выходные данные ухудшились. Ухудшение происходит постепенно, и каждый отдельный ответ выглядит убедительно.
Практический метод состоит в том, чтобы вести постоянную фиксированную группу реальных запросов — достаточно 100, взятых из фактического трафика и охватывающих ваши сложные случаи — и повторять их каждый месяц. Сравнивайте новые ответы с сохраненными. Там, где они отличаются, человек читает оба варианта и определяет, какой лучше. Это работает только при условии сохранения входных данных, что является аргументами за ведение журналов.
Наряду с уже имеющимися у вас показателями: скорость редактирования, процент отклонений, эскалация до человека, доля ответов, в которых система не нашла релевантных документов. Повышение последнего обычно означает, что ваши данные устарели, а не что модель ухудшилась.
Определите политику хранения и редакцию данных сначала
Эти журналы содержат все, что вводят пользователи, что означает, что они несут те же обязательства, что и любые другие личные данные. Классифицируйте поля по мере их ввода, маскируйте или токенизируйте то, что не должно быть читаемым, и храните журналы отдельно от приложения, чтобы сбой в одном не привел к потере записей другого.
Установите политику хранения намеренно. Для решений с юридическими или нормативными последствиями сохраняйте записи как долго длится соответствующая ответственность, и сделайте хранилище только для добавления, чтобы никто не мог тайно изменить историю. Для рутинного трафика более короткий срок хранения лучше и дешевле. Назначьте одного человека ответственным за политику.
Хранение — это дешевая часть. Дорогостоящей является интеграция всех этих записей в живую систему, когда вы уже получаете запросы объяснить выходные данные, которые вы не можете обосновать. Мы создаем эти записи с самого начала, потому что они превращают систему ИИ из чего-то, в чем вы доверяете, в то, что вы можете продемонстрировать.