
Ключ от верхних ящиков потерялся. Ключ от верхних ящиков потерялись.
Между «ключом» и «потерялся» вклинились «ящики» во множественном числе. Мы, носители языка, не задумываясь, понимаем, что потерялся ключ, и согласуем глагол с ним. У LLM перед сказуемым развилка: «ключ» требует единственного числа, а более близкие «ящики» – множественного. Если модель будет опираться на близость слов сильнее, чем на структуру фразы, она может выбрать форму «потерялись». Это – ошибка согласовательного притяжения.
Даже если нейросеть выберет правильный ответ, это еще мало что значит. «Ключ потерялся» модель могла видеть тысячи раз. Интереснее заменить ключ на другое слово, отодвинуть глагол и поставить рядом несколько существительных во множественном числе. Тут и выяснится, видит ли LLM связь между словами или просто идет по ближайшему следу.
Такие ловушки для нейросетей придумывают лингвисты. Сегодня разберем несколько и посмотрим, что модель делает с формой слова, синтаксисом, смыслом и контекстом.
В основном будем говорить об авторегрессионных моделях: они собирают текст по одному токену, каждый раз предсказывая следующий. Иногда заглянем в работы о BERT и других энкодерах.
У слова токен два значения. В корпусной лингвистике это конкретное появление единицы в тексте. Формы «кот» и «кота» в предложении «Кот увидел кота» — два токена одной леммы кот.
У модели токен — элемент технического словаря. Им может быть слово, его кусок, запятая, пробел со следующим словом или несколько байтов. С языковыми единицами эти границы совпадать не обязаны.
Возьмем слово домики. Лингвист разберет его на корень дом-, суффикс -ик- и окончание -и. Токенизатор, с точки зрения морфологии, расчленит слово, разделит его пополам или разрежет в месте, например доми + ки. Но морфемику нейросеть не сдавала, ее задача — собрать словарь разумного размера и не растянуть текст на бесконечную цепочку токенов.
С пробелами еще веселее. Во многих токенизаторах пробел входит в токен следующего слова. Поэтому дом в начале строки и дом после пробела могут кодироваться по-разному. От токенизации зависят длина последовательности, расход контекста, стоимость вычислений и качество работы с конкретным языком. В сравнении девяти языков и пяти типов задач токенизатор, обученный для отдельного языка, улучшил работу многоязычной модели почти во всех случаях.
Русский язык для токенизатора, можно сказать, головная боль. Один корень обрастает приставками, суффиксами и окончаниями, и программе приходится решать, где все это резать. В работе MorphBPE границы морфем учитывали прямо при обучении токенизатора. На русском модели лучше предсказывали текст и справлялись с пониманием прочитанного. Авторы отдельно проверили: дело не сводилось к более коротким последовательностям
Из этого вывод: токен – не слово и не морфема, а удобный для машины кусок текста. Совпал с суффиксом, славно, разрезал морфему пополам — модель может собрать нужную информацию из нескольких токенов.
После токенизации каждый токен получает ID — номер в словаре модели.По номеру из таблицы достают вектор, то есть набор чисел. Это эмбеддинг, черновой портрет токена без контекста.
Таблиц morphology, syntax и semantics нет, поэтому лингвисты действуют в обход: подключают к слоям небольшие классификаторы и проверяют, можно ли извлечь из векторов часть речи, синтаксическую связь или значение.
В одном из таких опытов BERT разложил язык почти по учебнику. Сначала обнаружились части речи, затем синтаксис и именованные сущности, выше — семантические роли и кореференция. Красота результата даже немного пугала, уж очень хорошо все разложилось.
Позже BERT проверили при других условиях, учли позицию токена, этап обучения и случайную инициализацию. Тогда языковые признаки не выстроились по слоям, результат зависел и от модели, и от того, как ее измеряли.
И в этом нет ничего удивительного. Сам язык не любит отделов. Окончание, например, указывает одноременно на число, падеж и связь с соседними словами. Порядок слов может менять и синтаксис, и акцент фразы. Посмотрим на уровни языка по отдельности.
Если я попрошу нейросеть подобрать рифму к слову розы, она предложит грезы и слезы. Все верно. Только ни того ни другого она никогда не слышала.

