Еще раз спасибо за совет. Я поэкспериментировал с форматом GGUF. Загружал с помощью ollama.
К сожалению, модель 30B влезает в мою видеопамять только наполовину. Я подобрал вот такую модель: Qwen3-14B-GGUF:q5_K_M с контекстом 4096. Она занимает 11ГБ видеопамяти и полностью помещается на моей видеокарточке. Благодаря этому и благодаря формату GGUF скорость работы возросла очень сильно.
Ответ да-нет теперь возвращается через 150-600 миллисекунд! Генерация сообщения - 2-5 секунд. В целом бот отвечает за 5-10 секунд. Теперь с ним общаешься не как с человеком, который печатает сообщения, а как с машиной, которая отвечает сразу. Ну, с поправкой на небольшие тормоза. Это прямо меняет ощущение от бота.
Я пробовал также, какая будет скорость работы с Qwen3-30B-A3B-GGUF. Она, хоть и обрабатывается частично процессором, выдает ответы не сильно медленнее, где-то в полтора раза. По качеству генерации 14B держит требуемый уровень. Переход с q4 на q5, кажется, дает заметную прибавку, но это не точно, надо получше потестировать. Я также сравнивал Qwen3-30B-A3B-GGUF и Qwen3-14B-GGUF на задаче "придумай и расскажи историю про выживание на необитаемом острове" - 14B показалась даже получше. Возможно A3B портит результат на задачах чистого понимания и генерации текста. Чистую 30B не пробовал, повышать квантизацию на 30B не пробовал.
В целом 14B q5 работает практически как надо. Я тестировал диалоги и подумал, что неплохо было бы добавить проверку в такой логике: если пользователь заказал срочные работы, модель должна переспросить, согласен ли он на двойную оплату. Я просто добавил строчку в конфиг-файл, сформулировал вопрос и условие, и все заработало с первого раза!
Ответ занимает меньше минуты. Все еще быстрее, чем когда переписываешься с человеком. Ты мог бы попробовать пообщаться сам, бот работает. Просто заходи по адресу и начинай диалог.
Судя по моим экспериментам с локальными моделями, генерация картинок требует меньше ресурсов, чем генерация текста. В любом случае, ваш скриншот выглядит круто. Но какую помощь мы окажем условному токарю, используя этот функционал?
Поговорить - это сложно. Вы не сталкивались с ситуацией "мы на связи с 9 до 18 в рабочие дни"? Держать секретаря 24/7 для мелкого бизнеса бывает накладно.
С другой стороны, я попробовал сделать бота, который задает вопросы только по делу. В идеале чтобы общение с ботом не очень отличалось от общения с живым человеком.
Ну вот, собственно, я и сделал. Можно было взять мультимодальную, но я не уверен, что ИИ сможет вытащить что-то вменяемое из картинки. Текстовое описание "тут изображен болт" - можно, да, но какая от этого польза токарю? Разве что проверить, что картинка действительно на тему заказа, но мне кажется, от этого не сильно много толку.
На первый взгляд кажется просто, но я вот нигде не видел такого в коммерческих решениях. Если вы видели, дайте ссылку.
Не могу пройти мимо, когда в интернете кто-то не прав. Я, к сожалению, испытал на себе язву 12-перстной кишки. Лечился сначала таблетками, естественно по назначению врача, естественно после всех необходимых анализов. Принимал как мог аккуратно: ставил будильники, чтобы съесть одну таблетку за 30 минут до еды, другую — 30 минут после еды. Принимал антибиотики от бактерий и еще несколько других препаратов. Результат: острое состояние удалось снять, но здоровым я себя не чувствовал. Пробовал повторять лечение, естественно, по назначению врача после сдачи анализов — результат не сильно лучше.
Пробовал диету. Диета помогает гораздо эффективнее. С диетой ты чувствуешь себя хорошо, а съешь что-то не то — боль, слабость, изжога и так далее. Опять же, диета оказалась достаточно неожиданной. Скажем, одним из самых вредных блюд оказался суп. Если внимательно почитать про стол номер 1, то выяснится, что нельзя бульон и нельзя капусту.
Пробовал спорт — можно до некоторой степени выменивать погрешность в диете на тренировку. Но самым эффективным оказалось немного похудеть...
Не утверждаю, что мой рецепт поможет всем. У кого-то, может быть, генетическая особенность, у кого-то сильное влияние внешних факторов. Но думаю, что если вы не имеете наследственных болезней и живете обычной жизнью, вас поставит на ноги на первых порах диета, а в долгосрочной перспективе — похудение и физкультура. А не таблетки.
Ну мой литий к моменту разряда уже соединен с кислородом. Лучше сбросить аккумулятор, чем упасть всему аппарату.
Впрочем, это, конечно, пока область фантазий, не стоит особых обсуждений.
Надо бы собрать кладбище разрекламированных, но загнувшихся идей.
1) Сегвей как убийца традиционных авто
2) Суборбительный космический туризм
3) Mars one
4) Google glass
5) Бытовая 3d-печать как массовое явление
6) Space Shuttle как убийца одноразовых ракет
7) Аэротакси как массовая услуга на основе мультикоптеров и прочих нетрадиционных ЛА
Мы не слишком далеко от фундаментальных ограничений, раза в два еще может быть, когда нибудь, химические источники тока и выдадут.
Предел эффективности химических источников тока ограничен примерно характеристиками бензобака с бензином. Это на порядок-другой больше, чем сейчас. То есть, тут есть куда расти.
Такой аккумулятор мог бы получиться, если бы химики нашли какое-то вещество, которое может соединяться с кислородом воздуха и давать ток, а при зарядке возвращать кислород. Да, аккумулятор бы тяжелел в процессе полета, но лишний вес на посадке не так критичен, как на взлете, а в аварийной ситуации разряженный потяжелевший аккумулятор можно сбросить.
Странно, что не упомянули вот такой работающий алгоритм:
После праздника, перед тем, как лечь спать, пьем много воды. 0.5 литра, или больше — сколько влезет.
Ночью просыпаемся от гидробудильника. Выполняем основную миссию, затем опять пьем воду, 0.5 литра или больше. Если данный пункт происходит несколько раз за ночь — так и хорошо.
Отлично. Но заявка должна браться не из хотения заявляющего, а с какого-то внешнего проекта, или из поручения топа. Вот эти 100500 от склада должны суммироваться в бюджет внешнего проекта, или в бюджет изначальной заявки. И в конце можно будет поднять вопрос эффективности работы отделов при выполнении изначальной задачи.
Рассказывали, как группа товарищей пыталась совместить кайт и манутинборд, катались по полям. Среднее время до обращения в медпункт составляло 5 минут.
Я посмотрел несколько роликов (не все). На тех, что я смотрел — робот выполнял действия совместно с человеком. Человек подавал штуку, робот ее брал, вертел, обрабатывал и возвращал назад. Думаю, что в таком сценарии робот не может заменить 2-3 рабочих. Чтобы робот смог заменить рабочего, его надо научить брать деталь из коробки, в которой деталь может лежать любым боком. Искать отвертку, которая куда-то завалилась, замазывать брак с предыдущего участка, за кружкой пива обсуждать с технологом, как бы оптимизировать процесс. И тут дело не в подшипниках…
В прочем, в этой области я теоретик. Было бы интересно услышать отзывы практиков.
Несколько лет назад написал пару статей в лурку. Скажу так: там никого не волнуют такие нюансы, как ссылки на авторитетные источники, и т.п. Текст должен быть увлекательным, текст не должен быть похож на выдумку или личное мнение. Текст должен быть про нечто более-менее на слуху. Этого достаточно.
Если напишешь что-то, что кто-нибудь может принять на свой счет и обидеться — удалят. Например, у меня из песни выкинули четверостишье. Я не встал на тропу войны правок, я заметил-то это через месяцы.
Вы немного не о том написали. Вы написали о бизнес сценарии «отмена турпоездки» или «изменение в планах поездки». Наша система тоже это умеет — надо заложить дополнительные правила по отмене ненужных действий. Система построит новый процесс, в котором будут шаги по отмене ненужных действий и совершению новых нужных (например, отменить бронирование гостиницы, забронировать яхту на эти же даты).
Но это просто дополнительные требования, которые могут быть, а могут и нет. Изначально я писал о том, что если произошла техническая ошибка (код выбросил исключение), то нет общего способа решить проблему без программиста. Предложили вариант откатиться на последнее ручное действие — это не подходит, т.к. отмена в общем случае не реализуема.
Пример. Процесс планирования турпоездки. Одно из действий — бронирование гостиницы — автоматизировано. Наша система посылает в систему бронирования запрос, система бронирования что-то отвечает. Внезапно интерфейс системы бронирования чуть-чуть поменяли, или решили забронировать какую-то нестандартную гостиницу. Ответ от системы бронирования пришел и был провалидирован, но на одном из дальнейших шагов (скажем, распечатка памятки для клиента) произошла системная ошибка — гостиница называлась корейскими иероглифами, для которых не нашлось шрифтов.
Автоматически подобные ошибки не решить: мы не знаем, какие шаги отменять. И как их правильно отменять. Если мы попробуем включить процесс «компенсации», то он тоже может упасть на каком-нибудь шаге вроде «распечатки квитанции об отмене».
По мне так должна быть одна система, в которой гармонично переплетаются PM/BPM/ACM. И далее выясняется, что ИС должна быть тесно интегрирована с ERP & CRM.
Как в известном анекдоте: «мышки, станьте ежиками».
Тут можно было бы сделать блокирвоку, что невалидная заявка не снимается с данного пользователя. Так и болтается в его списке задач. И еще продумать форму ввода адреса, чтобы не вбивали кривые адреса.
Ошибка может проявиться через много шагов после того, как были вбиты данные. Естественно, этого пытаются избежать, но мир не идеален и всякое бывает. Проблема еще и в том, что в том подходе, который описан в статье, задача отката не решается, если только специально не создавать точки отката. Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
Еще раз спасибо за совет. Я поэкспериментировал с форматом GGUF. Загружал с помощью ollama.
К сожалению, модель 30B влезает в мою видеопамять только наполовину. Я подобрал вот такую модель: Qwen3-14B-GGUF:q5_K_M с контекстом 4096. Она занимает 11ГБ видеопамяти и полностью помещается на моей видеокарточке. Благодаря этому и благодаря формату GGUF скорость работы возросла очень сильно.
Ответ да-нет теперь возвращается через 150-600 миллисекунд! Генерация сообщения - 2-5 секунд. В целом бот отвечает за 5-10 секунд. Теперь с ним общаешься не как с человеком, который печатает сообщения, а как с машиной, которая отвечает сразу. Ну, с поправкой на небольшие тормоза. Это прямо меняет ощущение от бота.
Я пробовал также, какая будет скорость работы с Qwen3-30B-A3B-GGUF. Она, хоть и обрабатывается частично процессором, выдает ответы не сильно медленнее, где-то в полтора раза. По качеству генерации 14B держит требуемый уровень. Переход с q4 на q5, кажется, дает заметную прибавку, но это не точно, надо получше потестировать. Я также сравнивал Qwen3-30B-A3B-GGUF и Qwen3-14B-GGUF на задаче "придумай и расскажи историю про выживание на необитаемом острове" - 14B показалась даже получше. Возможно A3B портит результат на задачах чистого понимания и генерации текста. Чистую 30B не пробовал, повышать квантизацию на 30B не пробовал.
В целом 14B q5 работает практически как надо. Я тестировал диалоги и подумал, что неплохо было бы добавить проверку в такой логике: если пользователь заказал срочные работы, модель должна переспросить, согласен ли он на двойную оплату. Я просто добавил строчку в конфиг-файл, сформулировал вопрос и условие, и все заработало с первого раза!
Спасибо за совет, поэкспериментирую.
Ответ занимает меньше минуты. Все еще быстрее, чем когда переписываешься с человеком. Ты мог бы попробовать пообщаться сам, бот работает. Просто заходи по адресу и начинай диалог.
Судя по моим экспериментам с локальными моделями, генерация картинок требует меньше ресурсов, чем генерация текста. В любом случае, ваш скриншот выглядит круто. Но какую помощь мы окажем условному токарю, используя этот функционал?
Поговорить - это сложно. Вы не сталкивались с ситуацией "мы на связи с 9 до 18 в рабочие дни"? Держать секретаря 24/7 для мелкого бизнеса бывает накладно.
С другой стороны, я попробовал сделать бота, который задает вопросы только по делу. В идеале чтобы общение с ботом не очень отличалось от общения с живым человеком.
Ну вот, собственно, я и сделал. Можно было взять мультимодальную, но я не уверен, что ИИ сможет вытащить что-то вменяемое из картинки. Текстовое описание "тут изображен болт" - можно, да, но какая от этого польза токарю? Разве что проверить, что картинка действительно на тему заказа, но мне кажется, от этого не сильно много толку.
На первый взгляд кажется просто, но я вот нигде не видел такого в коммерческих решениях. Если вы видели, дайте ссылку.
Не могу пройти мимо, когда в интернете кто-то не прав. Я, к сожалению, испытал на себе язву 12-перстной кишки. Лечился сначала таблетками, естественно по назначению врача, естественно после всех необходимых анализов. Принимал как мог аккуратно: ставил будильники, чтобы съесть одну таблетку за 30 минут до еды, другую — 30 минут после еды. Принимал антибиотики от бактерий и еще несколько других препаратов. Результат: острое состояние удалось снять, но здоровым я себя не чувствовал. Пробовал повторять лечение, естественно, по назначению врача после сдачи анализов — результат не сильно лучше.
Пробовал диету. Диета помогает гораздо эффективнее. С диетой ты чувствуешь себя хорошо, а съешь что-то не то — боль, слабость, изжога и так далее. Опять же, диета оказалась достаточно неожиданной. Скажем, одним из самых вредных блюд оказался суп. Если внимательно почитать про стол номер 1, то выяснится, что нельзя бульон и нельзя капусту.
Пробовал спорт — можно до некоторой степени выменивать погрешность в диете на тренировку. Но самым эффективным оказалось немного похудеть...
Не утверждаю, что мой рецепт поможет всем. У кого-то, может быть, генетическая особенность, у кого-то сильное влияние внешних факторов. Но думаю, что если вы не имеете наследственных болезней и живете обычной жизнью, вас поставит на ноги на первых порах диета, а в долгосрочной перспективе — похудение и физкультура. А не таблетки.
Ну мой литий к моменту разряда уже соединен с кислородом. Лучше сбросить аккумулятор, чем упасть всему аппарату.
Впрочем, это, конечно, пока область фантазий, не стоит особых обсуждений.
Надо бы собрать кладбище разрекламированных, но загнувшихся идей.
1) Сегвей как убийца традиционных авто
2) Суборбительный космический туризм
3) Mars one
4) Google glass
5) Бытовая 3d-печать как массовое явление
6) Space Shuttle как убийца одноразовых ракет
7) Аэротакси как массовая услуга на основе мультикоптеров и прочих нетрадиционных ЛА
Кто еще что припомнит из этой же серии?
Предел эффективности химических источников тока ограничен примерно характеристиками бензобака с бензином. Это на порядок-другой больше, чем сейчас. То есть, тут есть куда расти.
Такой аккумулятор мог бы получиться, если бы химики нашли какое-то вещество, которое может соединяться с кислородом воздуха и давать ток, а при зарядке возвращать кислород. Да, аккумулятор бы тяжелел в процессе полета, но лишний вес на посадке не так критичен, как на взлете, а в аварийной ситуации разряженный потяжелевший аккумулятор можно сбросить.
Странно, что не упомянули вот такой работающий алгоритм:
После праздника, перед тем, как лечь спать, пьем много воды. 0.5 литра, или больше — сколько влезет.
Ночью просыпаемся от гидробудильника. Выполняем основную миссию, затем опять пьем воду, 0.5 литра или больше. Если данный пункт происходит несколько раз за ночь — так и хорошо.
Утром последствия почти не ощущаются.
В прочем, в этой области я теоретик. Было бы интересно услышать отзывы практиков.
Если напишешь что-то, что кто-нибудь может принять на свой счет и обидеться — удалят. Например, у меня из песни выкинули четверостишье. Я не встал на тропу войны правок, я заметил-то это через месяцы.
Но это просто дополнительные требования, которые могут быть, а могут и нет. Изначально я писал о том, что если произошла техническая ошибка (код выбросил исключение), то нет общего способа решить проблему без программиста. Предложили вариант откатиться на последнее ручное действие — это не подходит, т.к. отмена в общем случае не реализуема.
Пример. Процесс планирования турпоездки. Одно из действий — бронирование гостиницы — автоматизировано. Наша система посылает в систему бронирования запрос, система бронирования что-то отвечает. Внезапно интерфейс системы бронирования чуть-чуть поменяли, или решили забронировать какую-то нестандартную гостиницу. Ответ от системы бронирования пришел и был провалидирован, но на одном из дальнейших шагов (скажем, распечатка памятки для клиента) произошла системная ошибка — гостиница называлась корейскими иероглифами, для которых не нашлось шрифтов.
Автоматически подобные ошибки не решить: мы не знаем, какие шаги отменять. И как их правильно отменять. Если мы попробуем включить процесс «компенсации», то он тоже может упасть на каком-нибудь шаге вроде «распечатки квитанции об отмене».
Как в известном анекдоте: «мышки, станьте ежиками».
Ошибка может проявиться через много шагов после того, как были вбиты данные. Естественно, этого пытаются избежать, но мир не идеален и всякое бывает. Проблема еще и в том, что в том подходе, который описан в статье, задача отката не решается, если только специально не создавать точки отката. Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?