Недавно слушал доклад про схожее решение с автоматизацией работы доменного эксперта. Тут пошли дальше: ассистент не только помогает с документацией, но и может в код. Явно вырисовывается тренд на 2024 год, осталось поймать волну 🏄♂️
👍2
Forwarded from Pavel Zloi
Всем привет! Хочу рассказать про ещё одну обученную мною модель под названием PavelGPT-7B-128K-v0.1-LoRA, на этот раз я взял скрипты Saiga (rulm) и модифицировал их таким образом, чтобы получить языковую модель типа INSTRUCT, но с данными оформленными в виде чата (для того чтобы её было легко использовать в связке с проектами типа text-generation-webui).
В качестве основы взял Yarn-Mistral-7b-128k, а датасеты собирал так, чтобы модель могла не только решать базовые задачи, но и отгадывать загадки, а ещё решать несложные математические задачки, писать небольшие тексты, составлять оглавление и создавать простые скрипты.
Вот все ссылочки, которые могут пригодиться:
- скрипт обучения модели
- отчёт обучения на wandb
- тестовые ответы модели в карточке на huggingface
- скрипт запуска модели
PS. Мне давно хотелось сделать себе чуть более умного помощника для работы с документацией которую я храню в Obsidian и пока что впечатления от использования данной модели более приятные чем от предыдущих моих экспериментов.
Надеюсь вам данная моделька тоже окажется полезной :)
#ai #saiga #gpt
В качестве основы взял Yarn-Mistral-7b-128k, а датасеты собирал так, чтобы модель могла не только решать базовые задачи, но и отгадывать загадки, а ещё решать несложные математические задачки, писать небольшие тексты, составлять оглавление и создавать простые скрипты.
Вот все ссылочки, которые могут пригодиться:
- скрипт обучения модели
- отчёт обучения на wandb
- тестовые ответы модели в карточке на huggingface
- скрипт запуска модели
PS. Мне давно хотелось сделать себе чуть более умного помощника для работы с документацией которую я храню в Obsidian и пока что впечатления от использования данной модели более приятные чем от предыдущих моих экспериментов.
Надеюсь вам данная моделька тоже окажется полезной :)
#ai #saiga #gpt
👍2
Походу олимпиадников автоматизируют быстрее, чем джсонукладчиков с завода 🏭
👍2
Forwarded from Knowledge Accumulator
AutoNumerics-Zero: Automated Discovery of State-of-the-Art Mathematical Functions [2023] - ещё одно AI-открытие уходящего года
Продолжаем тему оптимизации программ. Почти одновременно с FunSearch вышла другая работа от Deepmind, правда, не применяющая LLM, и поэтому попавшая только в Just Links. Идеологически она похожа на AutoML-Zero, про который я уже тоже писал пост.
Итак, мы умеем легко и быстро производить на компьютере 4 базовые арифметические операции. Однако, "трансцендентные" функции, например, экспоненту, нельзя легко посчитать. Компьютер их считает приближённо, например, с помощью ряда Тейлора. При этом, нам достаточно уметь приближать её на промежутке [0;1], т.к. в целую степень мы умеем легко возводить и таким образом получить любую степень.
Итак, задача - найти как можно более короткую / быструю программу, вычисляющую экспоненту на отрезке с заданной точностью. Авторы представляют программу в виде графа вычислений (см. картинку). Вершинами является вход x, выход f, константы и математические операции, в которые по направленным рёбрам попадают входные данные.
Генетический алгоритм поддерживает популяцию графов, случайно добавляет мутации в них - добавление вершин, удаление, замена ребра и т.д. Оптимизируется одновременно точность и скорость (кол-во операций или время исполнения). Так как у нас 2 важных критерия отбора, используется специальный алгоритм сортировки популяции, выбирающий программы, сбалансированные по-разному с точки зрения критериев.
В результате, алгоритм не оставляет камня на камне от бейзлайнов, созданных приматами. Количество операций сокращается примерно в 2 раза, но это не самое крутое. Алгоритм подбирает функции так, чтобы компилятор оптимизировал их наиболее выгодно, в итоге скорость возрастает в >3 раза.
И вновь кожанные мешки показывают свою несостоятельность в сложных многослойных задачах, которые нельзя разбить на изолированные кусочки. End-to-end алгоритмическая оптимизация не оставляет нам никаких шансов.
@knowledge_accumulator
Продолжаем тему оптимизации программ. Почти одновременно с FunSearch вышла другая работа от Deepmind, правда, не применяющая LLM, и поэтому попавшая только в Just Links. Идеологически она похожа на AutoML-Zero, про который я уже тоже писал пост.
Итак, мы умеем легко и быстро производить на компьютере 4 базовые арифметические операции. Однако, "трансцендентные" функции, например, экспоненту, нельзя легко посчитать. Компьютер их считает приближённо, например, с помощью ряда Тейлора. При этом, нам достаточно уметь приближать её на промежутке [0;1], т.к. в целую степень мы умеем легко возводить и таким образом получить любую степень.
Итак, задача - найти как можно более короткую / быструю программу, вычисляющую экспоненту на отрезке с заданной точностью. Авторы представляют программу в виде графа вычислений (см. картинку). Вершинами является вход x, выход f, константы и математические операции, в которые по направленным рёбрам попадают входные данные.
Генетический алгоритм поддерживает популяцию графов, случайно добавляет мутации в них - добавление вершин, удаление, замена ребра и т.д. Оптимизируется одновременно точность и скорость (кол-во операций или время исполнения). Так как у нас 2 важных критерия отбора, используется специальный алгоритм сортировки популяции, выбирающий программы, сбалансированные по-разному с точки зрения критериев.
В результате, алгоритм не оставляет камня на камне от бейзлайнов, созданных приматами. Количество операций сокращается примерно в 2 раза, но это не самое крутое. Алгоритм подбирает функции так, чтобы компилятор оптимизировал их наиболее выгодно, в итоге скорость возрастает в >3 раза.
И вновь кожанные мешки показывают свою несостоятельность в сложных многослойных задачах, которые нельзя разбить на изолированные кусочки. End-to-end алгоритмическая оптимизация не оставляет нам никаких шансов.
@knowledge_accumulator
👍2
Довольно занимательная статья, как писать вики будущего
Dmitry Soshnikov AKA shwars
Создаём предметно-ориентированного чат-бота с помощью LangChain и Yandex GPT
Большие языковые модели могут прекрасно поддерживать разговор на общие темы, но как же быть, если необходимо добавить такому чат-боту предметных знаний? Посмотрим, как использовать подход Retrieval-Augmented Generation для создания такого предметного чат…
👍3
Forwarded from Love. Death. Transformers.
Мы релизнули вихрь💨 Нормально.
Проблемы: мы не очень уверены что оно точно аутперформит mistral и saiga mistral. Формально - да, все хорошо.
Цитируя классику
Если вам интересно что мы сделали: хабр
А еще оформили все в красивую HF репу: https://huggingface.co/Vikhrmodels
Проблемы: мы не очень уверены что оно точно аутперформит mistral и saiga mistral. Формально - да, все хорошо.
Цитируя классику
Если вам интересно что мы сделали: хабр
А еще оформили все в красивую HF репу: https://huggingface.co/Vikhrmodels
👍2
Forwarded from Код и Капуста
Ребята из grafana делают много полезных штук.
k6 - это тулза для нагрузочного тестирования. Сами тесты пишутся на js, но запускаются с помощью утилиты, которая написана на #golang
Сайт https://k6.io/
Репа https://github.com/grafana/k6
k6 - это тулза для нагрузочного тестирования. Сами тесты пишутся на js, но запускаются с помощью утилиты, которая написана на #golang
k6 run script.js
Сайт https://k6.io/
Репа https://github.com/grafana/k6
👍2
Глубинный котер
Из заметки Михаила Корнеева узнал про FastStream. В целом хорошая идея с единым интерфейсом для работы с разными очередями и генерацией документации с описанием топиков и структурой сообщений. Но самым интересным показался их отдельный пакет faststream-gen…
Команду заинтересовал faststream валидацией сообщений с помощью pydantic и генерацией AsyncAPI из коробки для работы с kafka. Поэтому решил поближе познакомиться с этим фреймворком.
Первые впечатления были конечно получше, авторам не удалось решить типичные проблемы для таких чудо швейцарских ножей: сильная связность компонентов пакета и как следствие отсутствие гибкости. Сурсы довольно мудреные, а некоторые блоки очень спорные.
Например чтение из топиков происходит в бесконечном цикле, хотя iokafka , которая используется под капотом, предоставляет приятный интерфейс итератора по сообщениям. Тут же и вызов
В итоге решили воздержаться от использования этого пакета ☠️
Первые впечатления были конечно получше, авторам не удалось решить типичные проблемы для таких чудо швейцарских ножей: сильная связность компонентов пакета и как следствие отсутствие гибкости. Сурсы довольно мудреные, а некоторые блоки очень спорные.
Например чтение из топиков происходит в бесконечном цикле, хотя iokafka , которая используется под капотом, предоставляет приятный интерфейс итератора по сообщениям. Тут же и вызов
anyio.sleep, и перехват KafkaError с засыпанием без записи в лог или рейза ошибки.В итоге решили воздержаться от использования этого пакета ☠️
👍2
Давно слышал про книжные клубы и вот наконец-то появилась возможность попробовать. Недавно начал читать «От монолита к микросервисам» Сэма Ньюмена и случайно наткнулся на ютубе на обсуждения каждой главы этой книги в рамках книжного клуба «между скобок». Ребята из клуба недалеко продвинулись по книге, поэтому решил попробовать засинкаться с ними и после прочтения каждой главы смотреть выпуск с обсуждением главы.
Интересное дополнение ко книге получается, потому что обсуждение выстраивается в виде дебата, где участники приводят аргументы за и против тех или иных практик, описанных в главе. При этом к каждой главе немного меняется состав спикеров, поэтому всегда можно услышать свежее мнение.
Мне очень понравился такой формат чтения, потому что есть возможность увидеть проблемы, поднятые в главе, под новыми углами, повторно осмыслить некоторые моменты.
Интересное дополнение ко книге получается, потому что обсуждение выстраивается в виде дебата, где участники приводят аргументы за и против тех или иных практик, описанных в главе. При этом к каждой главе немного меняется состав спикеров, поэтому всегда можно услышать свежее мнение.
Мне очень понравился такой формат чтения, потому что есть возможность увидеть проблемы, поднятые в главе, под новыми углами, повторно осмыслить некоторые моменты.
YouTube
От монолита к микросервисам. Глава 1 Основные сведения о микросервисах / Филипп Дельгядо
В рамках обсуждения первой главы мы рассмотрим понятия микросервисов и их отличия от монолитов, а также обсудим преимущества и недостатки каждого подхода. Также мы поговорим о таких ключевых понятиях, как "Cohesion" и "Coupling".
Канал с анонсами https:…
Канал с анонсами https:…
👍2
Forwarded from Книжный куб (Alexander Polomodov)
An Introduction to Residuality Theory - Barry O'Reilly - NDC Oslo 2023 (Рубрика #Architecture)
Интересное выступление про residuality theory от Barry O'Reilly, автора теории. Автор делает подход к созданию теории, что поможет инженерам прокачиваться в архитектуру не просто набивая опыт, а используя достижения complexity theory, но без погружения во всю ее сложность. Для этого автор начинает с определения упорядоченных и неупорядоченных систем, а дальше он показывает как стрессоры (неизвестные факторы) могут негативно влиять на архитектуру. С учетом вариативности окружающего мира проанализировать все состояния системы и влияние стрессоров на систему в этом состоянии не представляется возможным. Поэтому автор предлагает рассматривать систему не целиком, а изучать то, что остается от системы, если случается пи... (стрессор X). Эти остатки определяют будущее системы и могут быть использованы для управления архитектурой программного обеспечения. Для моделирования стрессоров нам поможет метод Монте-Карло с его рандомизацией, которую мы можем применить к возможным стрессорам.
Дальше автор вводит рассказывает про аттракторы как устойчивые состояния, в которые скатывается система. Он приходит к ним через NK модель Кауффмана. У нас есть система с N элементами, принимающими значение 0 или 1, параметром K характеризующим связность (например, максимум связей одного элемента). Суть в том, чтобы показать, что при росте N и K у нас в системе увеличивается количество аттракторов. Заодно там появляется вероятностная характеристика P, которая характеризует bias связей между элементами. Финалом размышлений становится вывод некоторой выпуклой кривой критичности, которая вырисовывается в пространстве N и K, где мы играем с количеством элементов и связей между ними (еще один способ определить количество сервисов и связей между ними).
В общем, для каждого стрессора, который ломает нашу начальную наивную архитектуру, мы придумывает доработку, которая позволяет архитектуре системы пережить наступление этого стрессора. Пробежавшись по всем стрессорам, мы получаем крутую residual architecture для нашей системы.
Дальше автор приводит крутые примеры из дизайна системы для управления зарядными станциями для электромобилей. Ребята учли corner cases, которые бывают с зарядкой электромобилей и это помогло потом упростить решение проблем с людьми, что оставляют заряжать машины на целый день, а также с ребятами, что занимались саботажем. А вообще история прикольная и рекомендую посмотреть ее в оригинале.
Ну и в финале автор рассказывает про составление матриц для описания связей между компонентами системы и факторами стресса. Эти матрицы помогают выявить нефункциональные требования и уязвимости в системе. В этой матрице у нас в строках приведены стрессоры, а в колонках - компоненты системы. В итоге, мы анализируем для каждого стрессора влияет ли он на компонент. Если несколько компонентов подвержены одному стрессору, то вероятно у них есть неявная связь (implicit coupling), с которой хорошо бы разобраться.
В конце автор приводит способ померить крутость нашей residual architecture по сравнению с ее наивной версией. Схема выглядит так, что нам надо подсчитать для каждого стрессора
- Переживает ли наша наивная архитектура его наступление
- Переживает ли его наступление residual architecture
- Из значения успехов для residual architecture вычесть количество успехов для наивной архитектуры, а потом отнормировать на общее количество стрессоров
- Полученное число показывает насколько мы хорошо как архитекторы прокачали нашу начальную архитектуру:)
В общем, все звучит достаточно логично и напоминает мне подход генеративно-состязательных сетей, но только к архитектуре. Дальше я планирую прочитать whitepaper "Residuality Theory, random simulation, and attractor networks" от автора доклада и рассказать про него:)
#DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes
Интересное выступление про residuality theory от Barry O'Reilly, автора теории. Автор делает подход к созданию теории, что поможет инженерам прокачиваться в архитектуру не просто набивая опыт, а используя достижения complexity theory, но без погружения во всю ее сложность. Для этого автор начинает с определения упорядоченных и неупорядоченных систем, а дальше он показывает как стрессоры (неизвестные факторы) могут негативно влиять на архитектуру. С учетом вариативности окружающего мира проанализировать все состояния системы и влияние стрессоров на систему в этом состоянии не представляется возможным. Поэтому автор предлагает рассматривать систему не целиком, а изучать то, что остается от системы, если случается пи... (стрессор X). Эти остатки определяют будущее системы и могут быть использованы для управления архитектурой программного обеспечения. Для моделирования стрессоров нам поможет метод Монте-Карло с его рандомизацией, которую мы можем применить к возможным стрессорам.
Дальше автор вводит рассказывает про аттракторы как устойчивые состояния, в которые скатывается система. Он приходит к ним через NK модель Кауффмана. У нас есть система с N элементами, принимающими значение 0 или 1, параметром K характеризующим связность (например, максимум связей одного элемента). Суть в том, чтобы показать, что при росте N и K у нас в системе увеличивается количество аттракторов. Заодно там появляется вероятностная характеристика P, которая характеризует bias связей между элементами. Финалом размышлений становится вывод некоторой выпуклой кривой критичности, которая вырисовывается в пространстве N и K, где мы играем с количеством элементов и связей между ними (еще один способ определить количество сервисов и связей между ними).
В общем, для каждого стрессора, который ломает нашу начальную наивную архитектуру, мы придумывает доработку, которая позволяет архитектуре системы пережить наступление этого стрессора. Пробежавшись по всем стрессорам, мы получаем крутую residual architecture для нашей системы.
Дальше автор приводит крутые примеры из дизайна системы для управления зарядными станциями для электромобилей. Ребята учли corner cases, которые бывают с зарядкой электромобилей и это помогло потом упростить решение проблем с людьми, что оставляют заряжать машины на целый день, а также с ребятами, что занимались саботажем. А вообще история прикольная и рекомендую посмотреть ее в оригинале.
Ну и в финале автор рассказывает про составление матриц для описания связей между компонентами системы и факторами стресса. Эти матрицы помогают выявить нефункциональные требования и уязвимости в системе. В этой матрице у нас в строках приведены стрессоры, а в колонках - компоненты системы. В итоге, мы анализируем для каждого стрессора влияет ли он на компонент. Если несколько компонентов подвержены одному стрессору, то вероятно у них есть неявная связь (implicit coupling), с которой хорошо бы разобраться.
В конце автор приводит способ померить крутость нашей residual architecture по сравнению с ее наивной версией. Схема выглядит так, что нам надо подсчитать для каждого стрессора
- Переживает ли наша наивная архитектура его наступление
- Переживает ли его наступление residual architecture
- Из значения успехов для residual architecture вычесть количество успехов для наивной архитектуры, а потом отнормировать на общее количество стрессоров
- Полученное число показывает насколько мы хорошо как архитекторы прокачали нашу начальную архитектуру:)
В общем, все звучит достаточно логично и напоминает мне подход генеративно-состязательных сетей, но только к архитектуре. Дальше я планирую прочитать whitepaper "Residuality Theory, random simulation, and attractor networks" от автора доклада и рассказать про него:)
#DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes
YouTube
An Introduction to Residuality Theory - Barry O'Reilly - NDC Oslo 2023
Residuality theory is a revolutionary new theory of software design that aims to make it easier to design software systems for complex business environments. Residuality theory models software systems as interconnected residues - an alternative to component…
👍3
Мен одного бесит, когда чистую архитектуру приравнивают к DDD и наоборот?
Anonymous Poll
45%
Дааааа 👿👺😈
18%
Нет
36%
🤡
Написал свой первый пост в телетайп, потому что превысил ограничение на количество символов
https://teletype.in/@vdprud/book-building-event-driven-microservices
https://teletype.in/@vdprud/book-building-event-driven-microservices
Teletype
«Создание событийно-управляемых микросервисов» Адама Беллемара
tldr: введение в событийно-ориентированную архитектуру (EDA) на основе микросервисов
❤3