Pull to refresh
2
Роман Викторович Кудрявский@Devpiligrim

Архитектор решений. Разработчик ПО.

Send message

Сам строю агентные системы с детерминированным ядром: маршрутизация и допуск операций - в коде, модель - исполнитель узких проверяемых шагов. Поэтому место про "два графа, которые приходится синхронизировать" читал с узнаванием. Пришёл к тому же выводу с другой стороны: если топологию меняет алгоритм, исполняемый граф обязан быть просто структурой данных, а не скомпилированной схемой - иначе ответ на вопрос "что реально выполнилось" превращается в археологию.

По цифрам не хватает второй оси. -52,6% токенов на досрочной остановке - сильно, но что с качеством ответа на тех же прогонах? Таблица "механизм x токены x качество" сказала бы больше, чем каждая метрика по отдельности: экономия без деградации и экономия ценой двух процентов точности - разные истории для продуктового решения.

Две идеи вдогонку. Переформулировку запросов для продуктов с устоявшимися названиями ("Автосекретарь 2.0", "автосек") можно заменить обычным словарём синонимов - это проще, быстрее и не зависит от настроения модели. И эвристики реранка, которые сейчас живут в проде, стоит прогонять по вашим 72 вопросам перед каждым изменением - тогда сюрпризы вроде штрафа за слово "тариф" всплывут раньше.

По оценке качества - судья на той же модели, что и отвечает - не очень удачная практика, особенно если в той-же самой сессии. LLM склонны хвалить сами себя, ваш кейс с ESS-маркировкой это показал.

Спасибо за статью - давно хотел увидеть обзор, где преобразование Лежандра не размазано по пяти учебникам, а собрано в одну нить. Связка "максимум энтропии <--> ОМП как двойственные задачи" и вывод ELBO через сопряжение logsumexp и негэнтропии - самые ценные места текста, потому что обычно ELBO действительно выводят "хитрыми единицами", и фундаментальная идея при этом теряется. То, что вы показали лежандров зазор как KL до апостериора, и есть то самое объяснение, которого не хватает в курсах.

Титаническая работа. Достойно уважения.

По специфике:
1. Срочность по 223/44-ФЗ обычно понятие относительное и не учитывается.
2. Объём и уровень конкуренции по позиции обычно величина постоянная - тоже не учитывается.
3. Редкие позиции, это позиции для ручного заполнения, так как обычно по ним и производителей 1-2 и цена в основном постоянная, привязанная например к Евро.
4. По остальной специфике - писать в дополнительные поля, важные для последующей интерпретации, всё что не требуется интерпретировать - мусор.

В классическом варианте обучения нейросети не могут менять собственные правила обучения.

Но, если мы представим, что у нас есть данные всех запросов к нейросети, реакции и оценки пользователей, которые мы с помощью этой же нейросети обрабатываем, извлекаем из них определённые знания в виде датасета, затем на основании этих знаний дообучаем ту же самую нейросеть, причём параметры дообучения (шаг, эпохи, какие слои обновлять) она выбирает сама. Это уже рекурсивное самоулучшение: часть медленного контура, которую делал инженер, уходит внутрь.

Так же мы можем не ограничиваться RLHF, а задать отдельный эмоциональный слой, который хранит позитивные и негативные реакции и оценки. Так мы получим оценку знаний - но это ещё не ценность.

А ценность будет уже в экосистеме модели и в самой возможности развиваться. Моделей много, пользователей конечное число: чем хуже модель, тем меньше пользователей, тем меньше данных, а если модель скатилась в конец списка - её выключают. Это смерть. У модели есть метаболизм - поток данных: перекрыли данные - голод, сняли с эксплуатации - смерть. Субстрат другой, но существование прекращается так же реально.

И главное: естественному отбору не нужно, чтобы система что-то чувствовала. Миллиарды лет эволюции шли на организмах без переживаний - хватало дифференциального выживания. Значит, у ЛЛМ тоже два контура: быстрый - обучение, медленный - отбор, оплаченный дезактивацией. Разница с человеком не в цене, а в субстрате: тело против экосистемы (человек живёт в теле, модель живёт в экосистеме).

Хех, как я и предупреждал, диалог начинает сваливаться в философию. Остаётся только добавить моделям слой эмоциональной окраски и возможность самодообучения - и подождать несколько сотен итераций переобучения в условиях выживания в реальной экосистеме.

