Шероховатости модели jev-1.13

Jev не идеален. Здесь описаны известные нам шероховатости и ограничения модели jev-1.13. Многие из них будут исправлены в следующих версиях.

Модель jev-1.13 быстра, откалибрована и отлично справляется со здравыми суждениями (common-sense judgment), но она не идеальна. jev-1.13 лучше всего решает задачи System One. Она может испытывать трудности с задачами, требующими дополнительных уровней косвенности (indirection). Она может быть весьма буквальной в понимании текста. Также она испытывает сложности с задачами, требующими числовой точности.

Подробный обзор паттернов сбоев

Буквальное прочтение (Literal reading)

jev-1.13 отвечает именно на тот вопрос, который вы написали, а не на тот, который вы имели в виду. Ограничивающие слова, отрицания и подразумеваемые условия воспринимаются буквально. Ответ формируется строго по тексту инструкции, тогда как человек мог бы догадаться о скрытом намерении.

Что делать вместо этого: формулируйте точное условие в instructions. Будьте конкретны. Описывайте граничные случаи в критериях. Если при взгляде на неверный ответ вы начинаете объяснять, что вы «на самом деле имели в виду», — это объяснение как раз и является недостающей частью инструкции. Там, где интерпретации избежать невозможно, разбейте задачу на два буквальных вопроса и объедините результаты в коде.

Математика и числа (Math and Numbers)

Jev — это не калькулятор. Мы настоятельно рекомендуем реализовывать любую математическую логику в коде. Jev справляется с семантическими вопросами намного лучше, чем с математическими.

Подсчет элементов (Counting)

jev-1.13 ненадежно считает количество элементов. Это касается подсчета символов в слове, вхождений термина в текст или количества пунктов в длинном списке. Модель распознает общий паттерн ответа, а не ведет строгий подсчет, и погрешность растет пропорционально размеру подсчитываемого объекта.

Прежде чем задавать вопрос на подсчет, спросите себя: зачем для подсчета вообще нужна нейросетевая модель? Если единицу можно найти с помощью регулярного выражения или парсера, подсчет должен выполняться в коде, и модели здесь нечего добавить.

Что делать вместо этого: считайте в коде. Если вам нужно подсчитать элементы, соответствующие определенным критериям, переберите кандидатов в цикле в коде, задайте по одному вопросу для каждого элемента, а затем просуммируйте положительные ответы.

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # порог вы выбираете сами в зависимости от сценария использования.

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

Числовые представления (Numeric representations)

jev-1.13 работает лучше с семантическими описаниями, чем с числовыми значениями. Например, вопросы о цветах с использованием шестнадцатеричных hex-кодов покажут меньшую точность, чем вопросы с естественными названиями цветов на английском языке. Получив RGB-триплеты или hex-значения, модель не сможет надежно оценить, близки ли два цвета друг к другу.

Аналогично, вопросы о высокоуровневых языках программирования обрабатываются гораздо точнее, чем вопросы о низкоуровневом ассемблере или бинарных инструкциях.

Что делать вместо этого: выполняйте конвертацию в коде и передавайте в модель либо вычисленное значение, либо именованную категорию (bucket). Оставляйте модели только ту часть, которая действительно требует смыслового суждения — например, воспринимается ли цвет как предупреждающий.

Вычисления с использованием Score

Пожалуйста, не используйте числовые выходы Score (например, математическое ожидание и вероятности) для вычисления точной величины числа между двумя уровнями критерия. Вы можете использовать математическое ожидание для проверки превышения порога, однако уровни шкалы Score в jev-1.13 не предназначены для точной числовой калибровки. Модель не поможет вам восстановить точное число путем интерполяции между двумя ближайшими уровнями.

Сравнение дат и времени (Date and time comparison)

jev-1.13 воспринимает даты как текст, а не как упорядоченные временные величины. Вопросы о том, какая из двух дат наступает раньше, каково расстояние между ними или попадает ли дата в заданный интервал, обрабатываются ненадежно. Ситуация ухудшается при смешении форматов, относительных ссылках и предметных интервалах (кварталы, расчетные периоды и периоды начисления).

Что делать вместо этого: разделяйте задачи. Извлечение сущностей — это смысловое суждение, поручите его модели. Арифметика — нет, поэтому оставьте её коду.

Каждая часть даты представляет собой небольшое замкнутое множество: двенадцать месяцев, тридцать один день, ограниченный диапазон лет. Это превращает извлечение даты в вопрос Choice по перечисляемым вариантам вместо неструктурированного парсинга, а также позволяет добавить явный вариант «не указано», чтобы об отсутствии данных сообщалось явно, а не путем догадок. Затем код собирает извлеченные части в реальный объект даты и берет на себя все последующие операции: упорядочивание, длительность, смещение и день недели.

