Структурированная система отлично подходит для автоматизированного заполнения. Вот только автоматизированное заполнение не завезли...
Сейчас полно уже возможностей, STT, суммаризация, составление протоколов, даже выбор из списка работает хорошо благодаря structured output. Это все может работать в лайве пока врач и пациент разговаривают.
Раскошелиться на пару десятков миллионов на инфру, десять миллионов на зарплаты чтобы все это настроить и целую Москву будет поддерживать, т.к. щас полно оптимизаций и это все работает в faster than realtime на довольно старых гпушках типо P100 / 3060. Единственный момент это для ЛЛМок нужны карты помощнее, но там и запросы будут раз в 5 минут, короткие с транскрипциям разговоров врачей и пациентов (или по кнопке). А в итоге каждое поле заполняется по смыслу в течение 5-10 секунд после разговора и врачу остаётся пролистать и поправить нюансы.
То есть будь средства это все выполнимо уже сейчас, с возможностью апгрейда в будущем когда новые технологии завезут.
Ответ тянет на отдельную статью с обзором методов обучения и сравнения с методами для LLM. Планируете что то подобное писать в будущем?
По поводу решения по аналогии, судя по документации, GEPA подсматривает в задачи обучающей выборке и LLM-судья (тот который рефлексией занимается) прописывает характеристики, в том числе может написать в промпт примеры решений типовых задач, которые чаще всего встречаются. И дальше на валидационной/тестовой выборке это также приносит плоды, если модель не воспринимает примеры буквально. Но если воспринимает буквально, по методикам LLM-судья должен это определить и поменять формулировки. В этом однозначный плюс эволюционного подхода.
Тут ещё правильно тестировать надо. Если речь про RAG, то в тестовую выборку я бы добавлял документацию по продукту которого вообще не было в обучающей выборке, которую писали другие люди и о которой модель вообще ничего не знает. Тогда можно говорить о генерализации подхода. Тут все зависит от уровня модели-судьи. Если та же мелкая модель пытается научить саму себя, подозреваю что результаты будут посредственные даже с высоким уровнем бюджета.
Понятное дело, что все это попытки закрыть дыры в LLM подходах, но как говорится чем богаты и это все надо рассматривать как обертку над инструментом, а не попытку сделать "интеллект"
И внезапно мне как раз нужен был такой вот эволюционный метод для того чтобы по стилю и точности максимально подогнать ответы одной нейронки (более мелкой) к другой. И тут Гугл даёт рекомендацию этой статьи. Совпадение?
Я такие статьи пролистываю до сути. Про метод GEPA не знал, звучит интересно, но по статье в нем разбираться не буду. По сути нужен датасет с метрикой (точность ответов, или количество фолзов, или F1 например) и можно подобрать промпты или программный код, который будет давать результаты.
Если для параметризированных алгоритмов давно придумали всякие поиски по сетке, байесовские методы (я большой фанат Optuna), то для алгоритмов с неизвестными и плохо формализуемыми параметрами (найти оптимальный системный промпт для конкретной задачи LLM) этот GEPA выглядит как минимум приемлемо.
Не знаю какой был коммент на который вы отвечали. Но по хорошему для воспроизводимости после pull latest проверяется версия и обычно фиксируется в компознике, чтобы везде именно она использовалась, и желательно с уникальным названием и сетевым портом для доступа, чтобы вот так не попасть на открытый пол года назад контейнер. Но если это пет проект то не нужно так делать. А за статью спасибо, у LLMок действительно есть такая проблема.
Забавно, года полтора-два назад все говорили что это генератор бойлерплейта, а сейчас сравнивают аналитические способности. Что будет через пару лет? Если вот так остановиться и подумать, что было буквально год назад. Взять нейронки тех лет и сравнить. Они сейчас кажутся настолько тупыми, что ими пользоваться не хочется от слова совсем.
Миллион строк и абзац. Так абзац это же и есть перенос строки, разве нет? Что для вас абзац?
Вот я поставил один перенос. В моем сообщении 2 строки и 2 абзаца. А то как хабр (и блокнот) отображает зависит от его кода и ширины вашего экрана, но перенос строки я ставил один.
Gpt-5.2 с extra high ризонингом в codex - лучшее, что было для систематизированного программирования, не для вайб кодинга и штамповки веб приложений. Идеально точно исполняет команды, подмечает нюансы, не делает лишнего, из дополнительного может сразу обновить документацию и учесть неочевидный момент, но учесть его именно так как требуется кодовой базе, а не наспамить лишнего.
Как выразился мой друг "я перестал кричать на нейронку, а это что-то да значит". Я на нейронки не кричал никогда, но просто не могу пользоваться всякими своевольными которые так и норовят сделать какой нибудь вспомогательный скрипт и с его помощью "показать как работают изменения". Эта модель дольше размышляет, но оно не уходит в пустоту.
Как будет с gpt-5.2-codex не знаю, надо пробовать, но gpt-5.2 это первая модель после которой мне не стыдно в нашем легаси код коллегам показывать и я вношу туда буквально минимальные правки в одной-двух строках из 500.
Так это вполне нормальный процесс. Поколения меняются, меняется и эволюционирует язык. Язык это инструмент обмена информацией. Мы не сможем сейчас общаться ни на старорусском, ни на языке 19 века и даже 20го века будет звучать странновато, хотя большинство мы поймём. Вполне нормально что будущие поколения не будут понимать нас, ведь не нам с вами общаться на том языке, а им. И если они находят общение на нем эффективным, то почему мы должны заботиться о том как им общаться?
Да, самое сложное в обучении качественного RL алгоритма, это совсем не сам алгоритм, а среда которая при этом ещё и быстро должна отдавать результат. Именно от качества симуляции зависит будет ли агент читерить, а дальше уже дело техники выбрать правильный таргет и алгоритм. Да хоть параллельно пустить можно и выбрать лучший.
Как же вы задрали уже. Все эти смешные ролики про то что люди не могут общаться и при любом удобном случае пишут в приложение "чатгпт, он написал мне такой то комментарий, как мне ему лучше ответить", уже нихрена не смешные. Иногда хочется чтобы чатгпт сказал "остановись, дурак, и подумай что и зачем ты делаешь. Встань и посмотри в стену 5 минут, поразмышляй о жизни"
А что, .venv/bin/activate уже заблокировали на законодательном уровне и обязательно нужно придумывать uv activate? Если нужно что то запустить всегда есть uv run который незаметно для пользователя активирует окружение при запуске любой команды. А если нужно что то запускать несколько раз и каждый раз лень вводить uv run, все активируется по старинке потому что под капотом там обычный venv и знакомое для всех решение
Поражаюсь насколько народ ленив чтобы не то чтобы ответить самому, даже не прочитать, сразу скидывая в ближайшую LLM с просьбой пообщаться в комментариях.
Я сразу написал что перевод не читал и пошел в источник. Так что мой комментарий сразу относился не к переводу и его качеству, а к качеству первоисточника, нет смысла ещё раз сообщать что это всего лишь перевод и повторно перечислять то что я уже написал, но другими словами.
Принесите в диалог что-то новое, если хотите пообщаться. А нечего сказать, так лучше ничего не ответить. Комментарии к статье вполне могут существовать без ответа мейнтейнера.
Перевод не читал, сразу в оригинал пошел. Результаты были бы интересные, если бы не несколько пунктов:
1) Нет указания структуры данных - кликхауз надо уметь приготовить. Партиции, сортировки, индексы - все это влияет как на индивидуальную задержку, так и на пропускную способность.
2) Нет указания запросов, возможно тестировались только нужные конкретному заказчику в специфичном случае, а не широкий диапазон различных.
3) Данных М А Л О. Терик данных за несколько лет это даже не смешно. Хотя бы несколько сценариев надо:
а) пол терабайта в день и колонок этак 100 из которых 30 заполнены в разное время - реалистичный сценарий получения и нормализации каких нибудь логов из различных источников / различного назначения.
б) 5-10 колонок но все всегда заполнены
Обязательно нужно использовать все доступные типы данных в СУБД для адекватной проверки и показать таблицу сравнения, хотя бы что есть, а чего нет.
Автор оригинала просто мускулами поиграл, а не предоставил сравнительный отчет, мол вот цифры какие классные. При этом детали не раскрывает, а жаль
Вообще если серьезно за дело браться, то транслятор пишется и extension расширение на среду разработки, который в лайве все файлы фреймворка переводить будет, если надо в нем чё то ковырнуть. А новые фичи по честному завозить параллельной разработкой. Вот автор начал, он и должен завозить, ведь его пользователи не знают английский, а адекватные люди помогать ему не будут - свое время дороже
Не поворачивается. Я учил 1с, и успешно, но желания писать на нем не прибавилось. Просто по работе пришлось помогать когда в техподдержке ещё работал и параллельно у нашего 1с-ника стажировался. Сейчас глянул в доку - нет, все та же хрень от которой мутит.
Разработчики 1с это какие то герои из легенд, их зарплаты максимально оправданы как минимум потому что их мало. Да, они особенные, у них есть силы и иногда даже желание в этом копаться, бороться с особенностями и иногда даже выигрывать. Но в целом для подавляющего большинства стрелочка не поворачивается, потому что 1с это нишевый язык, а не общего назначения. По крайней мере используется он как нишевый в нишевых системах. А вот js пихается везде и не выучить его если ты знаешь что угодно ещё - это надо постараться. Даже после Бейсика или 1с перейти на js максимально легко для человека с определенным складом ума.
Если человек пишет на 1с но пытался и понял что не может писать даже базовые вещи на js/python/java/c (выбрать любое), время задуматься а пишет ли он вообще на 1с или притворяется.
Структурированная система отлично подходит для автоматизированного заполнения. Вот только автоматизированное заполнение не завезли...
Сейчас полно уже возможностей, STT, суммаризация, составление протоколов, даже выбор из списка работает хорошо благодаря structured output. Это все может работать в лайве пока врач и пациент разговаривают.
Раскошелиться на пару десятков миллионов на инфру, десять миллионов на зарплаты чтобы все это настроить и целую Москву будет поддерживать, т.к. щас полно оптимизаций и это все работает в faster than realtime на довольно старых гпушках типо P100 / 3060. Единственный момент это для ЛЛМок нужны карты помощнее, но там и запросы будут раз в 5 минут, короткие с транскрипциям разговоров врачей и пациентов (или по кнопке). А в итоге каждое поле заполняется по смыслу в течение 5-10 секунд после разговора и врачу остаётся пролистать и поправить нюансы.
То есть будь средства это все выполнимо уже сейчас, с возможностью апгрейда в будущем когда новые технологии завезут.
Ответ тянет на отдельную статью с обзором методов обучения и сравнения с методами для LLM. Планируете что то подобное писать в будущем?
По поводу решения по аналогии, судя по документации, GEPA подсматривает в задачи обучающей выборке и LLM-судья (тот который рефлексией занимается) прописывает характеристики, в том числе может написать в промпт примеры решений типовых задач, которые чаще всего встречаются. И дальше на валидационной/тестовой выборке это также приносит плоды, если модель не воспринимает примеры буквально. Но если воспринимает буквально, по методикам LLM-судья должен это определить и поменять формулировки. В этом однозначный плюс эволюционного подхода.
Тут ещё правильно тестировать надо. Если речь про RAG, то в тестовую выборку я бы добавлял документацию по продукту которого вообще не было в обучающей выборке, которую писали другие люди и о которой модель вообще ничего не знает. Тогда можно говорить о генерализации подхода. Тут все зависит от уровня модели-судьи. Если та же мелкая модель пытается научить саму себя, подозреваю что результаты будут посредственные даже с высоким уровнем бюджета.
Понятное дело, что все это попытки закрыть дыры в LLM подходах, но как говорится чем богаты и это все надо рассматривать как обертку над инструментом, а не попытку сделать "интеллект"
И внезапно мне как раз нужен был такой вот эволюционный метод для того чтобы по стилю и точности максимально подогнать ответы одной нейронки (более мелкой) к другой. И тут Гугл даёт рекомендацию этой статьи. Совпадение?
Я такие статьи пролистываю до сути. Про метод GEPA не знал, звучит интересно, но по статье в нем разбираться не буду. По сути нужен датасет с метрикой (точность ответов, или количество фолзов, или F1 например) и можно подобрать промпты или программный код, который будет давать результаты.
Если для параметризированных алгоритмов давно придумали всякие поиски по сетке, байесовские методы (я большой фанат Optuna), то для алгоритмов с неизвестными и плохо формализуемыми параметрами (найти оптимальный системный промпт для конкретной задачи LLM) этот GEPA выглядит как минимум приемлемо.
Не знаю какой был коммент на который вы отвечали. Но по хорошему для воспроизводимости после pull latest проверяется версия и обычно фиксируется в компознике, чтобы везде именно она использовалась, и желательно с уникальным названием и сетевым портом для доступа, чтобы вот так не попасть на открытый пол года назад контейнер. Но если это пет проект то не нужно так делать. А за статью спасибо, у LLMок действительно есть такая проблема.
Забавно, года полтора-два назад все говорили что это генератор бойлерплейта, а сейчас сравнивают аналитические способности. Что будет через пару лет? Если вот так остановиться и подумать, что было буквально год назад. Взять нейронки тех лет и сравнить. Они сейчас кажутся настолько тупыми, что ими пользоваться не хочется от слова совсем.
Миллион строк и абзац. Так абзац это же и есть перенос строки, разве нет? Что для вас абзац?
Вот я поставил один перенос. В моем сообщении 2 строки и 2 абзаца. А то как хабр (и блокнот) отображает зависит от его кода и ширины вашего экрана, но перенос строки я ставил один.
Потому что первый выходец с курса, а второй - человек с реальным опытом работы, возможно очень богатым и полезным опытом.
Для госуслуг TOTP настроен, удобно, M*x не нужен и вроде даже перестали предлагать подключить на него коды.
Gpt-5.2 с extra high ризонингом в codex - лучшее, что было для систематизированного программирования, не для вайб кодинга и штамповки веб приложений. Идеально точно исполняет команды, подмечает нюансы, не делает лишнего, из дополнительного может сразу обновить документацию и учесть неочевидный момент, но учесть его именно так как требуется кодовой базе, а не наспамить лишнего.
Как выразился мой друг "я перестал кричать на нейронку, а это что-то да значит". Я на нейронки не кричал никогда, но просто не могу пользоваться всякими своевольными которые так и норовят сделать какой нибудь вспомогательный скрипт и с его помощью "показать как работают изменения". Эта модель дольше размышляет, но оно не уходит в пустоту.
Как будет с gpt-5.2-codex не знаю, надо пробовать, но gpt-5.2 это первая модель после которой мне не стыдно в нашем легаси код коллегам показывать и я вношу туда буквально минимальные правки в одной-двух строках из 500.
А потом весь интернет падает, потому что ты unwrap написал
Так это вполне нормальный процесс. Поколения меняются, меняется и эволюционирует язык. Язык это инструмент обмена информацией. Мы не сможем сейчас общаться ни на старорусском, ни на языке 19 века и даже 20го века будет звучать странновато, хотя большинство мы поймём. Вполне нормально что будущие поколения не будут понимать нас, ведь не нам с вами общаться на том языке, а им. И если они находят общение на нем эффективным, то почему мы должны заботиться о том как им общаться?
Да, самое сложное в обучении качественного RL алгоритма, это совсем не сам алгоритм, а среда которая при этом ещё и быстро должна отдавать результат. Именно от качества симуляции зависит будет ли агент читерить, а дальше уже дело техники выбрать правильный таргет и алгоритм. Да хоть параллельно пустить можно и выбрать лучший.
Нет, gemini 3 pro это не deep think.
Он
Как же вы задрали уже. Все эти смешные ролики про то что люди не могут общаться и при любом удобном случае пишут в приложение "чатгпт, он написал мне такой то комментарий, как мне ему лучше ответить", уже нихрена не смешные. Иногда хочется чтобы чатгпт сказал "остановись, дурак, и подумай что и зачем ты делаешь. Встань и посмотри в стену 5 минут, поразмышляй о жизни"
А что, .venv/bin/activate уже заблокировали на законодательном уровне и обязательно нужно придумывать uv activate? Если нужно что то запустить всегда есть uv run который незаметно для пользователя активирует окружение при запуске любой команды. А если нужно что то запускать несколько раз и каждый раз лень вводить uv run, все активируется по старинке потому что под капотом там обычный venv и знакомое для всех решение
Поражаюсь насколько народ ленив чтобы не то чтобы ответить самому, даже не прочитать, сразу скидывая в ближайшую LLM с просьбой пообщаться в комментариях.
Я сразу написал что перевод не читал и пошел в источник. Так что мой комментарий сразу относился не к переводу и его качеству, а к качеству первоисточника, нет смысла ещё раз сообщать что это всего лишь перевод и повторно перечислять то что я уже написал, но другими словами.
Принесите в диалог что-то новое, если хотите пообщаться. А нечего сказать, так лучше ничего не ответить. Комментарии к статье вполне могут существовать без ответа мейнтейнера.
:)
Перевод не читал, сразу в оригинал пошел. Результаты были бы интересные, если бы не несколько пунктов:
1) Нет указания структуры данных - кликхауз надо уметь приготовить. Партиции, сортировки, индексы - все это влияет как на индивидуальную задержку, так и на пропускную способность.
2) Нет указания запросов, возможно тестировались только нужные конкретному заказчику в специфичном случае, а не широкий диапазон различных.
3) Данных М А Л О. Терик данных за несколько лет это даже не смешно. Хотя бы несколько сценариев надо:
а) пол терабайта в день и колонок этак 100 из которых 30 заполнены в разное время - реалистичный сценарий получения и нормализации каких нибудь логов из различных источников / различного назначения.
б) 5-10 колонок но все всегда заполнены
Обязательно нужно использовать все доступные типы данных в СУБД для адекватной проверки и показать таблицу сравнения, хотя бы что есть, а чего нет.
Автор оригинала просто мускулами поиграл, а не предоставил сравнительный отчет, мол вот цифры какие классные. При этом детали не раскрывает, а жаль
Вообще если серьезно за дело браться, то транслятор пишется и
extensionрасширение на среду разработки, который в лайве все файлы фреймворка переводить будет, если надо в нем чё то ковырнуть. А новые фичи по честному завозить параллельной разработкой. Вот автор начал, он и должен завозить, ведь его пользователи не знают английский, а адекватные люди помогать ему не будут - свое время дорожеНе поворачивается. Я учил 1с, и успешно, но желания писать на нем не прибавилось. Просто по работе пришлось помогать когда в техподдержке ещё работал и параллельно у нашего 1с-ника стажировался. Сейчас глянул в доку - нет, все та же хрень от которой мутит.
Разработчики 1с это какие то герои из легенд, их зарплаты максимально оправданы как минимум потому что их мало. Да, они особенные, у них есть силы и иногда даже желание в этом копаться, бороться с особенностями и иногда даже выигрывать. Но в целом для подавляющего большинства стрелочка не поворачивается, потому что 1с это нишевый язык, а не общего назначения. По крайней мере используется он как нишевый в нишевых системах. А вот js пихается везде и не выучить его если ты знаешь что угодно ещё - это надо постараться. Даже после Бейсика или 1с перейти на js максимально легко для человека с определенным складом ума.
Если человек пишет на 1с но пытался и понял что не может писать даже базовые вещи на js/python/java/c (выбрать любое), время задуматься а пишет ли он вообще на 1с или притворяется.