Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: Implement new AtomizedModel #1325

Open
DRMPN opened this issue Aug 26, 2024 · 3 comments
Open

refactor: Implement new AtomizedModel #1325

DRMPN opened this issue Aug 26, 2024 · 3 comments
Labels
enhancement New feature or request refactoring

Comments

@DRMPN
Copy link
Collaborator

DRMPN commented Aug 26, 2024

понятно, нужно будет в таком случае создать дополнительно 2 issue:

  • в продолжение Atomized model operation #1227, чтобы наконец убрать AtomizedModel
  • в поддержку новой Atomized для GOLEM

Originally posted by @Lopa10ko in #1324 (comment)

@DRMPN DRMPN added enhancement New feature or request refactoring in progress task in progress and removed in progress task in progress labels Aug 26, 2024
@DRMPN
Copy link
Collaborator Author

DRMPN commented Aug 27, 2024

Inside _transform_to_opt_node function context of AtomizedModel is lost.

The idea to solve this problem is to change:
'name': operation_name, -> 'name': node.content['name'],
However, it's not a complete solution to the problem.

Next, Golem Optimizer doesn't know anything about AtomizedModel, so either implement it there or use the params key in the context dictionary to store the ?entire pipeline? with the help of _adapt and _restore functions.

image

@kasyanovse
Copy link
Collaborator

kasyanovse commented Oct 13, 2024

Может быть пригодится. Пишу по памяти.

Реализация AtomizedModel как узла-монолита - не единственный возможный вариант. Ранее, я с @Lopa10ko, изучал возможность вовлечения узлов-монолитов в процесс композиции и тюнинга (возможно в #1227, #1232). Точно не помню результаты той работы, но выводы я получил примерно следующие:

  1. Текущая реализация узлов-монолитов AtomizedModel имеет место быть, если их оставить как есть. Не стоить залезать внутрь узла, пусть он живет по своим правилам. Это хороший способ внедрить готовую модель, которую не хочется менять, внутрь пайплайна.
  2. Подмешивание пайплайнов друг в друга удобнее и проще реализовать через систему тегов (репозитории моделей). То есть, не запихивать пайплайны в узлы, а мержить пайплайны друг с другом, управляя работой с пайплайнами через теги. Для этого я начал рефакторить репозитории в Operation repo refactor #1253. ИМХО, работа завершена на 80%+. Через Atomized Model я планировал реализовать много крутых фич, так что хорошо написанные репозитории моделей с возможностью гибкой настройки под разные задачи/типы моделей, позволят много чего потом добавить в пайплайны, что в текущей реализации надо будет делать через говнокод.

CC: @nicl-nno

@nicl-nno
Copy link
Collaborator

@kasyanovse спасибо!

С пунктом 1 согласен, над пунктом 2 подумает как это лучше провернуть.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request refactoring
Projects
Status: Todo
Development

No branches or pull requests

3 participants