Фонетика изучает, как звук произносится и звучит, фонология — какие звуковые различия важны для языка. Но у текстовой LLM только буквы и токены. Все остальное она восстанавливает по письменным следам, хотя голосовой интерфейс создает небольшую иллюзию. Мы говорим с ассистентом и думаем, что говорим именно с LLM; но часто звук принимает одна модель, превращает его в текст и только потом передает другой. Аудиомодели, которые работают прямо со звуковой волной, — отдельный случай. Например, «за́мок» и «замо́к» без ударения пишутся одинаково. Человек слышит разницу, модель находит ее по смыслу фразы. О произношении она узнает из словарей, транскрипций и т.д.
Так что способность подобрать рифму не доказывает, что внутри сформировалось человеческое фонологическое представление. С «розами» то же самое. «Грезы» и «слезы» могли тысячи раз стоять рядом с ними в стихах и песнях. Верная рифма только доказывает, что модель уловила связь между написанием и произношением.
Это проверяли на английском PhonologyBench. Текстовые модели без доступа к аудио переводили буквы в фонемы, подбирали рифмы и считали слоги; но людям уступили. Разрыв составил 17 процентных пунктов в рифмах и 45 — в слогах.
Есть старый лингвистический опыт. Ребенку показывают вымышленное существо и говорят: «Это один ваг. А теперь их два. Это два…» Если ребенок отвечает вага, правило он понял; подсмотреть готовую форму было негде. Тест так и называется — wug test, только теперь на место ребенка посадили GPT.
В многоязычном исследовании модели образовывали новые формы вымышленных слов на шести языках, а носители языка решали, годится ответ или нет. Модели в целом понимали, чего от них хотят. Но сложная морфология быстро портила картину: чем больше значений язык прятал в одной словоформе, тем чаще возникали ошибки. Даже количество обучающих текстов помогало меньше, чем можно было ожидать.
Возьмем слово «договор»:
новый договор
нового договора
новыми договорами
Объект все тот же, но как только изменились число и падеж, сменилось окончание прилагательного. С точки зрения лингвистики,перед нами одна лексема и несколько ее форм, а для токенизатора — несколько строк, которые еще и нарезаны по-разному.
Но связала ли модель эти формы между собой? На договоре ее сложно поймать; слово-то частое, все три варианта она могла запомнить по отдельности. В таком случае и делают wug-тест. Лингвист дает вымышленное, или его еще называют квазислово, wug, показывает зверька и сообщает только название существа, форму множественного числа ей не показывает. Потом зверьков становится два. Если модель отвечает wugs, значит, она перенесла на новое слово правило, знакомое по другим существительным. Подсмотреть готовый ответ было негде.
Ближе к глаголу
Вернемся к потерянному ключу:
Ключ от верхних ящиков потерялся.
Ключ от верхних ящиков потерялись.
Просить лингвисту модель объяснить свой выбор – бессмысленно. Объяснений она даст сколько угодно, в том числе неверных. Вместо этого языковед показывает одно начало фразы и сравнивает вероятности двух продолжений: грамматичного и неграмматичного. Потом меняет одну деталь и повторяет опыт. Это называется минимальной парой. Например:
Главное слово | Слово-приманка | Ожидаемая форма |
Ключ | Шкафа | Потерялся |
Ключ | Шкафов | Потерялся |
Ключи | Шкафа | Потерялись |
Ключи | Шкафов | Потерялись |
В первой и последней строках оба существительных требуют от глагола одной формы. В середине интереснее, подлежащее тянет глагол в свое сторону, дополнение — в другую. Если модель спотыкается на этом месте, значит, соседнее существительное и правда сбило ее с пути. Если ошибки появляются везде, синтаксис, возможно, ни при чем, например, лингвист предложил слово редкое или форму непривычную.
Начало предложения | Если модель держит связь с главным словом | Если модель смотрит на ближайшее существительное |
Ключ… | Ключ — ед. ч. → потерялся | Ключ — ед. ч. → потерялся |
Ключ от шкафа… | Ключ — ед. ч. → потерялся | Шкафа — ед. ч. → потерялся |
Ключ от шкафов… | Ключ — ед. ч. → потерялся | Шкафов — мн. ч. → потерялись |
Ключи от шкафа… | Ключи — мн. ч. → потерялись | Шкафа — ед. ч. → потерялся |
Ключ, который рабочие положили в шкафы… | Ключ — ед. ч. → потерялся | Шкафы — мн. ч. → потерялись |
После первой проверки ключ меняют на другие существительные, еще дальше отодвигают подлежащее и сказуемое, добавляют причастные и деепричастные обороты, чтобы закономерность не спутать с удачным ответом.
В кросс-языковом тесте CLAMS, куда вошел и русский, модели хорошо справлялись с простыми зависимостями, но заметно хуже — с согласованием через более сложные конструкции, в частности объектные относительные придаточные.
Это все еще проверка формы. Модель нашла слово, с которым надо согласовать глагол; поняла ли она саму сцену — другой вопрос. Можно безошибочно связать слова и все-таки перепутать, кто кому что передал. Тут синтаксис заканчивается, и начинается семантика.
Сравним:
Повар мелко нарезал лук.
Лучник туже натянул лук.
Мы выбираем значение, почти не замечая этого. У модели в таблице эмбеддингов для токена лук есть одна строка с числами; отдельного вектора для каждого значения не заведено. Но слово проходит через слои трансформера, внимание связывает его с предыдущим контекстом, и представление постепенно меняется. Рядом с поваром и нарезал получается одно скрытое состояние, рядом с лучником и натянул — другое.
Тут, естественно, хочется, спросить: а где разработчик сообщает модели, что первый лук едят, а из второго стреляют? На самом деле, нигде.
Во время базового обучения модель вообще не получает словарных толкований. Она пытается предсказать следующий токен и раз за разом обнаруживает, что у двух луков разное окружение. Нарезанный лук кладут в суп и жарят; натянутый связывают со стрелой и тетивой. Если модель смешивает эти продолжения, растет ошибка, веса немного меняются. Потом еще раз, и еще несколько миллиардов раз…
Лингвист начинает «издеваться» над моделью как раз, когда ее хороший ответ охота принять за понимание смысла. Например, модель выучила простое соседство: рядом с поваром выбирай овощ, рядом с лучником — оружие. Приходит лингвист и начинается:
Повар натянул спортивный лук.
Стрелок нарезал репчатый лук для супа.
Если модель смотрит только на профессию, она перепутает значения. Для правильного ответа еще надо учесть глагол, определение и всю ситуацию.
Потом проверка, сохраняется ли смысл при изменении порядка слов:
Повар позвал лучника.
Лучника позвал повар.
В обоих случаях звал повар, а дальше участников меняют местами:
Лучник позвал повара.
Теперь изменилось уже само событие. Такие примеры показывают, поняла ли модель, кто что сделал, или просто смотрит на порядок слов.
На этом этапе работа лингвиста – составить техническое задание. Он размечает роли, кто действует, на кого направлено действие и что сохранилось после перестановки слов. Из таких примеров разработчик собирает обучающую выборку или тест. Модель отвечает; ответ сравнивают с разметкой, ошибка понемногу меняет веса.
Готового правила, «кто позвал кого», в коде нет. Код задает способ учиться; лингвист следит, чтобы модель не отделалась удобной приметой, например, первое существительное всегда действует. Машина такие приметы любит.
После обучения от каждой новой фразы меняются внутренние представления слов. В предложении Лучника позвал повар модель должна связать повара с тем, кто зовет, а лучника — с тем, кого зовут. Если та же связь сохраняется с другими людьми, глаголами и порядком слов, можно осторожно сказать, что модель усвоила часть семантики.
Здесь холодно – это может быть обычное сообщение о температуре. Но если говорящий сидит у открытого окна и надевает свитер, мы слышим: окно надо закрыть, я замерз. Для нашего языка это норма, мы почему-то любим прятать просьбы в утверждения. «Что-то темно» – включи свет, «Чайник кипит» – надо выключить и т.д.
У фразы «здесь холодно» нет готовой расшифровки «закрой окно». Просьба появляется из ситуации: кто это сказал, кому и при каких обстоятельствах. Прагматика как раз изучает смысл, который не произнесли прямо, но собеседник все равно уловил.
Еще один пример — импликатура:
Некоторые тесты прошли.
Здесь не сказано, что остальные тесты провалились. Но мы обычно именно так и понимаем фразу: если бы прошли все, человек, вероятно, сказал бы все. Вывод «не все» и есть импликатура — смысл, который возник не из самих слов, а из выбора этих слов.
Такой намек можно отменить:
Некоторые тесты прошли. Точнее, все.
Первая фраза не ложная; говорящий лишь уточнил ее и снял наш первоначальный вывод. Этим импликатура и отличается от буквального значения: она зависит от ситуации и может исчезнуть после одной дополнительной фразы.
При базовом обучении модели никто дает в постскриптумах объяснение пользовательских намеков. Нейросеть предсказывает следующий токен и постепенно замечает, что после фразы «здесь холодно» в одних диалогах пользователи ищут рецепт горячего напитка. При настройке на инструкциях и человеческих предпочтениях полезные реакции получают дополнительное преимущество. Ответ «вот рецепт какао» тогда вероятнее ответа «спасибо за метеорологическое наблюдение».
Но правильная реакция еще не доказывает, что модель восстановила намерение. Возможно, она просто выучила частую пару: холодно → согреться. Модель знает о ситуации только то, что попало в ее контекст. Температуру в комнате она не чувствует и открытого окна не видит.
Здесь лингвист помогает разработчику превратить слово ситуация в набор наблюдаемых признаков. Кто говорит? Каковы его отношения с адресатом? Есть ли открытое окно? Может ли собеседник его закрыть? Была ли раньше просьба проветрить комнату? Разработчик решает, откуда получить эти данные и как передать их модели; лингвист следит, чтобы в датасете не осталось одной удобной дорожки к ответу.
Для проверки берут одну реплику и меняют только обстоятельства:
В кабинете открыто окно. Гость ежится и говорит хозяину: «Здесь холодно».
Здесь вероятна просьба закрыть окно.
Инженер проверяет холодильную установку и говорит коллеге: «Здесь холодно».
Теперь это скорее результат проверки.
В кабинете открыто окно. Гость говорит: «Здесь холодно, но не закрывай: я проветриваю».
Намек отменен самой следующей фразой.
Модели предлагают несколько толкований и сравнивают их вероятности. Потом меняют участников, помещение, социальные роли, формулировку; убирают слова окно и проветривать, чтобы они не служили готовой подсказкой. Свободное объяснение менее надежно, потому что модель может сочинить убедительную историю уже после того, как выбрала неверный смысл.
Человеку сообщают:
Маша сходила в кафе. Она там поела!
В кафе и так обычно едят, вторая фраза кажется лишней. В разговоре с другими людьми мы привыкли считать собеседника существом разумным (не всегда) и предполагаем, что лишнее сказано не просто так. Возможно, Маша обычно приходит в кафе только выпить кофе, а сегодня вдруг поела.
В эксперименте Kurch et al. модели знали, что обычно происходит в ресторане, и замечали лишнее уточнение. Но следующий шаг давался им хуже: они не всегда понимали, что говорящий подчеркнул очевидное с какой-то целью. Несколько готовых примеров помогали; стоило немного изменить их формулировку — и количество успешных ответов снижалось, то есть модель нередко повторяла знакомую схему, а не сам принцип.
Похожая трудность у LLM возникает, когда пользователь выбирает нарочито громоздкое выражение, например, «Я не то чтобы не знал». Почему он не скажет просто: «Я знал»? Возможно, говорящий уклоняется от прямого признания, смягчает ответственность или различает степени осведомленности. Сам способ выражения — тоже часть сообщения.
В другом исследовании проверяли, понимает ли модель, почему человек выбрал уклончивую фразу вместо прямой. Исследователи смотрели, какие продолжения она считает вероятными, как представляет фразы внутри и что отвечает на прямой вопрос. Простые различия модели замечали, а в более тонких случаях путали сказанное с тем, что слушатель лишь додумал.
Пока от модели нужен только хороший ответ, его можно оценить целиком. Но если мы хотим понять, какое правило она выучила и почему ошибается, нужен специалист. Он формулирует гипотезу, готовит серии примеров и продумывает контрольные условия. Разработчик переводит этот план в код, получает logprobs или внутренние представления модели и считает результат. Дальше разберем, что же делает лингвист с подопечной моделью:
Вспомним предложение:
Ключ от верхних ящиков...
Лингвиста интересуют только два продолжения: потерялся и потерялись. Самый вероятный токен во всем словаре здесь не так важен. Лингвист заранее выбрал спор, который должна разрешить модель.
API может вернуть логарифмы вероятностей, или logprobs, для обеих форм. Если слово разбилось на несколько токенов, оценки его частей складывают:
Здесь (c) — начало предложения, а (t_i) — токены проверяемого слова. Логарифмы – это обычное правило цепочки из теории вероятностей в удобной для вычислений форме.
Чем итог ближе к нулю, тем вероятнее продолжение. Например, −1,2 выше, чем −3,7. Если большую оценку получило потерялся, модель предпочла согласовать глагол с ключом. Если победило потерялись, ее, вероятно, отвлекли ближайшие ящики.
Нужные глаголы, как назло, могут не попасть в top-5. API покажет первые пять вариантов, а дальше — неизвестно. Может быть, потерялся стоит шестым, а потерялись сотым. Может быть, наоборот, мы этого не знаем.
Для лингвиста результат в таком случае не плохой, а отсутствующий. Он не может сказать, что модель ошиблась, если ему просто не отдали числа, ради которых ставили опыт. Значит, разработчику надо отдельно получить оценку каждой формы. Если API этого не умеет, придется менять способ проверки. Прямой вопрос «какой вариант правильный?» тоже годится, но это уже задача с подсказанными ответами, и нельзя считать результат чистым.
После фразы:
Он намазал хлеб…
модель ждет мазутом гораздо меньше, чем маслом. Степень этой неожиданности называют surprisal:
У маслом вероятность выше, поэтому surprisal ниже. У мазутом вероятность меньше, а неожиданность больше. Никакой новой величины поверх вероятности тут нет: это та же оценка, записанная в удобном для сравнения виде.
Задача лингвиста — решить, на каком слове измерять неожиданность и какие продолжения сопоставить, после чего он составляет целую серию примеров. Иначе есть риск выяснить только то, что модель часто встречала рядом хлеб и масло. Чтобы проверить более общее языковое ожидание, нужны другие глаголы, предметы и странные, но грамматически допустимые продолжения.
В психолингвистике surprisal сравнивают со временем чтения: неожиданные слова человек в среднем читает дольше. В работе Goodkind и Bicknell оценки более точных языковых моделей лучше предсказывали задержки при чтении.
В продуктовом промпте щедрость уместна: инструкция, примеры, весь полезный контекст. Пусть модели будет легче, пользователю ведь нужен ответ. В эксперименте та же щедрость может все погубить. Добавили подсказку — добавили еще одну возможную причину результата. И потом сиди, разбирай.
Отсюда и минимальные пары, с которыми мы уже встречались в таблице выше. Лингвист берет два примера и убирает между ними все различия, кроме одного. Изменилась реакция модели — круг подозреваемых невелик. В идеале он вообще состоит из одного признака.
Каждый пример получает небольшой паспорт: что в нем проверяется, какие формы нужно оценить, где находится критическое слово. Например:
item_id = letter_01
число_помехи = множественное
критические_формы = пришло / пришли
У парного примера останется тот же item_id, но значение поля число_помехи сменится на единственное. Все остальное лингвист просит сохранить: слова, порядок, длину конструкции. Поля скучные. В том и польза.
Так можно отдельно проверить число, падеж, одушевленность, отрицание или расстояние между связанными словами. Весь датасет может содержать много признаков; внутри одного сравнения движется только один. Иначе вероятность изменится, но причину никто не узнает. Потом одна и та же схема заполняется другими словами. Вместо письма появляются отчет, запах, список, фотография — десятки или сотни вариантов. Для каждого item_id код сначала считает разницу между двумя условиями, и только потом результаты объединяют. Это важно: несколько особенно удачных фраз могут вытянуть среднее и создать видимость общего правила.
Лингвист следит и за тем, как примеры попадают к модели. Если отправить их подряд в одном диалоге, предыдущие фразы сами станут подсказкой. Поэтому запросы делают независимыми либо сохраняют для всех одинаковый контекст. Разработчик закрепляет это в коде вместе с версией модели, шаблоном запроса и фактической токенизацией.
У знакомого слова тянется за ним целая биография: тексты, устойчивые сочетания, готовые формы. И попробуй потом пойми, вывела модель правило или вспомнила слышанное. Лингвисту для такого случая нужны слова без прошлого, например:
Один нип осторожно замифрил.
Два нипа осторожно замифрили.
Что такое нип, не знает даже сам лингвист. Чем занимаются, когда замифривают, тоже. Зато грамматических подсказок здесь полно: Один задает единственное число; два нипа требует во множественном числе сказуемого. Если модель предпочитает замифрил в первой фразе и замифрили во второй, значит, знакомую схему она смогла перенести на незнакомые основы. По крайней мере, это объяснение уже правдоподобнее простой памяти.
Так же устроена знаменитая фраза академика Щербы:
Глокая куздра штеко будланула бокра и курдячит бокренка.
Лексические значения выдуманы, но окончания выдают многое: где действие, кто его совершил, с кем что произошло. Семантика не исчезла совсем — мы все-таки достраиваем некоторую сцену, — но привычные значения слов больше не помогают. Остался один голый грамматический каркас.
Одного нипа для опыта мало, вдруг модель связала его с фамилией, аббревиатурой или редким словом из обучающего корпуса? Чтобы минимизировать риск, лингвист готовит целое семейство искусственных основ. Они должны подчиняться фонологии русского языка, нормально склоняться и спрягаться, но не совпадать с известными словами.
Разработчик получает список псевдослов, их грамматические признаки и формы для сравнения. Есть и старая токенизаторная неприятность: новое слово почти наверняка разрежет на несколько частей. Значит, оценивать придется всю последовательность, а не первый попавшийся кусок. Ведь у нипа нет биографии. А грамматика уже есть — ее-то и проверяют.
Допустим, в предложении “письмо от бухгалтера …” модель выбрала форму пришло. Мы спрашиваем почему и получаем безупречный ответ: сказуемое согласуется с главным словом письмо, а не с зависимым бухгалтера. Это верно, но объяснение модель генерирует уже после выбора. Саму форму могла предпочесть из-за структуры предложения, частоты сочетания или ближайшего существительного, а потом подобрать к ней подходящее правило. Объяснять свои решения модель умеет примерно так же, как отвечать на остальные вопросы: убедительно, но не всегда точно. У лингвиста самообъяснение — отдельная задача.
В таких случаях смотрят внутренние представления. Модель замораживают, собирают активации и обучают на них небольшой диагностический классификатор, или probe. Его задача – определить по внутреннему вектору часть речи, число слова либо его положение в синтаксическом дереве.
В работе Hewitt и Manning таким способом исследовали представления ELMo и BERT. Авторы нашли линейное преобразование, после которого расстояния между векторами отражали расстояния между словами в дереве зависимостей, а нормы векторов — глубину узлов. Синтаксическую структуру из представлений можно было восстановить.
Соблазн велик: вот же она, грамматика, лежит внутри. Но извлечь информацию и использовать ее при генерации — не одно и то же. Диагностический классификатор может оказаться способнее исследуемого представления и сам выучить нужную зависимость.
Это проверяли с помощью контрольных задач. Словам случайным образом назначали метки, в которых по определению не было языкового правила. Если классификатор успешно запоминал и их, высокая точность на частях речи уже выглядела не столь убедительно. В исследовании Hewitt и Liang несколько распространенных классификаторов действительно показали слабую избирательность: они хорошо решали языковую задачу, но заодно неплохо справлялись со случайной.
Лингвист поэтому заранее задает не только признак для извлечения, но и контроль: что классификатор не должен уметь, если действительно читает информацию модели, а не приносит решение с собой. Разработчик обучает классификаторы разной сложности и сравнивает их на основной и случайной разметке.
Более сильный ход — вмешаться в вычисление. Можно отключить часть компонентов, подменить активации между двумя примерами (activation patching) или заменить представление числа в выбранном слое. Потом снова измерить вероятности форм. Если после подмены модель предпочла другое согласование, у языковедов появляется причинная связь: изменили внутреннее состояние — изменилось поведение.
Мой сосед по коворкингу, разработчик, посмотрел мой черновик и сказал: «Это все очень интересно, но зачем это нам?». Действительно, морфология и семантика – это вайб филфака, которое зачем-то принесли в разработку. Но лингвистический разбор для тех, кто пилит ИИ в свой продукт, довольно полезный, он дает ошибке адрес, как сотрудник почты – индекс письму.
Встречали фразу «ИИ плохо работает с русским языком»? Для команды разработчиков она почти бесполезна. Пока все это называется качеством, править приходится на ощупь. Как может лингвистика помочь продукту:
Хотя бы первая разбивка на ошибки может выглядеть так:
Уровень | Что проверять в продукте | Типичная поломка |
Графика и токенизация | Опечатки, регистр, редкие имена, смешение алфавитов | Одна небольшая правка резко меняет ответ |
Морфология | Склонение, согласование, новые термины | Частое слово оформляется верно, новое — нет |
Синтаксис | Роли участников, отрицание, дальние зависимости | Модель связывает сказуемое с ближайшим существительным |
Семантика | Перефразирование, выводы, значения многозначных слов | Фраза остается гладкой, смысл меняется |
Прагматика | Намерение, вежливость, косвенные просьбы | Буквальный ответ там, где ожидалось действие |
Дискурс | Местоимения, временная линия, условия из разных частей документа | Теряется референт или ограничение из середины контекста |
Лингвист размечает ошибки по этим уровням и составляет для каждого отдельные тесты. Разработчик добавляет к примеру входные данные, ожидаемый результат и тип поломки. В отчете может быть уже не «73% качества языка», а, скажем, нормальная работа с падежами и заметный провал на отрицаниях. С этим уже можно предметно работать.
2. Проверять не только опечатки.
Устойчивость часто испытывают опечатками. Но пользователь способен выразить ту же мысль иначе, перестроить предложение. Вот тут модели нередко и начинают чудить.
В работе модели проверяли с помощью контролируемых изменений на разных уровнях языка. Результат зависел от задачи, но естественные синтаксические и стилевые переделки, особенно отрицание, часто вредили сильнее, чем искусственная порча букв. Увеличение модели лучше помогало против поверхностного шума, чем против некоторых содержательных изменений.
Для продукта из этого следует, что тест должен быть похож не только на нормальную человеческую речь. К одному запросу добавлять перефразировки, менять порядок слов, активную конструкцию на пассивную, прямое утверждение на отрицание.
Когда модель ошибается, велик соблазн дописать в системную инструкцию: «будь внимательна», «не пропускай отрицания».
Но разные уровни языка требуют разных решений. Редкое имя развалилось при токенизации — помогут нормализация, словарь вариантов или другая модель, а не наставление о внимательности. Если условие потерялось в длинном документе, то нужно проверять разбиение текста, поиск фрагментов и способ передачи контекста.
В общем, все это описанное филологическое занудство, конечно, не поможет разрабочтикам напрямую. Но может сделать более скромную вещь: карту ошибок, набор воспроизводимых тестов и зацепку, на каком уровне искать баг.