Суперкомпьютер - сильное преувеличение. Просто устройство, заточенное под локальную работу с ИИ. Из "заточки" - объем памяти (128GB - не рекорд, но неплохо) и ее скорость (в 2 раза выше чем DDR5, но до видеокарт сильно недотягивает).
Проблема в том, что LLM - это уже набор закономерностей, найденных на этапе обучения. И поиском именно новых закономерностей он занимается спустя рукава.
Если ваши сценарии были в обучающей выборке - то работает хорошо. Если не было - то может и повезет (но маловероятно). Да, можно дообучить - но это доступно далеко не всем и далеко не так просто.
А ИИ-директор уже есть - ИИ-агентами зовутся. В теории штука очень хорошая, на практике тоже может поражать воображение. Но по факту - все та же LLM, но в обертке из доп. данных и инструментов. Галлюцинации никуда не делись, но теперь они еще и весь проект или всю систему могут "грохнуть".
В "Реальная мультиагентная система" как Исследователь и Дата-инженер обмениваются данными? Ладно, Редактор может просто по файлам отработать. Но Дата-инженер читает "предыдущие сообщения", которых просто нет - в истории одно сообщение с текущим запросом (и системный промт добавится).
Может checkpointer должен был помочь? Но у всех разный checkpointer (разные экземпляры MemorySaver), не говоря уже о том, что указаны разные thread_id (к слову, а зачем для app.ainvoke указывать thread_id, если у каждого узла своя LLM со своим конфигом?).
Может я что не понимаю и MemorySaver - это какой-нибудь Singleton? Но нет, попробовал запустить (взял авторский код с GitHub) - и действительно, данные не передаются. В dataset.csv генерируется какая-то ерунда, не относящаяся к вопросу.
Осталось впечатление, что был рабочий проект/пример, его "на коленках" адаптировали для статьи и без тестирования/запуска выдали (следы подобного подхода были и в предыдущей статье). В данном же случае, похоже, был пример "одному агенту по очереди автоматически добавляем задачи - собери данные, составь таблицу, дай отчет" переделанный в мультиагента.
P.S. поиск через duckduckgo не работает - там сейчас редирект, который не отрабатывает на клиенте. Надо указать новый URL (https://html.duckduckgo.com/html/). Разрешить редиректы у клиента (httpx.AsyncClient(timeout=10, follow_redirects=True)) не поможет - при редиректе теряются параметры запроса.
P.P.S. при проблемах использовать фейковые данные - плохая идея. Сильно усложняется отладка (подобное было и в предыдущей статье).
Для галлюцинаций достаточно просто что-то спросить у LLM. Чем уже область знаний - тем вероятнее галлюцинации. Различные ухищрения могут как улучшить ответ, так и ухудшить - универсального решения нет. Чем "лучше" работает LLM (благодаря супер-промту) - тем вероятнее галлюцинации.
Структурированные JSON-ответы: как всегда получать то, что ждешь
Сейчас можно на уровне запроса к LLM задать ожидаемый формат ответа, без необходимости парсить ответ. Заодно можно сократить размер промта - не обязательно указывать спецификации JSON-формата.
Большая языковая модель (БЯМ; англ. large language model, LLM) — языковая модель, состоящая из нейронной сети со множеством параметров (обычно миллиарды весовых коэффициентов и более), обученной на большом количестве неразмеченного текста с использованием обучения без учителя.
И причем тут AlphaFold и нобелевка ее разработчиков - вопрос открытый. Но в любом случае, нобелевку дали за разработку AlphaFold, а не за использование AlphaFold.
В том то и проблема, что я бы его даже со средним человеком не сравнил.
Скорее уж я бы сравнил с библиотекарем. Который прочитал всю библиотеку (выборочно запомнил, но лучше запомнил те моменты, что повторялись из книги в книгу). Но ничего, кроме книг, в жизни и не видел.
Отличные академические знания, но нет умения эти знания применять на практике. И если копнуть, то глубина знаний тоже оказывается не такой уж и высокой. Особенно если нужны нестандартные решения для той или иной задачи.
Причем знания у него на достаточно хорошем уровне - я бы оценил выше среднестатистического человека. Но хуже, чем у профессионала в его области (впрочем, не факт - именно знания могут присутствовать).
Т.е. спроси его по вопросу - ответит на отлично (местами даже больше знает, чем официальная документация). Но попроси решить задачу - и он не сможет понять, что эти знания тут пригодились бы. Даже если указать "куда смотреть" - может не понять как и что делать.
В LangGraph архитектурно заложено, что граф должен начинаться с узла, а не с условного ребра.
Попробовал начать с условного ребра - работает. Только при выводе графа "ломается" отображение __start__ и __end__ - они отображаются как стандартные узлы.
"Анализ с применением искусственного интеллекта" - это далеко не тоже самое, что "ИИ сказал". Подозреваю, что помимо ИИ были и другие аргументы. Просто ИИ на хайпе - вот его и пихают куда попало.
Впрочем, всегда надо изучать детали - тут возможен и вариант "показали ChatGPT фотку и спросили автора". Все-таки у музея есть и свой интерес в том, чтобы не копию хранить, а неповторимый оригинал.
Но вот какой момент. С ИИ надо ожидать подвоха в каждом ответе. И, зачастую, вопросы чуть сложнее базовых уже вызывают проблемы. Надо самому разбираться в вопросе, чтобы вовремя понять, что ИИ занесло не туда.
Умение связанно говорить - не есть понимание. ChatGPT умеет отлично рассказывать, этого не отнять. Отлично отвечает на вопросы, обучает тоже неплохо. Что лишний раз показывает, что для обучения понимания темы не нужно.
ChatGPT / LLM - скорее библиотека или справочная. Но понимания там нет.
И не стоит забывать про галлюцинации, которыми славятся LLM. Так что 100% доверия ему нет.
P.S. да, есть люди, которые мало что понимают, даже в том, чем профессионально занимаются, этого не отнять.
Масштабирование с очень существенными нюансами будет.
Сгенерированный код надо очень внимательно проверять. Подвох может быть практически в каждой строчке. И времени это может потребовать не меньше, чем написание кода.
А главное - универсальных промтов нет. Их надо так или иначе адаптировать под конкретную ситуацию. А генерация - рандомный процесс. И не всегда можно добиться идеального результата.
Я согласен, что LLM показывают удивительные результаты. Но до специалистов они очень не дотягивают - не хватает понимания.
И как раз понимания у LLM нет. LLM сгенерирует пример, распишет что делает каждая строчка и зачем она нужна. Но стоит удалить определенную строчку кода - и LLM уже не в состоянии понять что не так и почему не работает (из личного опыта).
И с текущей архитектурой LLM этого понимания и не будет - каждую возникающую проблему просто невозможно заранее прогнать в LLM для запоминания. А проблемы слишком разнообразны и уникальны для выработки общих шаблонов.
LLM хороши для "просто спросить". LLM отлично справляются с генерацией примеров. Но сложные или нестандартные проблемы они просто не в состоянии решать, даже если речь идет о топовых LLM.
P.S. отсутствие понимания очень просто доказать - от префразирования промта может значительно поменяться результат генерации (от хорошего до полностью неприемлемого), даже при нулевой температуре. А с ненулевой температурой - результат и одинакового промта плавает, пускай и в меньшей степени.
С cobol все-таки ситуация чуть другая. Cobol никому не интересен - и специалистов не осталось. При это нужда в них тоже не особо высокая (пускай сохраняется и сейчас).
LLM же скорее поднимает порог входа в ИТ (и опускает одновременно). Опускает тем, что сейчас любой может, активно общаясь с ИИ, выдавать себя за профессионала. А поднимает порог тем, что специалист (для успеха) должен лучше разбираться и понимать свою область, чем ИИ.
К чему это приведет? Еще больше самозванцев, еще больше стадий собеседования, еще больше сложности поиска работы.
А программисты как были, так и останутся. Где-то встречал умную мысль, что число программистов ограничивает не достаточность задач (работников должно быть ровно столько, чтобы справлялись с задачами), и фонд оплаты труда (а задач на всех хватит. Если что - аппетиты тоже можно увеличить).
Так что более высокая эффективность приведет не к сокращению штата, а к большей нагрузке на всех.
P.S. Впрочем, не думаю, что для хороших senior-программистов что-то серьезно поменяется. Да даже для хороших middle-программистов. Для программирования важно понимание предметной области (чем и славятся хорошие программисты), а с пониманием у ИИ как раз туго (даже когда нужные данные у ИИ есть).
Вот ортолинейные моноблоки я не понимаю. Сплит - да, позволяет пальцам двигаться в одном направлении. Но моноблок ничем не лучше в этом плане классической клавиатуры.
Нужна гибкая настройка? Так QMK/VIA есть и на обычных клавиатурах. Нужен небольшой размер? 60% клавиатура или даже 75% не сильно в размерах отличаются.
Насколько знаю, трекболы хорошо себя проявляют в разных CAD системах или при 3D-моделировании. На сколько слышал, за счет более естественного задания направления вращения фигуры.
Второй фактор - шар можно крутануть и он по инерции будет двигаться, что тоже бывает удобно.
И трекбол плохо себя проявляет в шутерах - но наловчится можно, особенно если ты не киберкотлета и нет необходимости выступать на турнирах )
У thumbball хорошая эргономичность - что-то среднее между Logitech MX Master и вертикальной мышью. Сейчас есть Logitech MX Ergo с изменяемым углом (2 положения). Но необходимость чистить шарик сильно портит впечатления.
А Logitech брать тем более нет желания - микрики достаточно быстро начинают дабл-кликать. И это не исправить толком даже их перепайкой - проблема (в том числе) и в низком тайминге на устранение дребезга контакта.
Суперкомпьютер - сильное преувеличение. Просто устройство, заточенное под локальную работу с ИИ. Из "заточки" - объем памяти (128GB - не рекорд, но неплохо) и ее скорость (в 2 раза выше чем DDR5, но до видеокарт сильно недотягивает).
Фича в объеме памяти - до 96GB VRAM, на видеокартах такого добиться сложнее (минимум 3-4 карты понадобится). И бюджет будет выше.
Но есть альтернативы - в виде Mac Studio или AMD Ryzen AI Max+ 395.
Но у NVIDIA лучше экосистема развита - так что спрос будет и немаленький (есть резон дождаться продуктов от вендоров - они дешевле обещают быть).
Проблема в том, что LLM - это уже набор закономерностей, найденных на этапе обучения. И поиском именно новых закономерностей он занимается спустя рукава.
Если ваши сценарии были в обучающей выборке - то работает хорошо. Если не было - то может и повезет (но маловероятно). Да, можно дообучить - но это доступно далеко не всем и далеко не так просто.
А ИИ-директор уже есть - ИИ-агентами зовутся. В теории штука очень хорошая, на практике тоже может поражать воображение. Но по факту - все та же LLM, но в обертке из доп. данных и инструментов. Галлюцинации никуда не делись, но теперь они еще и весь проект или всю систему могут "грохнуть".
Вычитки статье явно недостает.
В "Реальная мультиагентная система" как Исследователь и Дата-инженер обмениваются данными? Ладно, Редактор может просто по файлам отработать. Но Дата-инженер читает "предыдущие сообщения", которых просто нет - в истории одно сообщение с текущим запросом (и системный промт добавится).
Может
checkpointerдолжен был помочь? Но у всех разныйcheckpointer(разные экземплярыMemorySaver), не говоря уже о том, что указаны разныеthread_id(к слову, а зачем дляapp.ainvokeуказыватьthread_id, если у каждого узла своя LLM со своим конфигом?).Может я что не понимаю и
MemorySaver- это какой-нибудь Singleton? Но нет, попробовал запустить (взял авторский код с GitHub) - и действительно, данные не передаются. Вdataset.csvгенерируется какая-то ерунда, не относящаяся к вопросу.Осталось впечатление, что был рабочий проект/пример, его "на коленках" адаптировали для статьи и без тестирования/запуска выдали (следы подобного подхода были и в предыдущей статье). В данном же случае, похоже, был пример "одному агенту по очереди автоматически добавляем задачи - собери данные, составь таблицу, дай отчет" переделанный в мультиагента.
P.S. поиск через duckduckgo не работает - там сейчас редирект, который не отрабатывает на клиенте. Надо указать новый URL (
https://html.duckduckgo.com/html/). Разрешить редиректы у клиента (httpx.AsyncClient(timeout=10, follow_redirects=True)) не поможет - при редиректе теряются параметры запроса.P.P.S. при проблемах использовать фейковые данные - плохая идея. Сильно усложняется отладка (подобное было и в предыдущей статье).
Для галлюцинаций достаточно просто что-то спросить у LLM. Чем уже область знаний - тем вероятнее галлюцинации. Различные ухищрения могут как улучшить ответ, так и ухудшить - универсального решения нет. Чем "лучше" работает LLM (благодаря супер-промту) - тем вероятнее галлюцинации.
.
Сейчас можно на уровне запроса к LLM задать ожидаемый формат ответа, без необходимости парсить ответ. Заодно можно сократить размер промта - не обязательно указывать спецификации JSON-формата.
Хотя со спецификациями, скорее всего, будет лучше работать:
Но не факт, что у всех провайдеров LLM заведутся такие запросы - нужна поддержка на уровне API (в Ollama она есть).
С ChatOpenAI можно и к локальным провайдерам подключаться (ollama / llama.cpp и т.д.), не обязательно OpenAI оплачивать (или еще какого провайдера).
Мы говорили о LLM.
И причем тут AlphaFold и нобелевка ее разработчиков - вопрос открытый. Но в любом случае, нобелевку дали за разработку AlphaFold, а не за использование AlphaFold.
В том то и проблема, что я бы его даже со средним человеком не сравнил.
Скорее уж я бы сравнил с библиотекарем. Который прочитал всю библиотеку (выборочно запомнил, но лучше запомнил те моменты, что повторялись из книги в книгу). Но ничего, кроме книг, в жизни и не видел.
Отличные академические знания, но нет умения эти знания применять на практике. И если копнуть, то глубина знаний тоже оказывается не такой уж и высокой. Особенно если нужны нестандартные решения для той или иной задачи.
Причем знания у него на достаточно хорошем уровне - я бы оценил выше среднестатистического человека. Но хуже, чем у профессионала в его области (впрочем, не факт - именно знания могут присутствовать).
Т.е. спроси его по вопросу - ответит на отлично (местами даже больше знает, чем официальная документация). Но попроси решить задачу - и он не сможет понять, что эти знания тут пригодились бы. Даже если указать "куда смотреть" - может не понять как и что делать.
Попробовал начать с условного ребра - работает. Только при выводе графа "ломается" отображение
__start__и__end__- они отображаются как стандартные узлы."Анализ с применением искусственного интеллекта" - это далеко не тоже самое, что "ИИ сказал". Подозреваю, что помимо ИИ были и другие аргументы. Просто ИИ на хайпе - вот его и пихают куда попало.
Впрочем, всегда надо изучать детали - тут возможен и вариант "показали ChatGPT фотку и спросили автора". Все-таки у музея есть и свой интерес в том, чтобы не копию хранить, а неповторимый оригинал.
Но вот какой момент. С ИИ надо ожидать подвоха в каждом ответе. И, зачастую, вопросы чуть сложнее базовых уже вызывают проблемы. Надо самому разбираться в вопросе, чтобы вовремя понять, что ИИ занесло не туда.
А потом оказывается, что для небольших (а то и для средних) приложений достаточно и SQLite...
Умение связанно говорить - не есть понимание. ChatGPT умеет отлично рассказывать, этого не отнять. Отлично отвечает на вопросы, обучает тоже неплохо. Что лишний раз показывает, что для обучения понимания темы не нужно.
ChatGPT / LLM - скорее библиотека или справочная. Но понимания там нет.
И не стоит забывать про галлюцинации, которыми славятся LLM. Так что 100% доверия ему нет.
P.S. да, есть люди, которые мало что понимают, даже в том, чем профессионально занимаются, этого не отнять.
Масштабирование с очень существенными нюансами будет.
Сгенерированный код надо очень внимательно проверять. Подвох может быть практически в каждой строчке. И времени это может потребовать не меньше, чем написание кода.
А главное - универсальных промтов нет. Их надо так или иначе адаптировать под конкретную ситуацию. А генерация - рандомный процесс. И не всегда можно добиться идеального результата.
Я согласен, что LLM показывают удивительные результаты. Но до специалистов они очень не дотягивают - не хватает понимания.
И как раз понимания у LLM нет. LLM сгенерирует пример, распишет что делает каждая строчка и зачем она нужна. Но стоит удалить определенную строчку кода - и LLM уже не в состоянии понять что не так и почему не работает (из личного опыта).
И с текущей архитектурой LLM этого понимания и не будет - каждую возникающую проблему просто невозможно заранее прогнать в LLM для запоминания. А проблемы слишком разнообразны и уникальны для выработки общих шаблонов.
LLM хороши для "просто спросить". LLM отлично справляются с генерацией примеров. Но сложные или нестандартные проблемы они просто не в состоянии решать, даже если речь идет о топовых LLM.
P.S. отсутствие понимания очень просто доказать - от префразирования промта может значительно поменяться результат генерации (от хорошего до полностью неприемлемого), даже при нулевой температуре. А с ненулевой температурой - результат и одинакового промта плавает, пускай и в меньшей степени.
И в конце окажется, что трудозатраты на разработку не уменьшились.
Как известно, самое четкое ТЗ - это программный код.
С cobol все-таки ситуация чуть другая. Cobol никому не интересен - и специалистов не осталось. При это нужда в них тоже не особо высокая (пускай сохраняется и сейчас).
LLM же скорее поднимает порог входа в ИТ (и опускает одновременно).
Опускает тем, что сейчас любой может, активно общаясь с ИИ, выдавать себя за профессионала.
А поднимает порог тем, что специалист (для успеха) должен лучше разбираться и понимать свою область, чем ИИ.
К чему это приведет? Еще больше самозванцев, еще больше стадий собеседования, еще больше сложности поиска работы.
А программисты как были, так и останутся. Где-то встречал умную мысль, что число программистов ограничивает не достаточность задач (работников должно быть ровно столько, чтобы справлялись с задачами), и фонд оплаты труда (а задач на всех хватит. Если что - аппетиты тоже можно увеличить).
Так что более высокая эффективность приведет не к сокращению штата, а к большей нагрузке на всех.
P.S. Впрочем, не думаю, что для хороших senior-программистов что-то серьезно поменяется. Да даже для хороших middle-программистов. Для программирования важно понимание предметной области (чем и славятся хорошие программисты), а с пониманием у ИИ как раз туго (даже когда нужные данные у ИИ есть).
Вот ортолинейные моноблоки я не понимаю. Сплит - да, позволяет пальцам двигаться в одном направлении. Но моноблок ничем не лучше в этом плане классической клавиатуры.
Нужна гибкая настройка? Так QMK/VIA есть и на обычных клавиатурах.
Нужен небольшой размер? 60% клавиатура или даже 75% не сильно в размерах отличаются.
Насколько знаю, трекболы хорошо себя проявляют в разных CAD системах или при 3D-моделировании. На сколько слышал, за счет более естественного задания направления вращения фигуры.
Второй фактор - шар можно крутануть и он по инерции будет двигаться, что тоже бывает удобно.
И трекбол плохо себя проявляет в шутерах - но наловчится можно, особенно если ты не киберкотлета и нет необходимости выступать на турнирах )
У thumbball хорошая эргономичность - что-то среднее между Logitech MX Master и вертикальной мышью. Сейчас есть Logitech MX Ergo с изменяемым углом (2 положения). Но необходимость чистить шарик сильно портит впечатления.
А Logitech брать тем более нет желания - микрики достаточно быстро начинают дабл-кликать. И это не исправить толком даже их перепайкой - проблема (в том числе) и в низком тайминге на устранение дребезга контакта.