И станет ясно, что seq2seq модели в кодинг не могут по определению :)
Потому что это (seq2seq, Transformer, etc) - отображение одного множества на другом (и используются seq2seq для перевода).
А от всего остального появляется декартово произведение (Напиши Зеленый модуль в стиле Барокко на C++ - цвета X стиль X язык). И бесполезные модели в триллионы параметров.
Программирование - разработка Алгоритма.
Это делают SMT solver-ы, A* и т.д.
P.S. (ответы на все остальные вопросы)
Я обосновал Multistep (thinking) за год-два до OpenAI.
(В отличие от "Экспертов" c habr и сбербанк, которые не смогли в предметную область и тем более в магию множеств и декартова произведения)
А вы сами читали? Транзакционность в Orleans реализована за счет сохранения состояния в транзакционном хранилище, то есть в БД.
Продолжайте читать. Если вам советуют почитать (и даже ссылки кидают) - надо говорить Спасибо за ценную информацию.
Не надо делать какие-то невнятные заявления о транзакциях БД и прочем, в надежде что Вам сейчас все разъяснят.
Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)
Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)
The Orleans runtime guarantees that a grain instance will never execute on more than one thread at a time. This means that within the context of a single grain, you do not need to worry about race conditions or shared state being accessed concurrently by multiple threads.
Вы через WebApi дергаете BookItems
В Orleans.
Там (В методе BookItems у объекта ShopItem) в транзакции
уже проверяется словарь с записями по количеству на складах, вычитается у первого склада, на котором товар есть, пишется результат бронирования (в шину, оттуда BatchInsert).
Все, вы не можете записать результат бронирования пока не провалидируете количество на складах.
Остается только добавить возвращение результата (тоже через шину(!))
Почти akka.net
Есть явные причины так не делать под высокой нагрузкой.
Orleans offers high "actor speed" through a framework that keeps grain (actor) state in memory, providing low-latency access for real-time applications and enabling massive horizontal scalability by distributing grains across many silos (servers) and managing their lifecycles automatically. This in-memory state management is significantly faster than database roundtrips, allowing the system to achieve high throughput and sub-millisecond responses for concurrent tasks
У вас сколько типов товаров на распродаже? Меньше миллиарда (Чтобы на одном сервере поместились все акторы)?
Отлично.
10 кRPS.
Могу даже бесплатно подсказать:
Актор у вас
— item_id — уникальный идентификатор товара;
— warehouse_id — склад, где товар лежит;
— stock — общее количество (сколько товара на складе прям сейчас);
— reserved — сколько уже зарезервировано.
Ну а записи о резервировании опять в шину (персистентно, горизонтально масштабируемо), а оттуда - в БД (батчами).
Поздравляю, вы построили систему бронирования для миллиарда типов товаров, которая выдерживает
10 КRPS.
Саммари:
Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)
Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)
При этом не понимаете, что писать в <TargetFramework>. Поменяв net7.0 на netcoreapp2.0, вы сделали хуже, потому что если у .NET 7 поддержка закончилась в мае 2024, у .NET Core 2.0 - в октябре 2018.
И? Моя задача сделать либу, которая поддерживается наибольшим числом проектов. Core2.0 - самое то.
Да, нужно разбивать на несколько пакетов. Unity отдельно, Microsoft DI отдельно. Нет, разбираться в 3+ пакетах никому не придётся. Кому нужен RegistrationByAttributes для Microsoft DI, те по-прежнему поставят один пакет.
Зачем? Пакеты по 100 строк кода? При этом без тяжелых зависимостей (Только Abstractions)?
Во-вторых, лично я с возрастом начал ценить простоту. Я выберу 200 строк скучного, повторяющегося, но понятного как пять копеек кода, нежели магический чёрный ящик на 20 строк.
400-800-1000 строк скучного, повторяющегося кода, который всегда вызывает конфликты при merge :)
Вот это да (Сарказм).
Спасибо, что прикручиваете NLU к SMT.
Очередной Руководитель Департамента решил
пошутитьпоправить используя свои превосходные знания.Однако, программирование - поиск в пространстве функций.
А трансформер(GPT/Bert/etc) - отображение одного множества на другом (c CoT или без. Кот кстати даже не выведен математически :) ).
Это происходит от мнения, что Сбер или Яндекс действительно занимаются R&D, а не перепечаткой публикаций ученых.
R&D, только ЗП как у индусов. И уровень...
Да нет, я написал именно то, что имел ввиду.
Советую почитать еще раз
(про seq2seq, T9, LSTM, Tansformer и прочее)
https://ebetica.github.io/pytorch-Deep-Learning/en/week06/06-3
И станет ясно, что seq2seq модели в кодинг не могут по определению :)
Потому что это (seq2seq, Transformer, etc) - отображение одного множества на другом (и используются seq2seq для перевода).
А от всего остального появляется декартово произведение (Напиши Зеленый модуль в стиле Барокко на C++ - цвета X стиль X язык). И бесполезные модели в триллионы параметров.
Программирование - разработка Алгоритма.
Это делают SMT solver-ы, A* и т.д.
P.S. (ответы на все остальные вопросы)
Я обосновал Multistep (thinking) за год-два до OpenAI.
(В отличие от "Экспертов" c habr и сбербанк, которые не смогли в предметную область и тем более в магию множеств и декартова произведения)
https://medium.com/@PushkarevValeriyAndreevich2/how-to-write-on-verilog-with-chatgpt-or-do-anything-else-796a63c17f9b
К сожалению, сбер не опережает, а отстает даже от OpenAI :).
Когда станете прибыльными и сможете платить хотя-бы 8-16к$ на удаленке (типичная ЗП PhD R&D) - пиши, не стесняйся.
Про нейросети и статистические модели думаю говорить не будем (интересно, почему?)
https://9gag.com/gag/aZZVK3n
И, да, Сбербанк не разбирается в трендах ИИ, Яндекс тоже (денег нет), а вот 9 хомяков с Habr - разбираются xD
https://coub.com/view/39aatk
Бред какой пишите.
T-9 (transformer) не кодит?
Кодят поди DreamCoder-ы или SMT Solver-ы?
Есть вообще мнение, что это LowCost Cosplay на CAS (там уже биомаркеры-пептиды и окно в 10-20 лет)
Ну или даже на печально известное Delphi-2M
(да плевать что нейросети очень плохи в Explanation)
https://www.nature.com/articles/s41586-025-09529-3
Очень, учитывая что это почти DreamCoder (Darpa).
Т.е. просто спонсируем грант MiT, через 10 лет достаем (у нас тут в Alphabet почти OpenSource)
Продолжайте читать. Если вам советуют почитать (и даже ссылки кидают) - надо говорить Спасибо за ценную информацию.
Не надо делать какие-то невнятные заявления о транзакциях БД и прочем, в надежде что Вам сейчас все разъяснят.
Бесплатно - нет
Orleans так-то ACID.
Ну и весь код с Orleans - Положить запросы в шину,
При обработке:
1) дергать Orleans (bookTemporary(int count, int itemId), получаем guid)
2) отсылаем в шину операции на бронирование заказов (там BatchInsert)
3) отсылаем в шину операцию bookFinalize(подтверждаем бронирование)
Все, 100+ RPS.
За счет outboxConsistency точно не будет повисших бронирований.
Даже если шина вдруг откажет (ага), остатки будут возвращены на склад
Вы через WebApi дергаете BookItems
В Orleans.
Там (В методе BookItems у объекта ShopItem) в транзакции
уже проверяется словарь с записями по количеству на складах, вычитается у первого склада, на котором товар есть, пишется результат бронирования (в шину, оттуда BatchInsert).
Все, вы не можете записать результат бронирования пока не провалидируете количество на складах.
https://learn.microsoft.com/ru-ru/dotnet/orleans/grains/transactions
Как не решает?
Остается только добавить возвращение результата (тоже через шину(!))
Почти akka.net
Orleans offers high "actor speed" through a framework that keeps grain (actor) state in memory, providing low-latency access for real-time applications and enabling massive horizontal scalability by distributing grains across many silos (servers) and managing their lifecycles automatically. This in-memory state management is significantly faster than database roundtrips, allowing the system to achieve high throughput and sub-millisecond responses for concurrent tasks
У вас сколько типов товаров на распродаже? Меньше миллиарда (Чтобы на одном сервере поместились все акторы)?
Отлично.
10 кRPS.
Могу даже бесплатно подсказать:
Актор у вас
Ну а записи о резервировании опять в шину (персистентно, горизонтально масштабируемо), а оттуда - в БД (батчами).
Поздравляю, вы построили систему бронирования для миллиарда типов товаров, которая выдерживает
10 КRPS.
Саммари:
Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)
Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)
А вообще забавно.
10 RPS
Если просто взять, записать все в шину (шины могут быть развернуты на 100 инстансах, и писать гигабиты запросов) - можно тоже получить 10 кRPS.
Ну и как-то сложно.
Вот генерация веб-апи, которое пишет все в шину и разбирает по батчам (для IOT).
https://habr.com/ru/articles/906778
Orleans.
Богатые доменные модели в оперативке (и дампятся в хранилище автоматом).
Хоть 1M RPS (упретесь в CPU\сеть) :)
Даже с транзакциями(!).
Но есть минусы.
Ну, расскажите нам, что у вас за git
Да вы что, добавление 2-х разных строк в одно и то же место в файле - 100% конфликт при мерже.
Вам написали, что вы - идиот?
Ссылки привели?
Что Вас не устраивает? )
(del)
Вы откровенно херню городите, Вам даже ссылки приводят.
Вам уже написали:
1) вы читали меньше меня
2) у вас нет ни интерпретации ни оптимизации персептрона (А как публикация называется? А какие понятные причины? :) )
(и интерпретировано все, и оптимизировано, и это уже сделано с позиции LP)
3) почему те, кто понимает нейросети и перцептроны лучше, чем средние дурачки из Google (или CAS), не пишут вам статьи об этом. Да еще и бесплатно )
Удивительно, но у меня есть куда более перспективные занятия (а хабр с точки зрения науки - трэш :) ).
Вы пропустили 3-4 публикации:
1) Перцептрон, знаки в S/A слое и гиперкубы логических функций
2) Перцептрон, нейросети и ошибки из-за ненормированного расстояния до гиперплоскостей
3) Перцептрон как линейное ограничение
И? Моя задача сделать либу, которая поддерживается наибольшим числом проектов. Core2.0 - самое то.
Зачем? Пакеты по 100 строк кода? При этом без тяжелых зависимостей (Только Abstractions)?
400-800-1000 строк скучного, повторяющегося кода, который всегда вызывает конфликты при merge :)
Тут согласен.
Это который превращает boilerplate регистраций в еще менее поддерживаемый? И требует перерегистраций? Где истина-то?