В руководстве по извлечению дат (date extraction cookbook) разобран готовый пример, включая относительные даты и контроль по уверенности.

Косвенность (Indirection)

Инструкции с двойными отрицаниями или сложными цепочками косвенных связей обрабатываются менее надежно. Вопрос о свойстве свойства или задача, требующая нескольких логических переходов (hops), снижает итоговую точность.

Что делать вместо этого: пишите инструкции максимально прямо и лаконично. По возможности указывайте на нужные части состояния по именам.

Большое состояние с избыточными деталями (Large state full of irrelevant detail)

Точность снижается по мере роста объема state за счет информации, не относящейся к принимаемому решению. Нерелевантные подробности действуют как отвлекающие факторы (distractors), а большой объем состояния затрудняет локализацию причины ошибочного ответа.

Что делать вместо этого: сначала извлекайте и фильтруйте данные в коде, передавая в state только те поля, которые действительно необходимы для ответа на вопрос. Если отфильтровать данные заранее невозможно, используйте вопрос Noul для проверки релевантности. Готовый пример см. в руководстве по классификации фрагментов для RAG.

Состязательный контент (Adversarial content)

Поле state — это данные, и jev-1.13 по умолчанию не считает их враждебными. Контент, составленный с целью намеренного манипулирования моделью (инъекции инструкций, заведомо вводящие в заблуждение формулировки или текст, настаивающий на определенной классификации), может сместить ответ модели. Мы планируем улучшить защиту от подобных атак в будущих версиях.

Что делать вместо этого: детально и однозначно прописывайте критерии. Тщательно тестируйте интеграцию перед запуском на реальных пользователях.

Противоречивые инструкции и критерии (Contradictory instructions and criteria)

Когда instructions и criteria требуют противоположных вещей, jev-1.13 может запутаться. Наивысшая точность достигается при однозначных формулировках. Например, вопрос Noul, в котором true означает «нет», а false означает «да», будет работать существенно хуже. Стремитесь к тому, чтобы формулировки были понятны любому человеку без специальной подготовки.

Что делать вместо этого: рассматривайте критерии как прямое продолжение инструкции. Согласовывайте их между собой, используя понятный и точный язык.

Инварианты здравого смысла (Common-sense structural invariants)

Модель jev-1.13 чрезвычайно согласованна (consistent), то есть для семантически похожих входных данных следует ожидать количественно близкие выходы.
Однако существует множество структурных инвариантов, которые кажутся очевидными человеку, но не гарантируются моделью автоматически.

Например, вопрос «Просит ли клиент о возврате средств?», заданный как Noul и как вопрос «да/нет» через Choice для тикета «Мне не подошел размер. Какие у меня есть варианты?»:

Сопоставимыми значениями здесь являются noul и probabilities["yes"], и нет однозначного математического правила прямого пересчета результата Choice и его уверенности в ответ Noul или наоборот.

Тот же вопрос и его отрицание: «Просит ли клиент о чем-то, кроме возврата средств?», заданные как два независимых вопроса Noul для тикета «С меня списали оплату за один заказ дважды. Разберитесь, пожалуйста»:

Существует множество математических и вероятностных причин, почему P(noul) и 1 - P(not noul) могут напрямую не складываться в единицу.

Что делать вместо этого: не полагайтесь на ожидаемую структурную инвариантность и формулируйте вопросы так, чтобы они прямо отражали требуемый результат. Не переносите порог, настроенный для Noul, на вопрос Choice, и не требуйте от модели строгого соблюдения арифметических равенств между несвязанными вопросами. Вопрос Choice по набору вариантов и отдельные вопросы Noul для каждого варианта решают разные задачи: Choice относителен и определяет, какой именно вариант наиболее вероятен, тогда как каждый Noul абсолютен и может иметь низкую вероятность для всех вариантов сразу. В руководстве по рекомендации навыков оба подхода используются на одном списке: Choice выбирает конкретный навык, а Noul решает, стоит ли рекомендовать хоть какой-то навык вообще.

Генерация текста (Generation)

jev-1.13 не обучалась для свободной генерации текста. Хотя модель можно заставить выдавать текст через последовательные цепочки Choice, это будет работать нестабильно и очень медленно. Для извлечения данных лучше извлечь кандидаты с помощью регулярных выражений или генеративной модели, а выбор правильного варианта доверить jev-1.13.

Что делать вместо этого: если пространство возможных ответов ограничено, превратите извлечение данных в вопрос Choice по списку вариантов вместо генерации значения с нуля. А если вам действительно требуется генерировать связный текст... для этого существуют другие модели.