Если сделал на 110% — например, ответил на задачу и еще расписал следующий её шаг, посчитал бюджет, написал стратегию — на тебя обратят внимание.
Тут не соглашусь, это не всегда хорошо. Встречал ситуацию в Германии, когда человеку не засчитали проф. экзамен из за того, что он расписал больше чем нужно было в задании.
Мотивировали тем, что человек не может уложиться а рамки задания, а значит не сможет выполнять четко поставленные задачи как требуется.
Поэтому это очень тонкий ход, который я бы не стал использовать. Показывать знания лучше уже не рабочем месте на 110%.
Насчет единого гайда на "быстрый старт" - пока не сделал, задумывался об этом.
В целом, если расчет на более узкую аудиторию в виде разработчиков, то технической будет достаточно, главное хорошо и подробно описать.
Если ориентировка все таки на публику то да, удобнее было бы иметь "Quick Start Guide" как пишут во многих документациях.
Для нее можно использовать готовые шаблоны и хостить как отдельный репозиторий на том же гитхабе. Либо использовать Telegraph, что в целом тоже не плохо. Тут уже как вам удобно.
Да изначально не было в планах писать как-то серьезно и строго, мне наоборот комфортнее когда есть эмоджи и чтение более "простое" и не перегруженное. :)
Тогда и вопроса нет :) Если Вам так удобнее писать, то так и делайте. Это уже стилистические моменты, главное это сам продукт. 👍
Это конечно да, но интересно как будет справляться ffmpeg при обработке с whisper, имею в виду не самую тяжёлую модель. В любом случае звучит интересно.
В статье есть ссылка на бота с демо-меню, где можно посмотреть разные сценарии.
Из реального примера - на данном ядре создан бот для чатов собственников в моем ЖК.
Тут я не совсем понятно описал что хотел, тут имелось в виду пример создания бота с использованием ядра, т.е. банально описанные конфиги/код/файлы, как пример использования ядра со стороны разработки.
Возможно этот пример есть в Github, тогда вопрос снимается.
Много эмодзи используется осознанно, на мой взгляд так приятнее читать и текст более выразительный и лучше воспринимается. Возможно субъективная вещь, но вот так.
Вообще да, из за обилия ЛЛМ, подобные тексты воспринимаются сугубо как ИИ генерация. Поэтому лично я придерживаюсь сухой классики, чего-то близкого к академическому/публицистическому стилю.
Проект звучит интересно, не до конца понял как конкретно его использовать на реальном примере, но допустим. Не могу сказать сразу, что статья написана (как и код) через ИИ, однако по обилию эмодзи в README и стилю описаний, будто бы GPT с промптом на обезличивание.
Поэтому пока сложно оценить проект. Выглядит не плохо, интересно, посмотрим к чему придет проект.
В моем случае NexCloud был достаточно не удобным. Ставил из под Докера с туннелем через Cloudflare. Хотел себе личное облако куда можно удобно скидывать файлы, как с ПК, так и с телефона.
Основным неудобством было то, что мобильное приложение в плей маркете не может авторизоваться на севере, постоянно приходит запрос через unsplash. Пытался исправить но так и не вышло. Хотя сам endpoint работает исправно и с браузера спокойно могу войти. Да, возможно версия на FDroid этого не имеет, но хотелось обойтись стандартным средствами.
Сам интерфейс показался устаревшим и немного не интуитивным что-ли, вспоминал GUI от Synology и вроде как выглядело удобнее, но опять же дело вкуса.
В целом да, соглашусь что NextCloud немного перегружена функциями, но это и не совсем минус. Вариативность больше.
Сейчас пробую copyparty, это не совсем то же что и NextCloud, однако в целом свою работу делает. К тому же запускается не сложно. Пока не могу для себя найти какое-то универсальное решение, которое бы подошло, но посмотрим.
Интересно и удобно все в одной библиотеке иметь. У меня конечно вопрос по поводу производительности, ffmpeg и так сама по себе не слишком лёгкая, а тут ещё whisper.
Встречал такое, часто пытаются загрузить файлы на сервер, войти под logshell и т.д. Не до конца понятно зачем это делать на сайтах, которые особо никто и не посещает. И которые в случае проблем могут просто сбросить или закрыть, если они не используется практически.
Как только появится необходимость работы с файлами по размеру бОльшими чем лимиты телеграмма то они снова понадобятся.
К тому же например, отредактировать пост месячной давности уже нельзя, делится файлами с теми кто не пользуется телеграмом и т.д., так что телега не универсальный вариант.
Да и для таких вещей, давно есть два общепринятых инструмента, для обмена данными публично: Github и Gitlab.
Словари в таких задач действительно удобны. Единственное что появится вопрос сохранения состояний при перезапуске (если оно нужно).
И тогда можно прийти к конфиг файлам, куда есть возможность как добавить так и изменить переменные. Это ещё и полезно, если будут ошибки, то можно будет не опасаться того что состояния вернулись к стандартным.
На самом деле попросить ллм в конце объяснить как она поняла задачу вполне неплохое решение. Единственное, что всегда нужно помнить про окно контекста, ведь в рамках диалога модель принимает все что пишет она и мы. А если расспрашивать достаточно часто, то можно забить контекст и часть обсужденного раньше можно затеряться.
Понятно что это окно довольно большое, даже очень, и все же это тоже стоит учитывать.
В моих проектах использую в основном 4о или о3, как по мне они справляются лучше, особенно в решении проблем и ошибок, о3 в частности. Модель 4.1 не всегда справляется хорошо, на вид 4о даёт результат лучше (но тесты я не проводил, это сугубо как выглядит внешне), точнее.
И в целом, читал где-то, что к моделям стоит обращаться (и относиться) как к группе начитанных студентов или ботану, который умудрился прочитать всю библиотеку. Так действительно проще работать.
За статью большой плюс. Написали хорошо и интересно. На счет не очень ярких диодов, посмотрите те же видео где узнали по фрезеровку плат, судя по картинкам у них вышло ярче, сравните со своей реализацией, может натолкнет на мысли.
Это понятно. Все зависит от модели которую используем. Про настолько большую разницу в 20 секунд и речи быть не может, слишком большая разница, это и так понятно.
Учитывая что для RAG не обязательно использовать тяжеловесную модель, предположу что более-менее вменяемый результат можно будет получить, но конечно нужно тестировать. Кстати стало интересно сравнить через Ollama.
В целом может быть юзабельно даже на CPU, тут вопрос в том какой CPU использовать. Тот же условный Ryzen на 6-8 ядер сможет выдать приемлемую скорость, но конечно с GPU не сравнить.
Такой подход я лично не тестировал, но запускал модель обработки "дипфейков" для вебкамеры наживо. Без CUDA получал до 10 кадров, слайдшоу такое себе конечно, но как факт что можно запустить.
Тут не соглашусь, это не всегда хорошо. Встречал ситуацию в Германии, когда человеку не засчитали проф. экзамен из за того, что он расписал больше чем нужно было в задании.
Мотивировали тем, что человек не может уложиться а рамки задания, а значит не сможет выполнять четко поставленные задачи как требуется.
Поэтому это очень тонкий ход, который я бы не стал использовать. Показывать знания лучше уже не рабочем месте на 110%.
В целом, если расчет на более узкую аудиторию в виде разработчиков, то технической будет достаточно, главное хорошо и подробно описать.
Если ориентировка все таки на публику то да, удобнее было бы иметь "Quick Start Guide" как пишут во многих документациях.
Для нее можно использовать готовые шаблоны и хостить как отдельный репозиторий на том же гитхабе. Либо использовать Telegraph, что в целом тоже не плохо. Тут уже как вам удобно.
Тогда и вопроса нет :) Если Вам так удобнее писать, то так и делайте. Это уже стилистические моменты, главное это сам продукт. 👍
Это конечно да, но интересно как будет справляться ffmpeg при обработке с whisper, имею в виду не самую тяжёлую модель. В любом случае звучит интересно.
Тут я не совсем понятно описал что хотел, тут имелось в виду пример создания бота с использованием ядра, т.е. банально описанные конфиги/код/файлы, как пример использования ядра со стороны разработки.
Возможно этот пример есть в Github, тогда вопрос снимается.
Вообще да, из за обилия ЛЛМ, подобные тексты воспринимаются сугубо как ИИ генерация. Поэтому лично я придерживаюсь сухой классики, чего-то близкого к академическому/публицистическому стилю.
Проект звучит интересно, не до конца понял как конкретно его использовать на реальном примере, но допустим. Не могу сказать сразу, что статья написана (как и код) через ИИ, однако по обилию эмодзи в README и стилю описаний, будто бы GPT с промптом на обезличивание.
Поэтому пока сложно оценить проект. Выглядит не плохо, интересно, посмотрим к чему придет проект.
В моем случае NexCloud был достаточно не удобным. Ставил из под Докера с туннелем через Cloudflare. Хотел себе личное облако куда можно удобно скидывать файлы, как с ПК, так и с телефона.
Основным неудобством было то, что мобильное приложение в плей маркете не может авторизоваться на севере, постоянно приходит запрос через unsplash. Пытался исправить но так и не вышло. Хотя сам endpoint работает исправно и с браузера спокойно могу войти. Да, возможно версия на FDroid этого не имеет, но хотелось обойтись стандартным средствами.
Сам интерфейс показался устаревшим и немного не интуитивным что-ли, вспоминал GUI от Synology и вроде как выглядело удобнее, но опять же дело вкуса.
В целом да, соглашусь что NextCloud немного перегружена функциями, но это и не совсем минус. Вариативность больше.
Сейчас пробую copyparty, это не совсем то же что и NextCloud, однако в целом свою работу делает. К тому же запускается не сложно. Пока не могу для себя найти какое-то универсальное решение, которое бы подошло, но посмотрим.
Интересно и удобно все в одной библиотеке иметь. У меня конечно вопрос по поводу производительности, ffmpeg и так сама по себе не слишком лёгкая, а тут ещё whisper.
Есть такое. Как говорится, если на вас наслали DDoS - немного порадуйтесь, вы кому-то нужны 😁
Встречал такое, часто пытаются загрузить файлы на сервер, войти под logshell и т.д. Не до конца понятно зачем это делать на сайтах, которые особо никто и не посещает. И которые в случае проблем могут просто сбросить или закрыть, если они не используется практически.
Кроме GTP-5 в мобильной версии других моделей нет. И это при условии Plus подписки.
В - выбор (нет)
Как только появится необходимость работы с файлами по размеру бОльшими чем лимиты телеграмма то они снова понадобятся.
К тому же например, отредактировать пост месячной давности уже нельзя, делится файлами с теми кто не пользуется телеграмом и т.д., так что телега не универсальный вариант.
Да и для таких вещей, давно есть два общепринятых инструмента, для обмена данными публично: Github и Gitlab.
Удивительно почему победил бот компании которая опубликовала статью 🤔
Ах да...
Это тоже вариант, но конфиг файлы с секциями как по мне понятнее выглядят :)
Словари в таких задач действительно удобны. Единственное что появится вопрос сохранения состояний при перезапуске (если оно нужно).
И тогда можно прийти к конфиг файлам, куда есть возможность как добавить так и изменить переменные. Это ещё и полезно, если будут ошибки, то можно будет не опасаться того что состояния вернулись к стандартным.
Актуальный студ билет который проверяется. И насколько помню нет верификации, принадлежит ли он владельцу аккаунта.
В 2021 так же, пока был студентом, оформлял премиум на Ютубе для студентов, принцип тот же.
На самом деле попросить ллм в конце объяснить как она поняла задачу вполне неплохое решение. Единственное, что всегда нужно помнить про окно контекста, ведь в рамках диалога модель принимает все что пишет она и мы. А если расспрашивать достаточно часто, то можно забить контекст и часть обсужденного раньше можно затеряться.
Понятно что это окно довольно большое, даже очень, и все же это тоже стоит учитывать.
В моих проектах использую в основном 4о или о3, как по мне они справляются лучше, особенно в решении проблем и ошибок, о3 в частности. Модель 4.1 не всегда справляется хорошо, на вид 4о даёт результат лучше (но тесты я не проводил, это сугубо как выглядит внешне), точнее.
И в целом, читал где-то, что к моделям стоит обращаться (и относиться) как к группе начитанных студентов или ботану, который умудрился прочитать всю библиотеку. Так действительно проще работать.
За статью большой плюс. Написали хорошо и интересно. На счет не очень ярких диодов, посмотрите те же видео где узнали по фрезеровку плат, судя по картинкам у них вышло ярче, сравните со своей реализацией, может натолкнет на мысли.
Спасибо за развернутый ответ
Это понятно. Все зависит от модели которую используем. Про настолько большую разницу в 20 секунд и речи быть не может, слишком большая разница, это и так понятно.
Учитывая что для RAG не обязательно использовать тяжеловесную модель, предположу что более-менее вменяемый результат можно будет получить, но конечно нужно тестировать. Кстати стало интересно сравнить через Ollama.
В целом может быть юзабельно даже на CPU, тут вопрос в том какой CPU использовать. Тот же условный Ryzen на 6-8 ядер сможет выдать приемлемую скорость, но конечно с GPU не сравнить.
Такой подход я лично не тестировал, но запускал модель обработки "дипфейков" для вебкамеры наживо. Без CUDA получал до 10 кадров, слайдшоу такое себе конечно, но как факт что можно запустить.