Шесть концепций ИИ, которые подскажут вам, что проверить перед тем, как доверять ответу
Токены, окна контекста, параметр температуры, галлюцинации, технологии RAG и агенты рассматриваются как инструменты проверки, которые позволяют выявлять ошибки, контролировать затраты и оценивать утверждения ИИ-продуктов.
Вы передаёте искусственному интеллекту отчёт, и в ответ получаете отредактированное резюме с графиком, которого нет нигде в документе. Когда вы спрашиваете об этом, ассистент извиняется и предлагает другой график. Не хватало информации, произошла ошибка при поиске или число было просто выдумано? Шесть основных концепций, понятных с точки зрения принимаемых ими решений, позволяют заменить вопрос «Почему он лжёт?» на точный диагностический вопрос, а также помогают контролировать затраты и оценивать утверждения поставщиков.
Почему скептицизм — разумный стандарт
Недоверие к результатам работы ИИ распространено даже среди тех, кто использует его ежедневно. В опросе разработчиков Stack Overflow 2025 года 46% респондентов на вопрос об точности заявили, что не доверяют результатам ИИ, тогда как 33% верили в их достоверность; это на основе 33 244 ответов (результаты опроса). Прочитайте это внимательно: здесь записаны мнения разработчиков, а не показатели точности моделей, к тому же речь идет не о репрезентативной выборке населения. Однако это действительно отражает реальное противоречие: люди используют эти инструменты, но всё равно не верят всему, что они говорят.
Во-первых, применяйте такую же критику к заголовкам
Содержание о ИИ часто обещает, что знание нескольких терминов позволяет оказаться «перед 90% людей». Это звучит как результат исследования, но при отсутствии соответствующего исследования это всего лишь маркетинг в обличии статистики. Стоит задать очевидные вопросы: перед кем именно, как это измеряется, с участием кого, и где опубликованы результаты? Отсутствие оценки, выборки и данных означает, что это процент не имеет оснований. Это не делает все сопутствующие объяснения неверными и ничего не говорит о намерениях кого-либо; это просто означает, что этот показатель не имеет значения.
Знание определений — это отправная точка. Их применение, распознавание исключений и проверка реальных результатов — это отдельные навыки, и ни один из них не измеряется лестным процентом.
Тот же принцип дисциплины применим к утверждениям о том, что один запрос может заменить целую команду или что какой-то инструмент в десять раз увеличивает скорость работы всех. Запрашивайте конкретную задачу, базовые показатели, способ их измерения и существующие ограничения. Одна впечатляющая демонстрация не может служить основанием для общего вывода. Хорошим является привлекательный заголовок; проблемы начинаются, когда утверждение более точное, чем доказательства, его подтверждающие. Применяйте к этому руководству тот же стандарт.
1. Токены: реальный размер задачи
Токен — это единица текста, которую на самом деле обрабатывает языковая модель. В зависимости от токенизатора токеном может быть целое слово, фрагмент слова, знак препинания или любой другой элемент текста, причем токенизатор соответствует каждому элементу числовым идентификатором.
Не существует жесткого правила вроде «одно слово — один токен». В обзоре токенизаторов Hugging Face описано несколько подходов, включая кодирование парами байтов, WordPiece и методы, связанные с SentencePiece; одно и то же предложение может быть разделено совершенно по-разному разными токенизаторами. Языки, отличные от английского, код и нестандартный формат часто требуют большего количества токенов на слово.
Важность этого становится очевидной при рассмотрении такого вопроса:
Какие три жалобы клиентов встречаются чаще всего?
Сам вопрос кажется незначительным. Но если для его ответа необходимо прочитать тысячи сообщений поддержки, этот вопрос представляет собой погрешность округления в общем объеме данных. В качестве примера: 400 сообщений по 150 токенов каждое уже дают в сумме 60 000 токенов до учета каких-либо инструкций или другого контекста.
Поэтому важный вопрос заключается не в длине вашего запроса, а в объеме материала, который система должна обработать. Поскольку ценообразование, задержки и ограничения по контексту обычно выражаются в токенах, именно они определяют стоимость. Перед обработкой большого документа удаляйте повторяющиеся подписи электронных писем, нерелевантные приложения и дублирующиеся записи, которые не добавляют ценной информации, сохраняя при этом всё то, от чего действительно зависит ответ.
2. Окно контекста: что модель может увидеть в одном запросе
Окно контекста ограничивает объем материала, с которым может работать модель в одном запросе. Системные инструкции, история разговора, полученные фрагменты текста и любые другие входные данные потребляют этот лимит; способ учета токенов вывода зависит от модели и API. Документация Google по работе с большим контекстом показывает, как большие окна контекста позволяют обрабатывать большие коллекции текстов и других медиафайлов.
Однако принятие документа — это не то же самое, что надежное использование всех соответствующих в нем деталей. В исследовании 2023 года под названием «Потеряно посредине» тестировались функции ответов на вопросы на основе нескольких документов и поиска информации в формате «ключ-значение», и было обнаружено, что для рассматриваемых моделей точность часто снижалась, когда релевантная информация находилась посередине длинного ввода, а не ближе к началу или концу. Считайте это историческими данными о конкретных экспериментах, а не показателем для современных моделей, но урок о необходимости проверки остается актуальным.
Продукты чатов также редко ведут себя так, как предполагает их интерфейс. Когда диалог становится слишком длинным для окна чата, приложение не обязано просто удалять самые старые сообщения; оно может вместо этого составить краткое резюме, выбрать или извлечь более ранний материал. То, что вы видите в истории чата, — это не надежное отражение того, что поступает к модели при каждом вызове.
На практике:
- Для длительных задач храните краткое, четкое описание текущих требований и решений, а также переформулируйте его каждый раз, когда это необходимо.
- Если вывод зависит от одного конкретного фрагмента, попросите ассистента процитировать или найти этот фрагмент перед тем, как делать вывод.
Большое окно предоставляет системе пространство для работы; однако это не гарантирует, что система использовала правильные доказательства.
3. Температура: контроль над разнообразием, а не над истиной
На каждом этапе генерации модель оценивает каждый возможный следующий токен. Параметр температуры изменяет распределение вероятностей, используемое для выбора токенов на основе этих оценок: низкие значения сосредотачивают вероятность на наиболее вероятных вариантах, тогда как высокие значения распределяют ее по большему количеству вариантов. В документации Hugging Face температура описывается вместе с другими параметрами генерации, такими как выборка top-p и жадное декодирование.
Соблазнительный упрощённый подход заключается в том, что «низкая температура означает точность». Но это не так. Если наиболее верный ответ модели неверен, снижение разнообразия не поможет восполнить отсутствующий факт; оно лишь приведёт к тому, что та же ошибка будет повторяться более систематически. Аналогично, повышение температуры не гарантирует лучших идей, а лишь более разнообразных.
Два противоположных по характеру задания показывают эту разницу. Создание пяти названий для вымышленного кафе выгодно от разнообразия. Извлечение номеров счётов выгодно от единообразия формата, но эти номера всё равно должны соответствовать реальным счётам, и температура здесь не играет никакой роли.
Рассматривайте температуру как один из параметров для экспериментов и оценивайте его с учетом реальных потребностей задачи. При извлечении данных считайте неверные и отсутствующие поля; при генерации идей проверяйте, являются ли они пригодными к использованию и действительно различаются друг от друга. Прогнозируемость и точность требуют отдельной проверки.
4. Галлюцинации: результаты, выходящие за рамки имеющихся доказательств
Под галлюцинацией здесь понимается сгенерированный контент, который является вымышленным, фактически неверным или не подтверждается материалами, которые он предполагает описывать. Уверенный тон затрудняет его обнаружение, но уверенность не является частью определения; осторожно сформулированное утверждение также может оказаться необоснованным.
Очевидным примером является выдуманная научная статья. Более тонким и распространенным примером является реальная статья, цитируемая по результату, которого в ней никогда не было, и которая кажется достоверной при поверхностном просмотре именно благодаря наличию этой цитаты.
В критерии оценки TruthfulQA было представлено 817 вопросов в 38 категориях, основанных на распространённых заблуждениях. В первоначальной оценке лучший протестированный модель давал правильные ответы на 58% вопросов, тогда как у людей этот показатель составлял 94%. Это исторические результаты исследований 2021 и 2022 годов; они не отражают текущую эффективность чат-ботов и не являются универсальным показателем частоты галлюцинаций. Эти исследования показывают, что модели способны верно воспроизводить ложные убеждения, присутствующие в текстах, написанных людьми.
Если в кратком изложении приводится удивительный показатель, необходимо явно спросить о его источнике:
Укажите исходный отрывок, дату его написания и контингент, по которому проводилось измерение. Если отрывок не подтверждает этот показатель, отметьте его как неподтверждённый.
Затем проверьте источник своими глазами. Любая цитата, сгенерированная моделью, является лишь утверждением до тех пор, пока вы не подтвердите как существование страницы, так и то, что она действительно содержит конкретное предложение.
5. RAG: получение доказательств перед ответом
Метод генерации с усилением за счёт поиска сочетает этап поиска с этапом генерации. Система находит соответствующий материал во внешнем источнике, передаёт его модели и просит модель ответить на основе этого материала.
Влиятельная статья 2020 года о RAG объединила заранее обученную модель генерации с механизмом поиска в индексе Википедии, и после публикации она показала лучшие результаты среди трёх тестовых заданий по вопросо-ответным системам открытой области. Эти результаты относятся к одной исследовательской системе, а не являются гарантией качества для всех продуктов, имеющих метку RAG.
Представьте ситуацию, когда сотрудник спрашивает, сколько дней у него есть на подачу заявления на возмещение расходов. Хорошая система извлекает действующие правила и отвечает на основе них. Если же она извлекает правила прошлого года, качественно написанный текст не сможет исправить ошибку — ответ будет понятным, но неверным. Именно поэтому сбои в работе RAG обычно легче диагностировать по этапам, чем просто рассматривая окончательный ответ; этот подход описан в оценке RAG по этапам сбоя.
Стоит прояснить два заблуждения:
- RAG не требует наличия специализированного хранилища векторов. Шаг поиска может осуществляться с использованием классического совпадения ключевых слов, измерения сходства векторов или их комбинации; в обзоре RAG от Microsoft рассматриваются все эти варианты, а также важность подготовки контента для эффективного поиска.
Чтобы оценить любого помощника с документами, задайте два отдельных вопроса: нашёл ли он нужный фрагмент и отражает ли его ответ верно этот фрагмент?
6. Агенты: системы, которые выбирают свои следующие действия
Термин «агент» используется довольно широко, поэтому конкретное различие помогает. Руководство Anthropic по созданию эффективных агентов описывает рабочие процессы как системы, следующие заранее определённым путями кода, в то время как агенты позволяют модели динамически управлять собственным процессом и использованием инструментов.
Фиксированный рабочий процесс может извлекать поля из счета-фактуры, проверять их и сохранять запись, всегда в этом порядке. Сотрудник, столкнувшийся с неполным счетом-фактурой, может по своему усмотрению открыть вложение, найти соответствующий заказ и отправить запрос о нехватке информации.
Поэтому ключевой вопрос заключается в следующем: какие решения и действия разрешено принимать системе? Подготовленный ответ и осуществленная возврат средств имеют совершенно разные последствия. Сотруднику необходимы четко определенные полномочия, видимые результаты каждого действия и способ остановки при отсутствии возможности определить разумный следующий шаг.
Чем больше шагов, тем выше вероятность неудачи. В качестве упрощённого примера: если для выполнения задачи требуется десять шагов, и каждый из них с успехом выполняется независимо с вероятностью 95%, то вероятность того, что все десять шагов пройдут успешно, составляет 0,95 в десятой степени, примерно 60%. На практике шаги агента взаимосвязаны, и повторные попытки меняют расчёты, поэтому это скорее интуитивное понимание кумулятивного риска, чем эталон. Практический вывод заключается в том, чтобы оценивать, была ли задача выполнена правильно в целом, включая все побочные эффекты, а не кажутся ли отдельные шаги разумными. Для более полного рассмотрения самого цикла см. понимание ИИ-агентов: цели, инструменты, память и цикл агента.
Чек-лист из шести вопросов для реальных задач
Каждая концепция соответствует вопросу, который можно задать по любой реальной задаче:
- Токены: сколько материала на самом деле требуется системе для обработки в этой задаче, и что можно удалить без потери доказательств?
- Окно контекста: на каком отрывке основывался ответ, и действительно ли система им воспользовалась?
- Температура: касается ли эта задача разнообразия или последовательности, и проверялись ли корректность и предсказуемость отдельно?
- Галлюцинации: где именно находится источник каждого удивительного утверждения, и говорит ли он о том же, что утверждает ответ?
- RAG: был ли получен правильный актуальный документ, и представлен ли он точно?
- Агенты: что разрешено делать системе, и была ли вся задача, включая её побочные эффекты, выполнена правильно?
Заключение
Попробуйте применить эти вопросы к реальному заданию, такому как краткое изложение документа, изменение кода или ответ клиенту, имея исходный материал открытым рядом. Определите, на каких данных основывался инструмент, к каким выводам он пришел самостоятельно и какие действия фактически выполнил. Регулярное выполнение этого позволяет узнать о надежности инструмента гораздо больше, чем любая демонстрация или статистика из заголовков, а также превращает расплывчатое недоверие в конкретные, решаемые проблемы: чрезмерно объемный вводных данных, пропущенный фрагмент, неверный документ, не поддерживаемая цифра или агент с чрезмерными полномочиями.