ИИ может объяснить, как работать с незнакомыми человеку инструментами, но и это понимание ИИ будет поверхностным, и код на основе этого понимания будет некачественным. Часто полезно просто заглянуть в документацию, а не слушать ИИ.
Да, но бывают ситуации, когда LLM отвечает гораздо подробнее и обстоятельнее официальной документации (сталкивался с таким на директивах nginx).
Я всегда избегал работы с плохим кодом, потому что знаю, какая это сложная, неэффективная и неинтересная работа, а теперь я буду вынужден погружаться с головой в это болото, потому что клиенты этого хотят.
Навык писать код и навык читать код - это, к сожалению, достаточно разные навыки. Само по себе изучение чужого кода, понимание замысла разработчика - это сложно. Для кода "с душком", это еще сложнее - сложно понять, что перед тобой - фича, баг или тех.долг? Но с LLM, когда осознаешь, что он "любит" галлюцинировать, при этом выдавая крайне правдоподобный текст - становится совсем грустно. Скорость LLM сильно превышает мою скорость понимания этого код.
Так что пока, лично для меня, LLМ хороши в качестве "просто спросить, если лень лезть в поисковик" и для подготовки примеров/заготовок нужного мне кода.
С чем-то более сложным LLM не справляется.
Впрочем, есть и успешные отзывы - когда LLM сумел пойти на пользу проекту. Вероятно, польза от LLM сильно от проекта зависит. И чем нестандартнее проект - тем LLM себя хуже чувствует.
В продуктовой разработке бывает, что все на дебаг-версиях и работает. Просто потому что релиз падает непонятно почему, а рабочая версия нужна еще вчера. А потом "исторически так сложилось" и "работает - не трогай" - и дебаг-сборка становится основной...
В C/C++, на сколько помню, неинициализованные переменные не обнулялись в дебаге (если говорить про Turbo C/Turbo C++/Borland C++) - так что если не работало, то не работало сразу. Хотя и бывало, что в дебаге работало, а в релизе нет из-за различий в режимах компиляции - в переменные попадал разный "мусор".
С Delphi тоже не помню подобных приколов (хотя не скажу, что много с ним работал - предпочитал C++ Builder), но на сколько знаю, там подобное поведение тоже было.
Помнится, в Turbo Pascal (Borland Pascal) была интересная "фича" - неинициализованные переменные хранят мусор. Но в debug-режиме неинициализованные переменные обнуляются.
В итоге у тебя прекрасно работает все в дебаггере, но при релизной сборке вдруг ломается... И дебагер, опять же, не поможет - в нем все прекрасно работает.
Но зато и плюс некоторый есть - убитый вечер (или несколько) и куча нервов жестко научили тщательно следить за инициализацией переменных.
Но в целом, Pascal мало чем отличается от всех других языков со строгой статической типизацией.
Согласен, JSON далеко не идеален, хотя LLM достаточно неплохо с ним дружит. Да и от формата ответа многое зависит - тот же "массив строк кода" останется человеко-читаемым (и экранировать надо будет по минимуму).
Вообще, в llama.cpp можно задать свой формат вывода - но надо определять грамматику в формате GBNF (GGML BNF). Но это не самый общепринятый формат, как я понимаю - у JSON-схемы поддержка гораздо шире.
Это не "спор из прошлого", а "идущий сейчас спор", что несколько больший накал страстей имеет ).
И спор - это просто как пример. Мой посыл в том, что только что добавленный бот не может сделать ничего полезного - и это портит первое впечатление.
Я согласен, не-ахти-какая-проблема, особенно если говорить о бесплатном боте. Но тем не менее, первое впечатление - это важно.
P.S. можно сделать отдельного юзер-бота исключительно для доступа к истории сообщений. А обычный, при добавлении, может присылать в чат что-то вроде "для доступа к истории сообщений добавьте этого юзер-бота, он просканирует историю сообщений и выйдет из чата".
Или может есть возможность самому боту добавлять в чат изер-бота (по отдельной команде, например)...
Сейчас та же Ollama умеет отдавать форматированный ответ - т.е. формат ответа достаточно жестко задается. Не пробовали использовать для генерации ответов? По идее, будет жестко следовать нужному формату - удобнее использовать будет.
В ответе (вернее в обогащенном запросе к LLM) будет пять одинаковых фрагментов из разных версий (наиболее близких по вектору) - вместо пяти разных фрагментов (пять - потому что запрашивается пять "лучших" результатов).
А самое интересное - между фрагментами теряется контекст, так что даже зная, что эта информация есть в документе, ее можно не найти - просто потому что заголовок и описание могут быть отделены от фрагмента с нужной информацией.
Например, описание "что нельзя делать со стиралкой" - слово "стиралка" не в каждом абзаце есть или даже главе. А если и встречаются - то используются синонимы вроде "устройство". Человек понимает по контексту, что устройство - это устройство из заголовка (т.е. стиралка). А RAG такие нюансы не учитывает.
Так что предостережение "Не использовать на животных" просто не попадет в контекст вопроса "можно ли стирать кошку в стиралке?". Но вполне может попасть описание режима стирки "Шерсть".
Хм... Похоже, можно любой объем установить в рантайме - через sudo sysctl iogpu.wired_limit_mb=<VALUE>. И даже в /etc/sysctl.conf можно записать значение на постоянку.
Память раза в 3 быстрее будет - причем у любой конфигурации с M3 Ultra.
У M4 Max примерно в 2 раза быстрее память (относительно AMD/NVIDIA), минимальный конфиг с 128GB RAM стоит около $3700, что дешевле NVIDIA DGX Spark, но дороже AMD Ryzen AI Max+ 395 )
P.S. у маков не более половины памяти под видео выделяется, этот нюанс тоже надо учитывать.
Да, но бывают ситуации, когда LLM отвечает гораздо подробнее и обстоятельнее официальной документации (сталкивался с таким на директивах nginx).
Навык писать код и навык читать код - это, к сожалению, достаточно разные навыки. Само по себе изучение чужого кода, понимание замысла разработчика - это сложно. Для кода "с душком", это еще сложнее - сложно понять, что перед тобой - фича, баг или тех.долг? Но с LLM, когда осознаешь, что он "любит" галлюцинировать, при этом выдавая крайне правдоподобный текст - становится совсем грустно. Скорость LLM сильно превышает мою скорость понимания этого код.
Так что пока, лично для меня, LLМ хороши в качестве "просто спросить, если лень лезть в поисковик" и для подготовки примеров/заготовок нужного мне кода.
С чем-то более сложным LLM не справляется.
Впрочем, есть и успешные отзывы - когда LLM сумел пойти на пользу проекту. Вероятно, польза от LLM сильно от проекта зависит. И чем нестандартнее проект - тем LLM себя хуже чувствует.
xkcd дает более простой ответ )))
А если распределение не важно - то достаточно
return rand5())))Вопрос финансов - только и всего.
Слабое и дорогое железо, а время инженера дешево - "Оптимизация наше все!".
Быстрое и дешевое железо, а время инженера дорого - "Железо все вытянет!".
Добавить сюда нюансы принятия решений (поиск "серебряной пули", личные интересы и прочее-прочее-прочее) и получим текущую картину.
В продуктовой разработке бывает, что все на дебаг-версиях и работает. Просто потому что релиз падает непонятно почему, а рабочая версия нужна еще вчера. А потом "исторически так сложилось" и "работает - не трогай" - и дебаг-сборка становится основной...
В C/C++, на сколько помню, неинициализованные переменные не обнулялись в дебаге (если говорить про Turbo C/Turbo C++/Borland C++) - так что если не работало, то не работало сразу. Хотя и бывало, что в дебаге работало, а в релизе нет из-за различий в режимах компиляции - в переменные попадал разный "мусор".
С Delphi тоже не помню подобных приколов (хотя не скажу, что много с ним работал - предпочитал C++ Builder), но на сколько знаю, там подобное поведение тоже было.
Помнится, в Turbo Pascal (Borland Pascal) была интересная "фича" - неинициализованные переменные хранят мусор. Но в debug-режиме неинициализованные переменные обнуляются.
В итоге у тебя прекрасно работает все в дебаггере, но при релизной сборке вдруг ломается... И дебагер, опять же, не поможет - в нем все прекрасно работает.
Но зато и плюс некоторый есть - убитый вечер (или несколько) и куча нервов жестко научили тщательно следить за инициализацией переменных.
Но в целом, Pascal мало чем отличается от всех других языков со строгой статической типизацией.
У ollama под капотом как раз llama.cpp - так что не все так однозначно )
Согласен, JSON далеко не идеален, хотя LLM достаточно неплохо с ним дружит.
Да и от формата ответа многое зависит - тот же "массив строк кода" останется человеко-читаемым (и экранировать надо будет по минимуму).
Вообще, в llama.cpp можно задать свой формат вывода - но надо определять грамматику в формате GBNF (GGML BNF). Но это не самый общепринятый формат, как я понимаю - у JSON-схемы поддержка гораздо шире.
Если задействовать structured output, то вероятно, размер промта можно будет значительно сократить.
Но в чате уже не отправить вопрос (хотя может есть какой софт с поддержкой задания формата ответа). И, вероятно, на формат JSON придется перейти.
Если в системный промт закинуть - то он в кеш попадет один раз и не будет несколько раз обрабатываться (в идеале).
Описание и примеры есть тут: https://ollama.com/blog/structured-outputs
Как понимаю, в поле format задается JSON-схема ответа - и этого достаточно.
Судя по всему, с JSON в основном и работает (есть поддержка у многих провайдеров LLM).
В llama.cpp можно и с другими форматами работать - но надо грамматику для них писать (см https://github.com/ggml-org/llama.cpp/blob/master/grammars/README.md). Но не факт, что ollama передает этот параметр в llama.cpp (я не пробовал с этим играться).
Это не "спор из прошлого", а "идущий сейчас спор", что несколько больший накал страстей имеет ).
И спор - это просто как пример. Мой посыл в том, что только что добавленный бот не может сделать ничего полезного - и это портит первое впечатление.
Я согласен, не-ахти-какая-проблема, особенно если говорить о бесплатном боте. Но тем не менее, первое впечатление - это важно.
P.S. можно сделать отдельного юзер-бота исключительно для доступа к истории сообщений. А обычный, при добавлении, может присылать в чат что-то вроде "для доступа к истории сообщений добавьте этого юзер-бота, он просканирует историю сообщений и выйдет из чата".
Или может есть возможность самому боту добавлять в чат изер-бота (по отдельной команде, например)...
Ценность - в первом впечатлении. Если сразу есть доступ к истории - то с ботом можно сразу и поиграться.
Да и "спор зашел в тупик - вспомнил про бота" - а бот ничего не может предложить, т.к. добавлен после спора. Впечатление останется негативным.
Сейчас та же Ollama умеет отдавать форматированный ответ - т.е. формат ответа достаточно жестко задается. Не пробовали использовать для генерации ответов? По идее, будет жестко следовать нужному формату - удобнее использовать будет.
В ответе (вернее в обогащенном запросе к LLM) будет пять одинаковых фрагментов из разных версий (наиболее близких по вектору) - вместо пяти разных фрагментов (пять - потому что запрашивается пять "лучших" результатов).
А самое интересное - между фрагментами теряется контекст, так что даже зная, что эта информация есть в документе, ее можно не найти - просто потому что заголовок и описание могут быть отделены от фрагмента с нужной информацией.
Например, описание "что нельзя делать со стиралкой" - слово "стиралка" не в каждом абзаце есть или даже главе. А если и встречаются - то используются синонимы вроде "устройство". Человек понимает по контексту, что устройство - это устройство из заголовка (т.е. стиралка). А RAG такие нюансы не учитывает.
Так что предостережение "Не использовать на животных" просто не попадет в контекст вопроса "можно ли стирать кошку в стиралке?". Но вполне может попасть описание режима стирки "Шерсть".
Хм... Похоже, можно любой объем установить в рантайме - через
sudo sysctl iogpu.wired_limit_mb=<VALUE>.И даже в
/etc/sysctl.confможно записать значение на постоянку.Спасибо, надо будет попробовать )
Тогда уж лучше взять Mac Studio на 512GB RAM - не сильно дороже выйдет, а работать будет точно быстрее.
Память раза в 3 быстрее будет - причем у любой конфигурации с M3 Ultra.
У M4 Max примерно в 2 раза быстрее память (относительно AMD/NVIDIA), минимальный конфиг с 128GB RAM стоит около $3700, что дешевле NVIDIA DGX Spark, но дороже AMD Ryzen AI Max+ 395 )
P.S. у маков не более половины памяти под видео выделяется, этот нюанс тоже надо учитывать.
У AMD экосистема (софт) для ИИ значительно менее развита. У AMD языковые работают неплохо, но проблемы с генерацией картинок или видео.
Так что NVIDIA - неплохой вариант, если нужна именно "эталонная" экосистема.