У естественного языка нет понятия «невалидного предложения».
Никто не проверяет, что попадает в контекст
Посмотрите, как информация попадает в контекст в текущих LLM-пайплайнах.
RAG возвращает чанки. Агент получает ответы API. Предыдущие разговоры накапливаются в истории. Пользователь загружает документ.
Всё это попадает в контекстное окно. Без проверки.
Почему нет проверки? Потому что у естественного языка нет понятия «невалидного».
Естественный язык принимает любую строку
В программировании существует такая вещь, как синтаксическая ошибка.
def calculate(x, y
return x + y
Скобка не закрыта. Код отклоняется до выполнения. Код можно определённо объявить «невалидным» до того, как он будет запущен, до того, как он будет прочитан.
У естественного языка такого нет.
«He went to the bank.» Грамматически безупречно. Невозможно сказать, кто пошёл, в какой банк или зачем, но ничто не нарушает грамматические правила естественного языка.
«Отчёт о продажах за 45-е число 13-го месяца 2024 года.» Нет ни 13-го месяца, ни 45-го дня. Но ничто не нарушает грамматические правила естественного языка. Это грамматически корректное предложение.
«Источник: неизвестно. Достоверность: неизвестно. Дата: неизвестно. Рыночная капитализация Samsung Electronics – 1200 трлн вон.» Источник неизвестен, достоверность неизвестна, дата неизвестна. Но ничто не нарушает грамматические правила естественного языка.
Естественный язык принимает всё. Невалидного предложения на естественном языке структурно не существует. Следовательно, нет механического критерия для «отклонения» информации, выраженной на естественном языке.
Что нужно для механической верификации
Посмотрите на компилятор Go.
Go отказывается компилировать, если есть неиспользуемый import. Даже если код работает безупречно. Даже если с логикой всё в порядке. Он отказывается только потому, что одна строка import не используется.
Это механическая верификация.
У механической верификации три характеристики.
Она детерминирована. Результат – да или нет. Не вероятность. Нет «наверное, всё хорошо». Валидно или невалидно.
Она дешёвая. Не нужен вызов LLM. Сравнение строк, проверка наличия полей, проверка диапазона значений. Операции CPU наносекундного масштаба.
Она не читает смысл. Она не оценивает, истинно содержание или ложно. Она лишь проверяет, соответствует ли формат спецификации. Она не знает, верно ли «рыночная капитализация Samsung Electronics – 1200 трлн вон». Но она знает, пустое ли поле источника.
Чтобы эти три вещи были возможны, есть одно предусловие. У информации должна быть спецификация.
Если есть спецификация, определены нарушения. Если определены нарушения, возможно отклонение. Если возможно отклонение, существует верификация.
У естественного языка нет спецификации, поэтому нет нарушений. Нет нарушений – нет отклонения. Нет отклонения – нет верификации.
Почему нужна проверка до попадания в контекст
Контекстное окно конечно.
Будь то 128K токенов или 1M токенов, оно конечно. Качество информации, попадающей в конечное пространство, определяет качество результата.
Но в текущих пайплайнах оценка качества происходит только после того, как информация попала в контекст. Ожидается, что LLM сам прочитает, оценит и решит: «этой информации трудно доверять».
Это неправильно по трём причинам.
Это дорого. Вы тратите затраты на инференс LLM на проверку формата. Запускаете модель с миллиардами параметров, чтобы отфильтровать чанки без источника. Используете вероятностное рассуждение для задачи, которая требует проверки одного поля.
Это ненадёжно. Нет гарантии, что LLM всегда проигнорирует информацию без источника. На практике, когда что-то попало в контекст, LLM скорее использует это. Ожидать, что модель проигнорирует то, что вы сами поместили в контекст, – противоречие.
Это поздно. Пространство окна уже потрачено. Если 5 чанков без источника занимают по 200 токенов каждый, 1000 токенов потрачены впустую. Даже если они будут отфильтрованы, это пространство уже израсходовано.
Механическая верификация предшествует всему этому. До попадания в контекст. До того, как LLM прочитает. До того, как окно будет израсходовано.
Что проверяется
Механическая верификация проверяет не истинность содержания, а соответствие спецификации формата.
Конкретно проверяется следующее:
Структурная полнота. Существуют ли обязательные поля? Есть ли у ребра субъект и объект? Ничего не пропущено?
Валидность идентификаторов. Существует ли ссылаемый узел? То, что записано как «Samsung Electronics», действительно указывает на определённую сущность? Не является ли ссылка висячей?
Соответствие типов. Есть ли дата в поле даты? Есть ли число в числовом поле? «45-е число 13-го месяца 2024 года» будет поймано здесь.
Наличие метаданных. Есть ли поле источника? Есть ли поле времени? Указана ли достоверность? Если нет – отклонить, пометить как отсутствующее или назначить значение по умолчанию.
Ссылочная целостность. Существует ли узел, на который указывает ребро? Не ссылается ли оно на удалённый узел?
У этих проверок есть одно общее свойство. Все они могут быть выполнены без чтения содержания. Вы не знаете, верно ли «рыночная капитализация Samsung Electronics – 1200 трлн вон». Но вы знаете, указан ли для этого утверждения источник. Вы знаете, записано ли для этого утверждения время. Вы знаете, соответствует ли формат этого утверждения спецификации.
Дешёвое – в первую очередь
В пайплайне контекстной инженерии проверки имеют порядок.
Механическая верификация: соответствие спецификации. Стоимость почти нулевая. Детерминирована. Семантическая фильтрация: оценка релевантности, достоверности, полезности. Высокая стоимость. Вероятностная. Проверка согласованности: противоречия между выбранными фрагментами информации. Ещё выше стоимость. Требует рассуждений.
Если расположить их от дешёвого к дорогому, дорогие проверки обрабатывают меньше данных.
Если механическая верификация отфильтрует 30% утверждений без источника, семантической фильтрации нужно обработать только 70%. Если семантическая фильтрация уберёт нерелевантное, проверка согласованности работает с ещё меньшим набором.
Это тот же принцип, что и оптимизация запросов в базах данных. Сначала применить условия, фильтруемые по индексу, в WHERE. Полное сканирование – потом. Если дешёвое – в первую очередь, нагрузка на дорогое уменьшается.
И наоборот, если запустить дорогую проверку первой, а дешёвую – потом, вы обнаружите ошибки формата только после того, как уже потратите ресурсы. Вы анализируете смысл утверждения, ссылающегося на несуществующий узел, и только потом обнаруживаете, что ссылка невалидна.
Этот порядок невозможен в пайплайне естественного языка
У естественного языка нет спецификации, поэтому механическая верификация невозможна. Раз механическая верификация невозможна, самой дешёвой проверки не существует.
Следовательно, каждая проверка – семантическая. Каждая проверка требует LLM. Каждая проверка дорогая.
«Есть ли у этого чанка источник?» – LLM должен его прочитать. «Уместна ли временная привязка этого чанка?» – LLM должен его прочитать. «Корректен ли формат этого чанка?» – У естественного языка нет формата, поэтому сам вопрос не имеет смысла.
Такова реальность текущей контекстной инженерии. Даже простейшая проверка выполняется самым дорогим инструментом. Задача, которую можно решить сравнением строк, обрабатывается движком инференса.
Предпосылки для верификации
Чтобы механическая верификация существовала, нужны три вещи.
Спецификация. Формат, которому информация должна следовать, должен быть определён. Какие поля обязательны, какие значения допустимы, какие ссылки валидны. Без спецификации нарушения не могут быть определены.
Формализация. Информация должна быть выражена в формате, который требует спецификация. Не в виде предложений на естественном языке, а закодированной в структуре, которую предписывает спецификация. Неформализованную информацию нельзя проверить.
Право на отклонение. Должна существовать возможность действительно отклонить информацию, не соответствующую требованиям. Если проверяете, но всегда пропускаете, – это не верификация. Невалидная информация должна быть предотвращена от попадания в контекст.
Эти три вещи считаются само собой разумеющимися в языках программирования. Есть спецификация – грамматика, есть формат – код, есть право на отклонение – компилятор.
В естественном языке все три отсутствуют. Грамматика – это не спецификация формата, а конвенция. Предложения – не структурированные форматы, а свободный текст. Понятия «невалидного естественного языка» не существует, поэтому нечего отклонять.
Чтобы ввести механическую верификацию в контекстную инженерию, должно измениться само представление информации.
Итог
В текущем контекстном пайплайне информация попадает в контекст без проверки. Потому что у естественного языка нет понятия «невалидного предложения».
Механическая верификация проверяет не истинность содержания, а соответствие спецификации формата. Структурная полнота, валидность идентификаторов, соответствие типов, наличие метаданных, ссылочная целостность. Детерминирована, дешёвая, и не читает смысл.
В пайплайне дешёвые проверки должны идти первыми. Если механическая верификация отфильтрует ошибки формата, дорогие семантические оценки обрабатывают меньше данных.
У естественного языка нет спецификации, поэтому эта проверка невозможна. Каждая проверка становится семантической, каждая проверка дорогая.
Чтобы механическая верификация была возможна, нужны спецификация, формализация и право на отклонение. Должно измениться само представление информации.