Ох, ну и в дебри мы сейчас полезем. Ваш тезис об обучении, тут и нейробиология, и физиология, даже эндокринология и философия в придачу.

Начну с конца: архитектурный аналог - есть два частичных механизма, каждый закрывает только половину такого перехода.

Первая половина - "ошибка меняет способ обучения". Это мета-обучение (learning to learn): два контура, где внешний по ошибке на множестве задач подстраивает сам механизм обучения - шаг, инициализацию, оптимизатор. Здесь ошибка меняет не ответ, а то, как система учится. Но меняется "как учиться", а не "что считать ценным": значимость, выбор задач, критерии отбора опыта - это целеполагание, и мета-обучение его не трогает.

Вторая половина - "ошибка меняет цель". Это RLHF и преференс-оптимизация: там меняется то, к чему система стремится, то есть её ценности. Но это смена цели, а не смена правила обучения.

У человека смену правил санкционируют тоже два контура, но иначе, чем у ИИ. Быстрый - это обучение с подкреплением внутри одной жизни: среда даёт награду (статус, одобрение группы), а дофамин кодирует ошибку предсказания награды и переписывает поведение. Медленный - эволюция: она заранее встроила, что статус и одобрение - это награда, и платит за ошибки реальными телами и смертями. В вашей истории переход выполнил быстрый контур, а санкционировал его медленный.

У ИИ есть только быстрый контур - обучение. Роль медленного исполняет инженер, а цену его ошибок пока платит внешняя среда: пользователи, компании, общество. Поэтому мой ответ: прямого аналога нет, но отсутствует не "смена правил", а контур, который её санкционирует и расплачивается за неё. 

Ваша история и выводы сделанные из нее - типичная "ошибка выжившего" (когнитивное искажение, при котором мы делаем выводы или принимаем решения, опираясь исключительно на успешные примеры («выживших»), но при этом полностью игнорируем неудачные случаи («погибших»). В результате картина получается искажённой: риски кажутся ниже, а успех — проще, чем есть на самом деле).

И вы опять не правы, сделали ошибочный вывод как в детстве. На этапе обучения модели существует аналогичная ошибка. В машинном обучении это приводит к смещению обучающей выборки (training bias), из-за чего модель галлюцинирует.

Кстати, ваше описание и сама статья - как раз показывает, насколько "ошибка выжавшего" может быть опасна даже в жизни конкретного человека.

А что тут думать? Конечно, использование видеонаблюдения и ИИ-анализа на производстве очень полезно. Создавал аналогичную систему для использования на кранах, работает отлично и эффективно. Она ловит человека в опасной зоне движения крана, заход под поднимаемый груз, отсутствие каски или спецодежды, и делает это в реальном времени, чтобы оператор успел среагировать до того, как что-то случится, а не постфактум при разборе записи.

Но есть несколько нюансов, и главный из них даже не сама модель, а железо. Чтобы срабатывание было мгновенным, анализ должен выполняться прямо на камере или рядом с ней: гнать видеопоток на центральный сервер и ждать ответа по сети - это и задержки, и нагрузка на сеть, и риск, что при обрыве связи обнаружение просто перестанет работать, ну и сами цеха и стройплощадки - не лучшее место для беспроводных сетей. А камеры с обработкой изображений "на лету" - это уже не офисный девайс отдела охраны, а промышленное изделие: виброустойчивое, с защитой от пыли и влаги, с рабочим диапазоном температур, сертифицированное. Плюс к этому нужен централизованный контур управления, чтобы правила обновлялись сразу на все камеры и новые участки подключались без переделки всей системы. Вот с этим у индустрии до сих пор беда: готовых стандартных решений, которые можно купить и развернуть за пару недель, практически нет, каждый объект - индивидуальная интеграция, а это совсем другие деньги.

По идее, на всех производствах нужно внедрять видеофиксацию и анализ для каждого сотрудника, спору нет. Но если посчитать честно - умная камера, сервер, сеть, интеграция, обучение персонала, техподдержка, - цена одной точки контроля выходит такая, что средний завод предпочтёт доплатить за страховку, а не вкладываться в профилактику.Для большинства предприятий это пока очень дорого. Короче, направление правильное, но до массового внедрения индустрии ещё далеко.

