Comments 6
Зачем высирать столько нейрослопа?
Пересчитала ансамбль судей в абсолютных числах: одиночный GPT-5.5 дает 0.80 на всех 40 примерах, это 32 верные метки; трое из четырех — 0.83 при покрытии 90%, то есть около 30, а единогласие — 0.96 при 68%, уже 26. Точность растет, а верно размеченных случаев становится меньше, причем воздержание приходится ровно на спорную атрибуцию. Отдельно смущает, что E1-E40 — те же проработанные примеры, на которых таксономию и собирали, а судьям выдали и определения, и первоисточник: 0.76 тогда меряет воспроизводимость разметки, а не перенос на незнакомые отказы. В статье есть прогон судей на примерах, не участвовавших в построении каталога?
Пересчитал ещё раз - да, всё верно: 32, примерно 30 и 26 верных меток. Точность растёт, полнота падает (0.80, потом примерно 0.75 и 0.65), и воздержание действительно попадает на самые спорные случаи. Это ровно тот размен из таблицы 4 первоисточника, авторы сами пишут о нём в ограничениях.
Второй пункт - самый сильный, и вы правы. Проверил по первоисточнику: примеры, по которым собирали каталог, там прямо названы тем же набором, на котором проверяли судей. Нюанс один: авторы и сами называют это воспроизводимостью разметки (operational reproducibility), а не переносом на новые случаи, и судьям закрыли доступ к готовым разборам и человеческим меткам - они читали только исходные материалы. Но прогона судей на примерах, не участвовавших в построении каталога, в статье действительно нет: судьи работали только с этими сорока.
Внёс правку в текст с пометкой UPD: 0.76 - это воспроизводимость разметки на корпусе разработки, а не оценка переноса на незнакомые отказы.
Позволю себе покритиковать Вас. То, что вы строите, упирается в архитектуру любой ллм - неопределённость - им нельзя давать волю брать куски юридических текстов напрямую. Но это решаемо. Если тащить не текст из документа напрямую, а потребовать от модели брать номер строки, где этот текст находится, - это будет стабильно работать. И неважно, это будет клод или другая модель попроще, остальное - относительно несложная работа с текстами, только нужно построить поток грамотного разбития на чанки (ввиду больших объёмов) и сделать конвейер под это. Задача абсолютно реализуемая с практически любой более менее смышлёной LLM, в том числе с локальными. Да, тут нужны скрипты - на них всё будет держаться. Но выбор модели вторичен, если один раз правильно написать код, потом вообще не важно будет какая модель будет сопоставлять и суммаризировать тексты.
Направление верное - и ровно так в конвейере и сделано: модель обязана дать ссылку вида «СП 1.13130.2020, п. 5.2.15» и дословную цитату, дальше детерминированный валидатор (без LLM) проверяет: документ в реестре, редакция действующая, пункт существует, цитата входит в базу дословно. Провал - статус needs_human, дорогой вердиктирующий вызов не происходит вовсе.
Но «номер строки - и стабильно» - оптимизм. Номер строки это такой же сгенерированный токен, как цитата: модель промахивается на N строк так же охотно, как выдумывает текст. И промах по номеру строки даёт гарантированно дословную цитату не того места — ошибка становится тише, а не реже. Вариант «цитата + сверка» хотя бы шумит при промахе.
«Неважно, какая модель сопоставляет» - тоже не так: анкеринг гарантирует неизвращение выбранного фрагмента, но не правильность выбора. А «остальное - несложная работа с текстами» - ровно тот слой, где у меня жили худшие отказы: молча потерянные 34% базы и ложно-зелёные метрики случились без участия модели вообще.
Кто на самом деле сломал вашего ИИ-агента: модель или обвязка?