Пересчитал ещё раз - да, всё верно: 32, примерно 30 и 26 верных меток. Точность растёт, полнота падает (0.80, потом примерно 0.75 и 0.65), и воздержание действительно попадает на самые спорные случаи. Это ровно тот размен из таблицы 4 первоисточника, авторы сами пишут о нём в ограничениях.
Второй пункт - самый сильный, и вы правы. Проверил по первоисточнику: примеры, по которым собирали каталог, там прямо названы тем же набором, на котором проверяли судей. Нюанс один: авторы и сами называют это воспроизводимостью разметки (operational reproducibility), а не переносом на новые случаи, и судьям закрыли доступ к готовым разборам и человеческим меткам - они читали только исходные материалы. Но прогона судей на примерах, не участвовавших в построении каталога, в статье действительно нет: судьи работали только с этими сорока.
Внёс правку в текст с пометкой UPD: 0.76 - это воспроизводимость разметки на корпусе разработки, а не оценка переноса на незнакомые отказы.
Направление верное - и ровно так в конвейере и сделано: модель обязана дать ссылку вида «СП 1.13130.2020, п. 5.2.15» и дословную цитату, дальше детерминированный валидатор (без LLM) проверяет: документ в реестре, редакция действующая, пункт существует, цитата входит в базу дословно. Провал - статус needs_human, дорогой вердиктирующий вызов не происходит вовсе.
Но «номер строки - и стабильно» - оптимизм. Номер строки это такой же сгенерированный токен, как цитата: модель промахивается на N строк так же охотно, как выдумывает текст. И промах по номеру строки даёт гарантированно дословную цитату не того места — ошибка становится тише, а не реже. Вариант «цитата + сверка» хотя бы шумит при промахе.
«Неважно, какая модель сопоставляет» - тоже не так: анкеринг гарантирует неизвращение выбранного фрагмента, но не правильность выбора. А «остальное - несложная работа с текстами» - ровно тот слой, где у меня жили худшие отказы: молча потерянные 34% базы и ложно-зелёные метрики случились без участия модели вообще.
по корнер-кейсам согласен, лимита на размер письма и таймаута на чтение в текущей версии нет, raw_bytes растёт неограниченно пока не придёт терминатор. это реальная дыра, поправлю.
по imap idle не соглашусь. там нужно хранить логин и пароль пользователя от его почты, это принципиально другой уровень риска и ответственности, чем форвардинг на служебный адрес, где я вообще не вижу и не храню чужие credentials. плюс это отдельное живое соединение на каждого юзера к чужому imap-серверу, с чужими лимитами и обрывами, у меня таких юзеров сотни.
по готовому exim в докере тоже не соглашусь. очередь, ретраи, dkim, spf, конфиги под виртуальные домены, systemd-юниты, логротейт, это тоже зоопарк функциональности со своими корнер-кейсами, просто чужими. для задачи "принять письмо на известный адрес и переслать его конкретному юзеру" это избыточно.
про то что человек всё равно бутылочное горлышко, тут отчасти согласен, это уже вопрос приоритетов а не архитектуры. но даже если финальный ответ фрилансера займёт минуты, скорость самого уведомления имеет смысл сама по себе, кто увидел заказ на минуту раньше конкурента, у того выше шанс успеть откликнуться первым.
насчёт окон и hol, тут по делу, per-stream окно я не учёл, а hol на уровне tcp и правда никак не лечится склейкой файлов, раз всё идёт через одно соединение. если честно, объяснял это тогда интуицией, а не разбором механизма, и явных доказательств что склейка что-то ускорила у меня нет, кроме сокращения числа отдельных http-запросов. cdn был единственным подтверждённым фиксом, и он закрыл проблему полностью сам по себе. надо было в статье сразу так и написать, а не пытаться подкрепить довесок теорией которая не выдерживает проверки. поправил блок в статье, спасибо
про clienthello - тут да, обычные девтулзы этого не покажут. смотрели через chrome://net-internals на компе у одного из юзеров, там видно что рвётся именно на этапе рукопожатия.
про склейку бандла - справедливое замечание. cdn там и правда основной фикс, он закрыл проблему с каналом полностью, а склейка бандла это уже была доп подстраховка сверху, не более того. решение принято в 2 ночи, без замеров до/после именно на cdn, чисто чтобы убрать лишнюю точку отказа раз уж всё равно копался в сети. если бы это был единственный фикс без cdn, я бы сначала померил. по мере роста проекта вернём нормальный vendor-chunking, но пока для моего масштаба (нечастые деплои, небольшое приложение) склейка себя оправдывает.
про ech в tls 1.3 - на сервере его не включали, но провайдеры у нас его реально режут наглухо. вполне вероятно что у части юзеров браузер пытался подтянуть ech и соединение тупо падало на clienthello.
про http2 согласен, я там уже обновил и переписал этот блок в статье. при http2 соединение одно и мультиплексирование работает. проблема была именно в качестве самого канала до зарубежного ип. при потере пакетов на плохом канале проявляется head-of-line blocking и пачка стримов начинает отваливаться по таймаутам. плюс внешняя зависимость telegram.org зависала сама по себе.
переезд на московские ноды selectel cdn как раз и закрыл проблему с каналом. а склейка бандла была уже вторичной историей чтобы убрать лишние rtt.
Пересчитал ещё раз - да, всё верно: 32, примерно 30 и 26 верных меток. Точность растёт, полнота падает (0.80, потом примерно 0.75 и 0.65), и воздержание действительно попадает на самые спорные случаи. Это ровно тот размен из таблицы 4 первоисточника, авторы сами пишут о нём в ограничениях.
Второй пункт - самый сильный, и вы правы. Проверил по первоисточнику: примеры, по которым собирали каталог, там прямо названы тем же набором, на котором проверяли судей. Нюанс один: авторы и сами называют это воспроизводимостью разметки (operational reproducibility), а не переносом на новые случаи, и судьям закрыли доступ к готовым разборам и человеческим меткам - они читали только исходные материалы. Но прогона судей на примерах, не участвовавших в построении каталога, в статье действительно нет: судьи работали только с этими сорока.
Внёс правку в текст с пометкой UPD: 0.76 - это воспроизводимость разметки на корпусе разработки, а не оценка переноса на незнакомые отказы.
Направление верное - и ровно так в конвейере и сделано: модель обязана дать ссылку вида «СП 1.13130.2020, п. 5.2.15» и дословную цитату, дальше детерминированный валидатор (без LLM) проверяет: документ в реестре, редакция действующая, пункт существует, цитата входит в базу дословно. Провал - статус needs_human, дорогой вердиктирующий вызов не происходит вовсе.
Но «номер строки - и стабильно» - оптимизм. Номер строки это такой же сгенерированный токен, как цитата: модель промахивается на N строк так же охотно, как выдумывает текст. И промах по номеру строки даёт гарантированно дословную цитату не того места — ошибка становится тише, а не реже. Вариант «цитата + сверка» хотя бы шумит при промахе.
«Неважно, какая модель сопоставляет» - тоже не так: анкеринг гарантирует неизвращение выбранного фрагмента, но не правильность выбора. А «остальное - несложная работа с текстами» - ровно тот слой, где у меня жили худшие отказы: молча потерянные 34% базы и ложно-зелёные метрики случились без участия модели вообще.
Можно поконкретнее?
по корнер-кейсам согласен, лимита на размер письма и таймаута на чтение в текущей версии нет, raw_bytes растёт неограниченно пока не придёт терминатор. это реальная дыра, поправлю.
по imap idle не соглашусь. там нужно хранить логин и пароль пользователя от его почты, это принципиально другой уровень риска и ответственности, чем форвардинг на служебный адрес, где я вообще не вижу и не храню чужие credentials. плюс это отдельное живое соединение на каждого юзера к чужому imap-серверу, с чужими лимитами и обрывами, у меня таких юзеров сотни.
по готовому exim в докере тоже не соглашусь. очередь, ретраи, dkim, spf, конфиги под виртуальные домены, systemd-юниты, логротейт, это тоже зоопарк функциональности со своими корнер-кейсами, просто чужими. для задачи "принять письмо на известный адрес и переслать его конкретному юзеру" это избыточно.
про то что человек всё равно бутылочное горлышко, тут отчасти согласен, это уже вопрос приоритетов а не архитектуры. но даже если финальный ответ фрилансера займёт минуты, скорость самого уведомления имеет смысл сама по себе, кто увидел заказ на минуту раньше конкурента, у того выше шанс успеть откликнуться первым.
насчёт окон и hol, тут по делу, per-stream окно я не учёл, а hol на уровне tcp и правда никак не лечится склейкой файлов, раз всё идёт через одно соединение. если честно, объяснял это тогда интуицией, а не разбором механизма, и явных доказательств что склейка что-то ускорила у меня нет, кроме сокращения числа отдельных http-запросов. cdn был единственным подтверждённым фиксом, и он закрыл проблему полностью сам по себе. надо было в статье сразу так и написать, а не пытаться подкрепить довесок теорией которая не выдерживает проверки. поправил блок в статье, спасибо
про clienthello - тут да, обычные девтулзы этого не покажут. смотрели через chrome://net-internals на компе у одного из юзеров, там видно что рвётся именно на этапе рукопожатия.
про склейку бандла - справедливое замечание. cdn там и правда основной фикс, он закрыл проблему с каналом полностью, а склейка бандла это уже была доп подстраховка сверху, не более того. решение принято в 2 ночи, без замеров до/после именно на cdn, чисто чтобы убрать лишнюю точку отказа раз уж всё равно копался в сети. если бы это был единственный фикс без cdn, я бы сначала померил. по мере роста проекта вернём нормальный vendor-chunking, но пока для моего масштаба (нечастые деплои, небольшое приложение) склейка себя оправдывает.
про ech в tls 1.3 - на сервере его не включали, но провайдеры у нас его реально режут наглухо. вполне вероятно что у части юзеров браузер пытался подтянуть ech и соединение тупо падало на clienthello.
про http2 согласен, я там уже обновил и переписал этот блок в статье. при http2 соединение одно и мультиплексирование работает. проблема была именно в качестве самого канала до зарубежного ип. при потере пакетов на плохом канале проявляется head-of-line blocking и пачка стримов начинает отваливаться по таймаутам. плюс внешняя зависимость telegram.org зависала сама по себе.
переезд на московские ноды selectel cdn как раз и закрыл проблему с каналом. а склейка бандла была уже вторичной историей чтобы убрать лишние rtt.