Вы продвинулись чуть дальше, чем я. С очередью на ручной резолв я пока что ничего не предпринимал, чесались бы руки сразу же какую ниб мл инструмент поставить, но мысленно ударив по рукам себе, то я бы пошел по пути калибровки(после сбора данных что там по итогу проставляется после ручной проверки), посмотрел бы что там за классы получаются. В сухом остатке, моя мысль в том, что если накапливается большая очередь на ручной резолв, значит нужно делать роутинг, так как видимо попадают в очередь по природе разные случаи. Хах, я бы в итоге все таки подключил какой ниб катбуст или логрег, которая бы определялал классы, и прогнозы строила. Если семанттика нужна, наверное, подумал бы о берте. Лично я, пока что не накопил данных по нашему проекту, мне только предстоит видимо с этим столкнуться. Спасибо за вопрос, мысленный эксперимент провел )
ну нода судьи для циклических задач выглядит естественно, но я бы не давал ей напрямую управлять бесконечным возвратом задачки. Судья ведь может вернуть типизированный результат. Вы можете добавить что то типа Контроллера самого цикла, который будет обязан хранить чисто попыток, лимиты бюдета и репорты слать. Иначе 2 вероятностных агента могут долго возвращать работу друг другу, каждый раз немного меняя формулировку, но не устраняя сам дефект.
да, для живого ллм адаптера строгая json-ка была бы полезна, тот же equivalent, extracted,reason с фикс типами и энамчиком. В текущем виде в репо намернно не вызывается, просто используются записанные json ответы. Но вот что сразу можно заметить: 1. json схема решает ведь только синтаксическую часть. Моделька все еще может вернуть совершенно валидный json с выдуманным "extracted=3/4" для ответа "не знаю" (это если в контексте описанных в статье примера). Поэтому json -схему я бы рассматривал как входной фильтр перед гейтом, а не как замену детерминированной проверки 2. Насчет смещения интуция дельная. Я бы проверял это на аб тестах на одном калибров.сете, где свободный ответ противопоставлял бы строгой схеме, а затем сравнил бы конфужн матрицу, каппу и долю ручной проверки. Кстати, я скорей всего, так и сделаю и результаты опубликацию как продолжение статьи, спасибо!
Вы продвинулись чуть дальше, чем я. С очередью на ручной резолв я пока что ничего не предпринимал, чесались бы руки сразу же какую ниб мл инструмент поставить, но мысленно ударив по рукам себе, то я бы пошел по пути калибровки(после сбора данных что там по итогу проставляется после ручной проверки), посмотрел бы что там за классы получаются. В сухом остатке, моя мысль в том, что если накапливается большая очередь на ручной резолв, значит нужно делать роутинг, так как видимо попадают в очередь по природе разные случаи. Хах, я бы в итоге все таки подключил какой ниб катбуст или логрег, которая бы определялал классы, и прогнозы строила. Если семанттика нужна, наверное, подумал бы о берте. Лично я, пока что не накопил данных по нашему проекту, мне только предстоит видимо с этим столкнуться. Спасибо за вопрос, мысленный эксперимент провел )
ну нода судьи для циклических задач выглядит естественно, но я бы не давал ей напрямую управлять бесконечным возвратом задачки. Судья ведь может вернуть типизированный результат. Вы можете добавить что то типа Контроллера самого цикла, который будет обязан хранить чисто попыток, лимиты бюдета и репорты слать. Иначе 2 вероятностных агента могут долго возвращать работу друг другу, каждый раз немного меняя формулировку, но не устраняя сам дефект.
да, для живого ллм адаптера строгая json-ка была бы полезна, тот же equivalent, extracted,reason с фикс типами и энамчиком. В текущем виде в репо намернно не вызывается, просто используются записанные json ответы.
Но вот что сразу можно заметить:
1. json схема решает ведь только синтаксическую часть. Моделька все еще может вернуть совершенно валидный json с выдуманным "extracted=3/4" для ответа "не знаю" (это если в контексте описанных в статье примера). Поэтому json -схему я бы рассматривал как входной фильтр перед гейтом, а не как замену детерминированной проверки
2. Насчет смещения интуция дельная. Я бы проверял это на аб тестах на одном калибров.сете, где свободный ответ противопоставлял бы строгой схеме, а затем сравнил бы конфужн матрицу, каппу и долю ручной проверки. Кстати, я скорей всего, так и сделаю и результаты опубликацию как продолжение статьи, спасибо!