-
Notifications
You must be signed in to change notification settings - Fork 87
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
Aggregated operations #1217
Comments
Концептуально звучит интересно, но какие преимущества видишь у такого подхода по сравнению с текущим подходом? Я вижу проблему в том, что тут получается, что в одной группе есть сильные и слабые модели (катбуст >> бустинга из склерна, например). Сейчас по-идее мы стремимся использовать просто одну сота модель из семейства, чтобы дополнительно не усложнять пространство поиска. К тому же мне сейчас кажется, что затраты на реализацию подхода >> профита |
Сокращение пространства поиска.
Как будто бы это не оптимально. Логичнее было бы на композиции использовать самую быструю модель, а на тюнинге уже попробовать подобрать модель поточнее.
С помощью костылей это можно сделать быстро) Но вообще это просто как возможный вариант на случай, если операции будут хоть немного рефакториться. |
Если по итогам испытаний "костыльной" реализации будет видно что такой подход (выбирать не конкретные модели а их тип) дает преимущество - то можно будет и реализовать полноценно. Сходу имею сомнения - ожидал бы что результат будет очень чувствителен к конкретному типу модели. Как вариант, можно только первые N поколений так делать. |
Тут согласен - если есть понимание того, как сделать быстрый proof-of-concept и проверить подход на pytsbe или на своем бенчмарке - то можно попробовать |
Moved to #1339. |
There are some groups of models:
Each group can be implemented as a single operation during the composition stage. At the tuning stage, any model from the group can be selected.
The text was updated successfully, but these errors were encountered: