Будет ли self-hosted LLM производительнее, чем модель во внешнем контуре
Да, если их правильно готовить.
Зачем использовать гигантскую GLM, требующую целой серверной стойки, если 80% ежедневных задач в IDE можно закрывать моделями 35–120B, помещающимися на пару видеокарт?
Базовые небольшие модели в чистом виде это полуфабрикаты. Их часто используют сырыми, получают посредственный результат и делают ложные выводы о непригодности. Но качественный файнтюнинг под специфику проекта (UI-kit, внутренние API, архитектурные шаблоны) дает на дистанции не просто сопоставимый, а зачастую более чистый результат без галлюцинаций и в разы быстрее.
Да, GLM вырывается вперед там, где нужна глубокая архитектурная логика и разбор сложных межмодульных связей. Но строить весь Dev-пайплайн только на монструозных моделях является экономическим оверхедом.
Будущее не за абстрактным “чем больше, тем лучше”, а за гибридным подходом: узкозаточенные FT-модели на локальном железе для рутины и одна тяжелая рассуждающая модель для редкого комплексного проектирования (которая нужна не всем и не всегда).
Дообучение же LoRA/QLoRA на сформированном датасете занимает пару часов и стоит копейки по сравнению с подписками/API-токенами монструозных моделей на всю команду разработки.
Мы живём в этой ловушке, это неизбежно, мы люди речи, но надо понимать её наличие.
Дополню из собственных мыслей, возникших за годы создания сети принятия решений:
В отличии от животных, люди не связаны с миром прямо. Наш язык и мышление является посредником. Мы не действуем с реальностью напрямую, мы ее называем, описываем и представляем в голове.
В этом наше отличие от животных. Кот не думает лизать ему яйца или нет, он не представляет в голове образ как он лижет яйца, он их лижет сразу. Потому что может, вернее, не может иначе. Он не может посмотреть на себя со стороны наложив нормы этики, морали и устоявшихся традиций в кошачем обществе и решить что пожалуй не стоит делать этого на улице.
Вполне понятная, маркетинговая тряска. Все хайп, что не некролог.
Вот когда нейронки научатся обходить пожарный топор, висящий на стене в серверной, возникнет небольшой повод для беспокойства, пока же это все "смотрите, мы тоже как Клод!"
Вы там определитесь, я далекий от ИИ или узкий специалист в своей микрообласти?
Вы действительно только прошлись своей распознавалкой по тексту, приняли ее коэффициент 0.60 и в саму статью не вчитывались?
Сначала я прочитал статью, в процессе чтения отловил глазами с десяток мест где глаз споткнулся, проверил на всякий случае скриптом на паттерны, убедился что монотонность и количество определенных приемов выдают с головой непереваренный слоп.
И вы ДЕЙСТВИТЕЛЬНО верите в то, о чем говорите, что статья - сплошной нейрослоп, от начала и до конца выдуманный нейронной, а я просто копировал и вставил?
Вы закинули в чат тему статьи, следом описали тему двумя предложениями и закинули пару фактов/наблюдений (в лучшем случае). Получили на выходе слоп и закинули в сюда.
Кстати, для человека, который "Я ИИ не пользуюсь, а живу в нём с 2022 года, еще с GPT-3.", могли бы и скилл накидать по правильному оформлению статей, взяв его из страницы для авторов, указать структуру и тд. А не так топорно.
Есть функция автогенератор, в который можно вставить curl или тела запросов/ответов, и сразу генерируются проверки, включая типы данных, whitelist для поиска лишних параметров, затем можно донастроить проверки под документацию (если необходимо).
Как реализовали, если не секрет? В общих чертах будет достаточно.
Также, если рассматривать работу в закрытом контуре, настоящий JSON нельзя отправить во внешний чат
Я говорю сугубо о внутреннем периметре (on-premise), никаких внешних чатов, все генерится моделью развернутой локальной. Такое решение собирается за пару вечеров опытным ML-инженером.
Также заметил, что оно под Windows 10 / 11, это однопользовательская программа и нужна лицензия на винду? Насколько я понимаю никакой интеграции в линуксовые CI/CD.
Я пытаюсь понять чем ваше решение может быть интересно и кому.
Зачем? В смысле для кого это? Если связка Pydantic + Pytest + LLM (для генерации тестов) + CI/CD сделают тоже самое по всему тесту за время пока вы будете накликивать первое правило проверки. И любой ручной тестировщик справится с вставкой в окно чата JSON запроса, URL и JSON правильного ответа.
Так я же и сказал что да, уличили, я живу и работаю в среде ИИ и везде его применяю и не скрываю этого.
Проблема не в этом.
И для вычитки статьи обширно применял.
А в том что применяли настолько обширно, что кроме воды, однострочных абзацев-обрывов, афористических концовок, искусственной симметрии и триад, а также неопределенной атрибуции и раздутой значимости там ничего не отсалось, вернее изначально не было.
Что ещё нужно? Что вы пытались донести?
Пытался донести что не стоит вываливать слоп в чистом виде, а хотя бы попробовать заменив часть воды своими мыслями, если они есть.
Но, как показывает практика, если это надо объяснять то это не надо объяснять.
Так что да, моя речь немного поменялась в силу этого соседства, и, сделав вычитку при помощи Fable, я посчитал нормальными формулировки, которые ненормальны для человека, далекого от ИИ.
Рассуждения в статье верные, LLM это действительно генератор текста, а не математический движок. Но чтобы ваша схема реально работала, в ней нужно использовать правильный ML стек на каждом этапе (не LLM).
Для поиска аномалий и всяких неожиданных утечек типа высокого CTR при нулевых продажах обычно используют Isolation Forest. Он очень быстрый, не требует разметки и отлично справляется с многомерными таблицами.
Если нужно проанализировать временные ряды по выручке и трафику с учетом сезонности, лучше взять классику вроде ARIMA или алгоритм Prophet.
Чтобы понять конкретную причину падения продаж вроде нулевого стока или скачка цен, сначала отрабатывают жесткие правила на Python. А следом подключается градиентный бустинг типа CatBoost или LightGBM. Он хорош тем, что оценивает важность признаков и сразу показывает, какой именно фактор сильнее всего обвалил показатели.
В самом конце результаты всех этих алгоритмов собираются в один аккуратный JSON/MD и уходят уже в LLM для саммаризации и красивого отчетика.
Красивое и элегантное инженерное решение для первичной фильтрации в пайплайне. Выделить сетку, пропорции и геометрию верстки классическим CV за 3 мс действительно здорово с точки зрения оптимизации.
Однако хочется внести ясность:
Во-первых, типизация не равна извлечению данных. Определить по геометрическим дескрипторам, что перед нами бланк паспорта или ID-карта, действительно можно без OCR и сетей. Но бизнес-ценность любого распознавания в содержимом (ФИО, серия, номер, даты). А для считывания текста без OCR или глубоких моделей всё равно не обойтись. То есть метод не заменяет OCR, а лишь оптимизирует выбор нужного шаблона.
Во-вторых, есть границы применимости геометрии. На сканах геометрия работает идеально. Но на мобильных фото с сильными перспективными искажениями, бликами или изгибами страниц эвристики геометрии быстро теряют точность. Дополнительно, документы единого формообразующего стандарта геометрически практически неотличимы друг от друга.
Т.е. как ультрабыстрый эвристический пре-фильтр для экономии ресурсов перед запуском моделей это имеет смысл. Но заголовок и подача всё же создают маркетинговое ощущение, что OCR больше не нужен.
Огромное вам спасибо за статью! Сам хотел сделать подобное, но все руки не доходили, теперь можно смело пропустить этот шаг и обновить бенчмарк локальных моделей на применимость по бизнес кейсам.
По моему опыту, из локальных моделей, Breeze и Whisper идут ноздря в ноздрю и конкретный победитель зависит от специфики проекта. А так оба хороши.
Вы открыли для себя что фломастеры на вкус и цвет разные. Современной Убунты хватает для большинства задач, но я почему-то 19 лет сижу на openSuse, наверное сила привычки, все просто работает.
Да, если их правильно готовить.
Зачем использовать гигантскую GLM, требующую целой серверной стойки, если 80% ежедневных задач в IDE можно закрывать моделями 35–120B, помещающимися на пару видеокарт?
Базовые небольшие модели в чистом виде это полуфабрикаты. Их часто используют сырыми, получают посредственный результат и делают ложные выводы о непригодности. Но качественный файнтюнинг под специфику проекта (UI-kit, внутренние API, архитектурные шаблоны) дает на дистанции не просто сопоставимый, а зачастую более чистый результат без галлюцинаций и в разы быстрее.
Да, GLM вырывается вперед там, где нужна глубокая архитектурная логика и разбор сложных межмодульных связей. Но строить весь Dev-пайплайн только на монструозных моделях является экономическим оверхедом.
Будущее не за абстрактным “чем больше, тем лучше”, а за гибридным подходом: узкозаточенные FT-модели на локальном железе для рутины и одна тяжелая рассуждающая модель для редкого комплексного проектирования (которая нужна не всем и не всегда).
Дообучение же LoRA/QLoRA на сформированном датасете занимает пару часов и стоит копейки по сравнению с подписками/API-токенами монструозных моделей на всю команду разработки.
Дополню из собственных мыслей, возникших за годы создания сети принятия решений:
В отличии от животных, люди не связаны с миром прямо. Наш язык и мышление является посредником. Мы не действуем с реальностью напрямую, мы ее называем, описываем и представляем в голове.
В этом наше отличие от животных. Кот не думает лизать ему яйца или нет, он не представляет в голове образ как он лижет яйца, он их лижет сразу. Потому что может, вернее, не может иначе. Он не может посмотреть на себя со стороны наложив нормы этики, морали и устоявшихся традиций в кошачем обществе и решить что пожалуй не стоит делать этого на улице.
Так вроде бы у задачи 2 не существует единственного правильного решения. Там ответ скорее в области философии.
Вполне понятная, маркетинговая тряска. Все хайп, что не некролог.
Вот когда нейронки научатся обходить пожарный топор, висящий на стене в серверной, возникнет небольшой повод для беспокойства, пока же это все "смотрите, мы тоже как Клод!"
P.S.: хм, знакомый у вас ник, мимо Obezyan.
Нет, не умеете, если вы не аутист (условно). Там сверхчеловеческая монотонность паттернов.
Спасибо за детальный и развернутый ответ. Теперь мне понятна целевая аудитория.
Зачем? Если вы дважды не поняли о чем я пишу. Не думаю, что в третий раз что-то изменится.
Вы там определитесь, я далекий от ИИ или узкий специалист в своей микрообласти?
Сначала я прочитал статью, в процессе чтения отловил глазами с десяток мест где глаз споткнулся, проверил на всякий случае скриптом на паттерны, убедился что монотонность и количество определенных приемов выдают с головой непереваренный слоп.
Вы закинули в чат тему статьи, следом описали тему двумя предложениями и закинули пару фактов/наблюдений (в лучшем случае). Получили на выходе слоп и закинули в сюда.
Кстати, для человека, который "Я ИИ не пользуюсь, а живу в нём с 2022 года, еще с GPT-3.", могли бы и скилл накидать по правильному оформлению статей, взяв его из страницы для авторов, указать структуру и тд. А не так топорно.
Как реализовали, если не секрет? В общих чертах будет достаточно.
Я говорю сугубо о внутреннем периметре (on-premise), никаких внешних чатов, все генерится моделью развернутой локальной. Такое решение собирается за пару вечеров опытным ML-инженером.
Также заметил, что оно под Windows 10 / 11, это однопользовательская программа и нужна лицензия на винду? Насколько я понимаю никакой интеграции в линуксовые CI/CD.
Я пытаюсь понять чем ваше решение может быть интересно и кому.
Зачем? В смысле для кого это? Если связка Pydantic + Pytest + LLM (для генерации тестов) + CI/CD сделают тоже самое по всему тесту за время пока вы будете накликивать первое правило проверки. И любой ручной тестировщик справится с вставкой в окно чата JSON запроса, URL и JSON правильного ответа.
Все, что я вам должен - прощаю.
Проблема не в этом.
А в том что применяли настолько обширно, что кроме воды, однострочных абзацев-обрывов, афористических концовок, искусственной симметрии и триад, а также неопределенной атрибуции и раздутой значимости там ничего не отсалось, вернее изначально не было.
Пытался донести что не стоит вываливать слоп в чистом виде, а хотя бы попробовать заменив часть воды своими мыслями, если они есть.
Но, как показывает практика, если это надо объяснять то это не надо объяснять.
На правах человека, максимально далекого от ИИ:
At first like this:
but then:
Как насчет начать с себя и перестать постить откровенный ИИ-слоп?
И это печально.
Рассуждения в статье верные, LLM это действительно генератор текста, а не математический движок. Но чтобы ваша схема реально работала, в ней нужно использовать правильный ML стек на каждом этапе (не LLM).
Для поиска аномалий и всяких неожиданных утечек типа высокого CTR при нулевых продажах обычно используют Isolation Forest. Он очень быстрый, не требует разметки и отлично справляется с многомерными таблицами.
Если нужно проанализировать временные ряды по выручке и трафику с учетом сезонности, лучше взять классику вроде ARIMA или алгоритм Prophet.
Чтобы понять конкретную причину падения продаж вроде нулевого стока или скачка цен, сначала отрабатывают жесткие правила на Python. А следом подключается градиентный бустинг типа CatBoost или LightGBM. Он хорош тем, что оценивает важность признаков и сразу показывает, какой именно фактор сильнее всего обвалил показатели.
В самом конце результаты всех этих алгоритмов собираются в один аккуратный JSON/MD и уходят уже в LLM для саммаризации и красивого отчетика.
Красивое и элегантное инженерное решение для первичной фильтрации в пайплайне. Выделить сетку, пропорции и геометрию верстки классическим CV за 3 мс действительно здорово с точки зрения оптимизации.
Однако хочется внести ясность:
Во-первых, типизация не равна извлечению данных. Определить по геометрическим дескрипторам, что перед нами бланк паспорта или ID-карта, действительно можно без OCR и сетей. Но бизнес-ценность любого распознавания в содержимом (ФИО, серия, номер, даты). А для считывания текста без OCR или глубоких моделей всё равно не обойтись. То есть метод не заменяет OCR, а лишь оптимизирует выбор нужного шаблона.
Во-вторых, есть границы применимости геометрии. На сканах геометрия работает идеально. Но на мобильных фото с сильными перспективными искажениями, бликами или изгибами страниц эвристики геометрии быстро теряют точность. Дополнительно, документы единого формообразующего стандарта геометрически практически неотличимы друг от друга.
Т.е. как ультрабыстрый эвристический пре-фильтр для экономии ресурсов перед запуском моделей это имеет смысл. Но заголовок и подача всё же создают маркетинговое ощущение, что OCR больше не нужен.
Огромное вам спасибо за статью! Сам хотел сделать подобное, но все руки не доходили, теперь можно смело пропустить этот шаг и обновить бенчмарк локальных моделей на применимость по бизнес кейсам.
По моему опыту, из локальных моделей, Breeze и Whisper идут ноздря в ноздрю и конкретный победитель зависит от специфики проекта. А так оба хороши.
Вы открыли для себя что фломастеры на вкус и цвет разные. Современной Убунты хватает для большинства задач, но я почему-то 19 лет сижу на openSuse, наверное сила привычки, все просто работает.
Анохин и Пу смотрят на проблему искусственного интеллекта сквозь призму фундаментальных законов биологического мозга.
К вашим рассуждениям это не имеет никакого отношения. Не пытайтесь прикрываться чужим авторитетом.