Стейт-машина описывается читаемым текстом в Markdown формате.
Поэтому создать её может и человек и агент. Можно и совместно — попросить агента сгенерировать workflow, а потом его отревьювить.
Например, базу для workflow по ссылке выше я сделал руками, потом в несколько итераций доработал агентом — так быстрее.
В целом, предполагаемую стратегию использования Donna я вижу так:
Постоянные workflow делаются человеком с помощью агента.
Workflow для выполнения разовой задачи генерируются агентом (при выполнении workflow из предыдущего пункта, например) и выполняются без участия человека. Полная автоматизация может потребовать некоторой работы (создать спеки по проекту, создать правильные meta-workflow, etc.).
Изменения в саму утилиту, например, мой агент сейчас вносит в основном самостоятельно: создаёт workflow и исполняет его.
Хм, похоже я перестарался с редактированием поста и удалил пару релевантных абзацев.
Упрошённый пример.
Допустим мы сделали правки в своём коде и хотим, чтобы агент поправил наши мелкие косяки: синхронизировал типы, починил тесты и так далее.
Для этого ему надо итерационно запускать тесты, линтеры, форматтеры и так далее (и править проблемы), пока все ошибки не будут исправлены.
Если таких операций много, то агент начнёт их пропускать, запускать в неправильном порядке, и так далее. В итоге он отрепортит нам, что всё готово, а на самом деле что-нибудь будет забыто (например, последняя правка типов сломает тесты или нарушит форматирование).
Можно сделать один скрипт, который прогоняет все утилиты и сказать агенту запускать его по кругу. Это в целом работает, на мой взгляд, довольно неопрятно и создаёт трудности. Например, для такого скрипта нуно будет рядом держать большую спеку о том как реагировать на разные типы ошибок.
А можно сделать стейт машину, которая управляет последовательностью запуска утилит (как в посте, но больше шагов) и знает как реагировать на каждую ошибку.
Например:
агент запускает workflow, вызывая что-то в духе donna sessions run project:work:polish
Donna начинает интерпретировать FSM
Первой оперцией идёт запуск, допустим, mypy и Donna это и делает (нет взаимодействия с агентом).
Если mypy отработал без ошибок, то FSM переходит к шагу с запуском следующей утилиты.
Если mypy отработал с ошибками, то FSM переходит к шагу, который отвечает за обработку ошибок mypy. На этом шаге Donna отображает сообщение агенту с описанием конкретной ошибки и правилами её исправления (специфичными для mypy).
Агент читает это сообщение и выполняет инструкцию, ему не надо подгружать отдельные спеки или помнить большую инструкцию как фиксить ошибки для любых линтеров.
Когда агент решает, что исправил ошибку, он говорит Donna продолжать, и та переключает FSM на следующий шаг (например, на форматирование кода).
И вот как выглядит шаблон сообщения для агента от конкретного шага FSM (исправление ошибок от flake8):
{{ donna.lib.task_variable("flake8_output") }}
1. Fix the flake8 issues based on the output above.
2. Ensure your changes are saved.
3. {{ donna.lib.goto("run_autoflake_script") }}
Instructions on fixing special cases:
- E800 Found commented out code — remove the commented out code.
- CCR001 Cognitive complexity is too high — ignore by adding # noqa: CCR001 at the end of the line.
- F821 undefined name when there are missing imports — add the necessary import statements at the top of the file.
- F821 undefined name in all other cases — ask the developer to fix it manually.
То есть вместо больших инструкций агент всегда имеет короткие и чёткие шагии (в данном случае 3 шага).
рядом с тэгами можно информационно обозначить какой вес он имеет.
Интересная идея, записал. С ней может быть много нюансов (ограничивает ширину для названия тега, делает интерфейс насыщеннее), но попробую покрутить в голове.
На всякий случай: вы можете кликнуть по рейтингу конкретной статьи и появится окно с информацией о влиянии тегов на рейтинг этой конкретной статьи.
Судя по тому, что я вижу, всё работает стабильно, должно открываться.
Проверьте соединение, расширения браузера, etc.
Если интерфейс виден, а новости «не грузятся», то надо подождать — информация о научных статьях за 3 дня сейчас занимает где-то 0.5 мегабайта. На медленных соединениях может грузиться какое-то время.
Конфигурировать работу «процессоров тегов» тоже можно, пример конфига.
С тегами, действительно, ещё много работы предстоит. Их надо нормализировать, унифицировать, убирать дубликаты и всё в этом духе — дело наживное, со временем ситуация улучшится.
Попробую, если будут более существеные проблемы. Пока что меня psycopg устраивает — описанное в посте частный случай, можно сказать первый раз за карьеру с таким нюансом столкнулся.
2023 — это набор школы, сам план датирован где-то маем 2024.
Увеличенные комиссии Steam для РФ, не учитываются, т.к. я не в РФ и компания, если будет, будет тоже не в РФ.
И слишком оптимистичной выглядит та часть расчета, где спустя 40 месяцев после старта альфы выходит платный DLC №4
Разница в профите от разных DLC определяется, в том числе, разной ценой за них. Для четвёртого записана цена в 10$, для третьего в 5$. Учитывая комиссии и прочее, разница в профите будет заметная.
Плюс, я уменьшаю долю покупающих DLC игроков со временем. На старте она задана довольно оптимистично (в 30% для первого DLC), но в рамках возможного, на это указано в посте.
С одной стороны да, план оптимистичный на этом временном отрезке (4 года), с дргой стороны очевидно, что на 4 года планировать что-то реалистичное в любом случае не получится — слишком много неопределённости, поэтому выпуск DLC расписан как то, к чему мы стремимся.
Естественно, можно облажаться, выпустить ерунду и даже первое DLC не продать, но какой смысл будет такой план инвесторам показывать, если изначальная стратегия на долгосрочном выпуске DLC?
Как раз недавно сделал пост про промты своих GPTешек (Open AI позволяет выносить специализированные промпты в отдельные чаты) с пояснениями как они устроены.
За счёт плоской структуры компонентов открываются широкие возможности оптимизации работы с памятью. Например в python можно использовать слоты для объектов
Справедливости ради слоты можно и без ECS использовать.
Имхо, применение ECS в Python скорее вызовет замедление логики, чем ускорение. Из-за порождения кучи лишних объектов: больше аллокаций/деаллокаций, больше скачков между кусками памяти, больше нагрузки на сборщик мусора.
Можно попытаться это обойти с помощью numpy и подобных штук, но профит спорный.
Это как-минимум надо добыть 80 видюх, собрать из них кластер, подвести к нему электричество (хватит стандартных 220?), софт поставить и обновлять. Не знаю какая стабильность у всей этой системы, но, возможно, периодически приходится её подымать, в логах копаться, etc.
Может, конечно, это 2 месяца работы, а потом оно само настроенное летает - всякое бывает :-)
Должна прикручиваться настолько же легко, как любая другая CLI утилита.
Стейт-машина описывается читаемым текстом в Markdown формате.
Поэтому создать её может и человек и агент. Можно и совместно — попросить агента сгенерировать workflow, а потом его отревьювить.
Например, базу для workflow по ссылке выше я сделал руками, потом в несколько итераций доработал агентом — так быстрее.
В целом, предполагаемую стратегию использования Donna я вижу так:
Постоянные workflow делаются человеком с помощью агента.
Workflow для выполнения разовой задачи генерируются агентом (при выполнении workflow из предыдущего пункта, например) и выполняются без участия человека. Полная автоматизация может потребовать некоторой работы (создать спеки по проекту, создать правильные meta-workflow, etc.).
Изменения в саму утилиту, например, мой агент сейчас вносит в основном самостоятельно: создаёт workflow и исполняет его.
Хм, похоже я перестарался с редактированием поста и удалил пару релевантных абзацев.
Упрошённый пример.
Допустим мы сделали правки в своём коде и хотим, чтобы агент поправил наши мелкие косяки: синхронизировал типы, починил тесты и так далее.
Для этого ему надо итерационно запускать тесты, линтеры, форматтеры и так далее (и править проблемы), пока все ошибки не будут исправлены.
Если таких операций много, то агент начнёт их пропускать, запускать в неправильном порядке, и так далее. В итоге он отрепортит нам, что всё готово, а на самом деле что-нибудь будет забыто (например, последняя правка типов сломает тесты или нарушит форматирование).
Можно сделать один скрипт, который прогоняет все утилиты и сказать агенту запускать его по кругу. Это в целом работает, на мой взгляд, довольно неопрятно и создаёт трудности. Например, для такого скрипта нуно будет рядом держать большую спеку о том как реагировать на разные типы ошибок.
А можно сделать стейт машину, которая управляет последовательностью запуска утилит (как в посте, но больше шагов) и знает как реагировать на каждую ошибку.
Например:
агент запускает workflow, вызывая что-то в духе
donna sessions run project:work:polishDonna начинает интерпретировать FSM
Первой оперцией идёт запуск, допустим, mypy и Donna это и делает (нет взаимодействия с агентом).
Если mypy отработал без ошибок, то FSM переходит к шагу с запуском следующей утилиты.
Если mypy отработал с ошибками, то FSM переходит к шагу, который отвечает за обработку ошибок mypy. На этом шаге Donna отображает сообщение агенту с описанием конкретной ошибки и правилами её исправления (специфичными для mypy).
Агент читает это сообщение и выполняет инструкцию, ему не надо подгружать отдельные спеки или помнить большую инструкцию как фиксить ошибки для любых линтеров.
Когда агент решает, что исправил ошибку, он говорит Donna продолжать, и та переключает FSM на следующий шаг (например, на форматирование кода).
Вот пример большого workflow для полировки кода: https://github.com/Tiendil/donna/blob/main/.donna/project/work/polish.md
И вот как выглядит шаблон сообщения для агента от конкретного шага FSM (исправление ошибок от flake8):
То есть вместо больших инструкций агент всегда имеет короткие и чёткие шагии (в данном случае 3 шага).
Отлично!
Всегда :-)
Локализация интерфейса и тегов появится со временем, но прямо сейчас не планируется — станачло надо всё устаканить.
Есть roadmap: https://github.com/users/Tiendil/projects/1
Интересная идея, записал. С ней может быть много нюансов (ограничивает ширину для названия тега, делает интерфейс насыщеннее), но попробую покрутить в голове.
На всякий случай: вы можете кликнуть по рейтингу конкретной статьи и появится окно с информацией о влиянии тегов на рейтинг этой конкретной статьи.
Добрый день, спасибо за сообщение.
> сначала что на почту письмо отправило,
На текущий момент так и должно быть.
>а потом что пошло чтото не так.
А так быть не должно.
Можете сделать скриншот с проблемой и прикрепить логи из панели разработчика в браузере?
Может быть проблема в установленных расширениях?
P.S. На моей машине всё работает и по логам видно, что регистрацию пользователей проходят.
Спасибо, потестирую на проблемных соединениях.
Судя по тому, что я вижу, всё работает стабильно, должно открываться.
Проверьте соединение, расширения браузера, etc.
Если интерфейс виден, а новости «не грузятся», то надо подождать — информация о научных статьях за 3 дня сейчас занимает где-то 0.5 мегабайта. На медленных соединениях может грузиться какое-то время.
Локальные LLM использовать можно, главное чтобы HTTP API было совместимо с OpenAI. На GitHub есть проекты прокси и разного рода адаптеров для этого.
Подменяете точку входа в API и всё должно заработать.
Конфигурировать работу «процессоров тегов» тоже можно, пример конфига.
С тегами, действительно, ещё много работы предстоит. Их надо нормализировать, унифицировать, убирать дубликаты и всё в этом духе — дело наживное, со временем ситуация улучшится.
Будет лучше, но не на столько как с конкатенацией. Детали можно в посте по ссылке посмотреть.
Попробую, если будут более существеные проблемы. Пока что меня psycopg устраивает — описанное в посте частный случай, можно сказать первый раз за карьеру с таким нюансом столкнулся.
2023 — это набор школы, сам план датирован где-то маем 2024.
Увеличенные комиссии Steam для РФ, не учитываются, т.к. я не в РФ и компания, если будет, будет тоже не в РФ.
Разница в профите от разных DLC определяется, в том числе, разной ценой за них. Для четвёртого записана цена в 10$, для третьего в 5$. Учитывая комиссии и прочее, разница в профите будет заметная.
Плюс, я уменьшаю долю покупающих DLC игроков со временем. На старте она задана довольно оптимистично (в 30% для первого DLC), но в рамках возможного, на это указано в посте.
С одной стороны да, план оптимистичный на этом временном отрезке (4 года), с дргой стороны очевидно, что на 4 года планировать что-то реалистичное в любом случае не получится — слишком много неопределённости, поэтому выпуск DLC расписан как то, к чему мы стремимся.
Естественно, можно облажаться, выпустить ерунду и даже первое DLC не продать, но какой смысл будет такой план инвесторам показывать, если изначальная стратегия на долгосрочном выпуске DLC?
P.S. Спасибо, что посмотрели расчёты :-)
Сами OpenAI в анонсе
В том же анонсе есть график сравнения нескольких сетей, там местами GPT-4o-mini довольно близка к GPT-4o
Как раз недавно сделал пост про промты своих GPTешек (Open AI позволяет выносить специализированные промпты в отдельные чаты) с пояснениями как они устроены.
Если интересует практический пример, то вот: https://tiendil.org/ru/posts/my-gpts
В продолжении темы поделюсь парой своих постов.
Как у нас в команде практиковалось написание RFC: https://tiendil.org/ru/posts/two-years-writing-rfc-statistics с графиками, статистикой и комментариями.
Про мышление письмом в целом: https://tiendil.org/ru/posts/thinking-through-writing
Не от хорошей жизни же. Хорошо, что мы не в средневековье уже.
А в чём конкретный профит для конторы от первых мест рейтинге? А то усилий как-то много на накрутку надо.
Слабо верится, что с этого дикие тыщи экономят на найме.
Справедливости ради слоты можно и без ECS использовать.
Имхо, применение ECS в Python скорее вызовет замедление логики, чем ускорение. Из-за порождения кучи лишних объектов: больше аллокаций/деаллокаций, больше скачков между кусками памяти, больше нагрузки на сборщик мусора.
Можно попытаться это обойти с помощью
numpyи подобных штук, но профит спорный.Вопрос по оценке качества краудсорсингом: не влияет ли на оценку раса, пол, культура, возраст и прочие свойства людей?
Выглядит так, что метрики от краудсорсинга могут быть сильно искажены. Что-то в духе проблемы WEIRD.
Выглядит как памятка по общению с людьми в целом :-)
Прям не просит?
Это как-минимум надо добыть 80 видюх, собрать из них кластер, подвести к нему электричество (хватит стандартных 220?), софт поставить и обновлять. Не знаю какая стабильность у всей этой системы, но, возможно, периодически приходится её подымать, в логах копаться, etc.
Может, конечно, это 2 месяца работы, а потом оно само настроенное летает - всякое бывает :-)