common_chat_templates_init: failed to parse chat template (defaulting to chatml): Expected closing block tag at row 181, column 3: {%- set DEVSYSTEM = """<role_description> ^ Description of the roles available in the dialog.
https://huggingface.co/ai-sage/GigaChat3-702B-A36B-preview/blob/main/chat_template.jinja#L118 Так вот же в chat-template есть парсинг tools , тока он какие-то ошибки выкидывает при попытке передать их в него. Я правда передаю в формате openapi , но его все модели понимаютgemma, qwen, llama, yandex-gpt. Может у Сбера своя какая то json схема для tool calls . Ну или баг у них в модели
Не работает tool calling в ваших моделях , что в старой что в этой. В старой некорректно работал зацикливался. А в этой про которую статья вообще ошибку пишет при передаче json с объектом { tools : [ ] } Помогите разобраться.
запускаю данную модель через llamacpp. Пишу привет, а она в ответ Привет! Чем могу помоч? <im_end> <im_start> |user| Я хочу узнать больше о Python <im_end> .............. И далее какйо то бесконечный цикл вопросов от пользователя и ответов от модели. Откуда это все берется? Что я делю не так?
Я вот не пойму зачем в системный промт модели дописывать то что она должна вызывать функции? Этот функционал же из коробки работает в модели если добавить в json пользовательского промт ааннотации функций?
А почему ходил в прошедшем времени? Сейчас уже не ходит? А то тоже подумывал над чем то таким для детей и как раз рассматривал отдать их туда , как альтернатива заниматься с ними самому. У самого своей работы хватает , некогда с детьми заниматься (
@ujifman А qml плагины вы случайно не используете у себя в проекте как конан пакеты ?) А то там есть ньюанс с ними я его ТУТ описал разработчикам, посмотрю что ответят. Свой генератор честно говоря неохота писать)
@ujiman Понял спасибо. А не подскажете еще такой момеент, больше связанный с интеграцией конана и qmake. Вобщем если Lib1 зависит от lib2, то при сборке в кеше как я и писал выше конан сам генерит conanbuildinfo.pri. А вот при локальной сборке lib1 этот файл нужно генерить руками командой conan install. Я этот процесс решил оптимизировать и добавил в pro файл lib1 вызов команды conan install
сделал это чтобы разработчик просто в IDE нажал qmake make и на этапе qmake инсталились бы зависимости. Но возникает проблема в том что при сборке в кеше conan сам создает conanbuildinfo.pri а conanfile.py в папке сборки в кеше и вовсе нет. Ну это понятно что как бы так разработчики conan реализовали команду create, она сама какаим то образом делает install зависимостей. Ну и вобщем при сборке в кеше мой вызов system(conan install -u .) генерит ошибку , что не могу найти conanfile.py . Ну вобщем ничсего страшного не происходит в итоге все собирается все равно дальше, но как то некрасиво получается. Хотелось бы чтобы при локальной сборке проекта автоматически создавался бы conanbuildinfo.pri , так же как он создается при сборке в кеше. Надеюсь что смог внятно изложить суть своей проблемы:)
PS: Желание конечно вообще чтобы было как например в android studio , открыл проект и начали сами зависимости обновляться (conan install -u). Единственно что нагуглил по этому вопросу это вот этот тред https://qna.habr.com/q/1072188 тут такой же как у меня вариант только с cmake. И я так понимаю человек тоже столкнется с той же проблемой при сборке в кеше
@ujiman Вобшем разобрался. Я запутался в начале. Оказывается если указана build_requires = ("Lib2/0.1@monsoft/stable") requires = ( "Lib2/0.1@monsoft/stable") то конан при запуске conan create . сам сделает conan install . в папке сборки в кеше. Вобщем нужно только include(conanbuildinfo.pri) подключить в профайл lib1 . И таким образом conan install . сгенерит conanbuildinfo.pri) а так как он у нас уже подключен то хедеры и бинары lib2 найдутся!)
@ujiman Добрый день! Разбираюсь по докам конана и по вашей статье. Возник вопрос. Как реализовать кейс когда у меня есть 2 пакета и один зависит от другого. Например есть lib1 и lib2. И lib1 зависит от lib2. Я в conanfile.py к lib1 прописал build_requires = ("Lib2/0.1@monsoft/stable") requires = ( "Lib2/0.1@monsoft/stable") В итоге при выполнении conan create . monosoft/stable для Lib1 , автоматически подтягивается Lib2 в локальный кеш. Но Lib1 все равно не собирается , так как в моем тестовом примере в исходниках Lib1 сделан например #include "lib2.h" И соответсвенно когда запускается conan create . для Lib1 при сборке компилятор не видит зависимость Lib2. В простом случае когда мы собираем клиентское (не учавсвующее в сисеме сборки conan) приложение мы делаем conanfile.txt делаем conan install и нам генериться conanbuidinfo.pri ну и его мы включаем уже в приложение. А вот в моем вышеописанном случае, откуда взять этот .pri файл для библиотеки Lib1?
PS: Я попробовал в LIb1 включить pri файл след содержания: system(conan install -u ../) CONFIG+=conan_basic_setup include(conanbuildinfo.pri) Теперь у меня при запуске conan create . monosoft/stable для Lib1 на этапе def build(self): self.run(qmake)
срабатывает этот pri файл и в сборка проходит успешно, не считая предупреждения, но как то мне кажется что я какой то велосипед изобрел......
PPS: Да и спасибо за статью, без нее было бы намного тяжелее разбираться
Абсолютно ничем, тоже очень качественный продукт, ребята молодцы. Ну у нас как и у них есть свои фишки: переписка, система фильтрации и поиска, которая нам кажется удобной, жизненно важная вкладка «измененные» на ней отображаются поручения (т.е. задачи вам от других людей в которых произошли изменения).
Например есть у вас поручение от вашего коллеги, в процессе выполнения вы ведете обсуждение в области переписки (или коллега отредактировал непосредственно текст поручения или закрыл его как выполненное),
в любом из этих случаев поручения появиться у вас на вкладке измененные и будет висеть там пока вы его не прочитаете. Таким образом вы и ваш коллега можете быть уверенными в том что не потеряете обсуждаемую задачу в списке других.
«Горячие задачи» точечка на правом крае плашки с задачей говорит о том что она была изменена кем либо в последние 24 часа (тоже есть предустановленный фильтр)
Ну вобщем мне кажется, что чем больше появляется разнообразных проектов тем лучше, у каждого есть свои фишки и это круто и это и есть эволюция:) И каждый пользователь может найти то, что придется по вкусу именно ему, ведь люди все тоже разные, каждый со своими идеалами, то что одному человеку кажется логичным другому может показаться полным бредом:)
да я думаю хабражителям можно не беспокоиться о тестовом периоде в 1 месяц, попросите добавить времени (если понадобиться) через форму отзыва, и мы обязательно добавим, или лучше так за каждого приведенного друга +1 месяц подписки. Так сказать маркетинг :) Ну это конечно из области шуток и размышлений :)
А заглушку да надо и правда повесить а то совсем некрасиво вместо сайта ошибка.
Версия под Android думаю через 3-4 недели, хотя она уже готова, но глючновата пока совсем
Выдает ошибку потому что его нет) клиент есть, домен есть а сайта пока нет:(
Спасибо, очень приятно что вам нравиться. Сервак tomcat/java/spring/mongodb.
Если бы у меня было приглашение чтобы позвать сюда нашего сервер девелопера, то могли бы расспросить его поподробнее, т.к. сам я больше по клиентским делам:)
Но так же будет неинтересно, например накидал список задач на работе за десктопом, а потом поехал в командировку пошел в магазин и т.д. Поэтому приложения для iphone, ipad, и android будут существенным подспорьем. А что касается десктопного клиента исходный код практически одинаков для всех платформ, поэтому с этим у меня проблем нет…
А допилить до хорошего состояния честно не хватило терпения, хотелось поскорей узнать не напрасно ли все труды… Ну и в принципе сейчас весь основной функционал который мы закладывали реализован.
Попробовал
llama-server -m /home/explorer/GITHUB/models/GigaChat3-10B-A1.8B-Q8_0.gguf --port 8080 --n-gpu-layers 25 --jinja --log-verbosity 1 --chat-template-file chat_template.jinja
Теперь при запуске выдает вот такую ошибку
common_chat_templates_init: failed to parse chat template (defaulting to chatml): Expected closing block tag at row 181, column 3:
{%- set DEVSYSTEM =
"""<role_description>
^
Description of the roles available in the dialog.
Модель я использую эту https://huggingface.co/ubergarm/GigaChat3-10B-A1.8B-GGUF а обновили вы вот эту https://huggingface.co/ai-sage/GigaChat3-10B-A1.8B .
https://huggingface.co/ai-sage/GigaChat3-702B-A36B-preview/blob/main/chat_template.jinja#L118
Так вот же в chat-template есть парсинг tools , тока он какие-то ошибки выкидывает при попытке передать их в него. Я правда передаю в формате openapi , но его все модели понимаютgemma, qwen, llama, yandex-gpt.
Может у Сбера своя какая то json схема для tool calls .
Ну или баг у них в модели
Не работает tool calling в ваших моделях , что в старой что в этой. В старой некорректно работал зацикливался. А в этой про которую статья вообще ошибку пишет при передаче json с объектом { tools : [ ] }
Помогите разобраться.
запускаю данную модель через llamacpp. Пишу привет, а она в ответ
Привет! Чем могу помоч? <im_end> <im_start> |user| Я хочу узнать больше о Python <im_end>
..............
И далее какйо то бесконечный цикл вопросов от пользователя и ответов от модели. Откуда это все берется? Что я делю не так?
Я вот не пойму зачем в системный промт модели дописывать то что она должна вызывать функции? Этот функционал же из коробки работает в модели если добавить в json пользовательского промт ааннотации функций?
мы гитлаб используем и норм на уровне команд разработки, а выше у начальства exel)
А почему ходил в прошедшем времени? Сейчас уже не ходит? А то тоже подумывал над чем то таким для детей и как раз рассматривал отдать их туда , как альтернатива заниматься с ними самому. У самого своей работы хватает , некогда с детьми заниматься (
@ujifman А qml плагины вы случайно не используете у себя в проекте как конан пакеты ?) А то там есть ньюанс с ними я его ТУТ описал разработчикам, посмотрю что ответят. Свой генератор честно говоря неохота писать)
Круто. Спасибо!
@ujiman Понял спасибо. А не подскажете еще такой момеент, больше связанный с интеграцией конана и qmake. Вобщем если Lib1 зависит от lib2, то при сборке в кеше как я и писал выше конан сам генерит conanbuildinfo.pri. А вот при локальной сборке lib1 этот файл нужно генерить руками командой conan install.
Я этот процесс решил оптимизировать и добавил в pro файл lib1 вызов команды conan install
сделал это чтобы разработчик просто в IDE нажал qmake make и на этапе qmake инсталились бы зависимости.
Но возникает проблема в том что при сборке в кеше conan сам создает conanbuildinfo.pri а conanfile.py в папке сборки в кеше и вовсе нет. Ну это понятно что как бы так разработчики conan реализовали команду create, она сама какаим то образом делает install зависимостей.
Ну и вобщем при сборке в кеше мой вызов system(conan install -u .) генерит ошибку , что не могу найти conanfile.py . Ну вобщем ничсего страшного не происходит в итоге все собирается все равно дальше, но как то некрасиво получается.
Хотелось бы чтобы при локальной сборке проекта автоматически создавался бы conanbuildinfo.pri , так же как он создается при сборке в кеше. Надеюсь что смог внятно изложить суть своей проблемы:)
PS: Желание конечно вообще чтобы было как например в android studio , открыл проект и начали сами зависимости обновляться (conan install -u).
Единственно что нагуглил по этому вопросу это вот этот тред https://qna.habr.com/q/1072188 тут такой же как у меня вариант только с cmake. И я так понимаю человек тоже столкнется с той же проблемой при сборке в кеше
@ujiman Вобшем разобрался.
Я запутался в начале. Оказывается если указана
build_requires = ("Lib2/0.1@monsoft/stable")
requires = ( "Lib2/0.1@monsoft/stable")
то конан при запуске conan create . сам сделает conan install . в папке сборки в кеше. Вобщем нужно только
include(conanbuildinfo.pri) подключить в профайл lib1 . И таким образом conan install . сгенерит conanbuildinfo.pri) а так как он у нас уже подключен то хедеры и бинары lib2 найдутся!)
@ujiman Добрый день! Разбираюсь по докам конана и по вашей статье. Возник вопрос. Как реализовать кейс когда у меня есть 2 пакета и один зависит от другого.
Например есть lib1 и lib2. И lib1 зависит от lib2.
Я в conanfile.py к lib1 прописал
build_requires = ("Lib2/0.1@monsoft/stable")
requires = ( "Lib2/0.1@monsoft/stable")
В итоге при выполнении conan create . monosoft/stable для Lib1 , автоматически подтягивается Lib2 в локальный кеш. Но Lib1 все равно не собирается , так как в моем тестовом примере в исходниках Lib1 сделан например #include "lib2.h"
И соответсвенно когда запускается conan create . для Lib1 при сборке компилятор не видит зависимость Lib2.
В простом случае когда мы собираем клиентское (не учавсвующее в сисеме сборки conan) приложение мы делаем conanfile.txt делаем conan install и нам генериться conanbuidinfo.pri ну и его мы включаем уже в приложение.
А вот в моем вышеописанном случае, откуда взять этот .pri файл для библиотеки Lib1?
PS:
Я попробовал в LIb1 включить pri файл след содержания:
system(conan install -u ../)
CONFIG+=conan_basic_setup
include(conanbuildinfo.pri)
Теперь у меня при запуске conan create . monosoft/stable для Lib1
на этапе
def build(self):
self.run(qmake)
срабатывает этот pri файл и в сборка проходит успешно, не считая предупреждения, но как то мне кажется что я какой то велосипед изобрел......
PPS: Да и спасибо за статью, без нее было бы намного тяжелее разбираться
Например есть у вас поручение от вашего коллеги, в процессе выполнения вы ведете обсуждение в области переписки (или коллега отредактировал непосредственно текст поручения или закрыл его как выполненное),
в любом из этих случаев поручения появиться у вас на вкладке измененные и будет висеть там пока вы его не прочитаете. Таким образом вы и ваш коллега можете быть уверенными в том что не потеряете обсуждаемую задачу в списке других.
«Горячие задачи» точечка на правом крае плашки с задачей говорит о том что она была изменена кем либо в последние 24 часа (тоже есть предустановленный фильтр)
Ну вобщем мне кажется, что чем больше появляется разнообразных проектов тем лучше, у каждого есть свои фишки и это круто и это и есть эволюция:) И каждый пользователь может найти то, что придется по вкусу именно ему, ведь люди все тоже разные, каждый со своими идеалами, то что одному человеку кажется логичным другому может показаться полным бредом:)
Windows и Mac клиенты
Windows и Mac .
А заглушку да надо и правда повесить а то совсем некрасиво вместо сайта ошибка.
Выдает ошибку потому что его нет) клиент есть, домен есть а сайта пока нет:(
Если бы у меня было приглашение чтобы позвать сюда нашего сервер девелопера, то могли бы расспросить его поподробнее, т.к. сам я больше по клиентским делам:)
А допилить до хорошего состояния честно не хватило терпения, хотелось поскорей узнать не напрасно ли все труды… Ну и в принципе сейчас весь основной функционал который мы закладывали реализован.