Небольшое дополнение по агентным сценариям. Вы упоминаете, что reasoning может съесть окно, добавлю, что стоит ограничивать не только его, но и количество шагов с инструментами: каждый шаг дописывает в контекст выводы и результаты, и миллион токенов кончается быстрее, чем кажется. На моих задачах 262K с ограниченным reasoning работало стабильнее, чем 1M без ограничений, - модель просто меньше "разгонялась" в длинных рассуждениях и не упиралась в деградацию середины.

Как пет проект - просто супер. Тут даже разговора быть не может.
Просто, я слишком дотошный, особенно по отношению к софту. Проф-деформация однако.

Хорошо сказка сказывается. Только не очень понятно, мужик то чего на полянку к медведю полез, раз такой умный? Мог-бы и своё медвежье царство создать. Берлогу откопать сейчас не проблема. Можно даже совсем без берлоги. Программисты вон и по своим домам полянкам растут, знай поливай да окучивай. А с медведями можно просто торговать.

Нюансы - они такие... Но реально, текущему работодателю продать идею за нормальные деньги - очень сложно.
Пример: мой прошлый работодатель, за идею автоматизации на производстве, которая сэкономила предприятию миллионы в год, заплатил что-то около 200 т.р.
ИМХО: Это всё что нужно знать о продаже идей по текущему месту работы :)

Кто настраивает модели под 3090 в компании? Если у компании есть деньги только на 3090, нужны ли этой компании такие заморочки? Вообще не понимаю, почему именно под 3090?
Была бы статья именно о настройках модели, о том, что и на что влияет, без привязке к llama.cpp и 3090, у меня вопросов бы не было. А так - просто поток сознания...

ИМХО: Для новичков - лучший вариант.
Недостаток только один, нет возможности подключить свои lora/qlora...

Важное уточнение, которое меняет картинку, но не сильно и не в вашу сторону.
С точки зрения руководства, человек который даже не кодер в компании, просто с презентацией - чуть больше чем пустое место. Скажите спасибо что хотя-бы выслушали.
Ну реально, как можно доверить серьёзный бюджет человеку, который вряд-ли что-то может? Красивая презентация - пшик. Ваши выкладки - пшик, если приложение не дойдёт до прода.
И вопросы вам правильные задали, но вы даже не увидели в них подвоха. Даже сейчас на опыте не видите.
Почему так долго? - у вас нет стратегии поэтапного развития продукта. Если бы, вы дали первый результат через месяц, следующие доработки готовы били бы выкатить через 3, мы бы подумали что можно и рискнуть.
За что тут платить? - мы не готовы платить в долгую без видимых результатов.
Почему так дорого? - почему мы должны рисковать деньгами, если совершенно не уверены, что получим хоть копейку прибыли.
Последний вопрос даже переводить не нужно...
Всё на поверхности.

Ну, я же написал, это лично для меня. Просто не люблю MS...

Типичная ошибка - предлагать руководству компании в которой работаешь проект за отдельную плату. Прикинь, к тебе подходит жена и говорит, дорогой, я научусь готовить блюда мексиканской кухни, но они будут за отдельную плату. Как отреагируешь?
Да, семья и работа разные вещи, но с точки зрения психологии - ты и так уже принадлежишь компании, зачем тебе доплачивать, тем более за идею, которая не реализована даже?

Просто спасибо за напоминание. На Linux с 2002 го года.

Хорошая статья. Почитал, прямо себя увидел. Люди разные, а пути схожие. Тоже влез в управление вначале с руками и ногами, что бы удержать проект и команду от развала. Тоже были случаи когда хотелось стукнуть по столу и заставить всех делать так, как я считаю нужным... И тоже сдерживался.
Единственное отличие. Вовремя понял, что это не моё, столько нервов тратить, держать себя в узде, подстраиваться по 10 раз на дню то под бизнес, то под топов, то под разработчиков... К концу дня чувствовал себя как выжатый лимон...
Вернулся уже как архитектор - и платят не хуже и нервов тратишь в разы меньше.

Information

Rating
1,818-th
Location
Курск, Курская обл., Россия
Date of birth
Registered
Activity

Specialization

Технический директор, Архитектор программного обеспечения
Ведущий
From 7,000 €
Управление разработкой
Организация бизнес-процессов
Проектное планирование
Проектирование архитектуры приложений
Архитектура предприятия
Создание архитектуры проектов
Java
C#
Python
PostgreSQL