да нет, просто нейросети экспоненциальны по сложности
то есть для текущих флагманов нужны целые ЦОДы когда локальные модели можно запустить на "домашнем ПК" и получим те самые флагманы годичной с гаком давности
даже если начнут закручивать с обоих сторон (и провайдеры ИИ в том числе) то люди просто перейдут на дешёвые аналоги. Для SaaaS в текущих ограничениях уже хватит с избытком локальной модели. просто потратится неделька на подготовку что бы обучить нейросеть работать с продуктом и убедится что она защищена как снаружи там и изнутри не делает ошибок (то есть пограмный кадавр написанный нейросетью где та самая нейросеть лишь один из вызываемых методов)
другое дело что это открывает целый новый сегмент атак, но в остальном будет все отлично работать по типу "кинь мне последний инвойс от контрагента" или "сколько за пол года чистого прихода" то есть весь SaaaS-цирк схлопнется до двух пользователей максимум (общий агент и ответственный админ и последняя инстанция), а если жалко денег то и вовсе одного пользователя
и это я не поднимаю возможность создания прокладки, что было популярно и до ИИ, просто с нейросетью такое станут делать чаше. Я про возможность попросить проклацать ИИ весь функционал SaaaS-продукта, скопировать верстку и создать свой тонкий клиент с распределёнными ролями, что бы тонкий клиент работал с валидным SaaaS-сервером от лица одного пользователя, а мы при этом могли нормально работать в многопользовательском режиме со своей стороны
О, "супер". Теперь кроме наркомании с "продажей мест" для цифрового продукта скоро появится еще счетчик "потребляемого контента" что бы не дай боже не упустить прибыль когда в специально переусложненной системе будет ковыряться один сотрудник-агент
Единое что радует - с неросетями в разы упала планка для "своих костыльных решений" а потому чем сильнее будут закручивать гайки, тем больше людей будут уходить с продукта, а значит петля замыкается и продукт умирает. И останутся только те кто не страдают фигней и оплата им действительно стоит, а не обычная деньговыжималка.
заводские штрихкоды то мертвая затея, анализировал, у меня реально большая аптечка это проблема которую я давно хочу решить
самое простое что я придумал это взять магазинный настренный терминал с камерой и екраноми перешить под себя. новое просто крутишь под камерой со всех сторон, а уже фотки сторон уходят на сервер где в фоне распознаются гуглятся и сводятся в базу, что бы не просто дата, но и поиск по названиям и показаниям что бы знать что у тебя вообще есть, что закончилось и что есть например чисто от простуды
но с подходом выше тоже свои подводные шаг дальше - самому маркировать (печать наклеек) и раскладывать картотекой по сгенерированному названию, что бы искать можно было по индексу, но такое не для всех и я гарантирую что мои домашние нифига не будут складывать туда же где взяли, а без этого быстрый контроль расположения теряется а просто перебирать под сотню номнклатур, даже зная название и фото как выглядит коробка такое себе
медикаментами в таком разрезе скорее в тему была бы апка или умная камера
сам думал на эту тему, аптечка в целый шкаф и отслеживать все надо 100%. Но это все руками забивать((( Можно попробовать нейронку по фото заряжать но это или дорого или чертовски долго для распознания (разве что какая-то интеграция с агентами по подписке, но это только десктоп тогда)
а за готовку у меня как раз отдельный таймер похожй на тот что я кидал. енкодер на вращающийся корпус чертовски удобно
самое главное правило при работе с нейронками - брать ношу по себе
кроссревью вычесывают от 95% проблем (а если это веб то все 99% так как агенты могут пользоваться браузером) но потом нужно самому вычитывать что бы упрощать код от архитектурных излишеств и пере усложнений
в фоне запускать "танго" что бы агенты сами танцевали между собой я бы лично не рискнул, потому как нужно пробегаться по каждой итерации ревью ибо мелочи важны и с нейронками проблемы лучше предвосхищать чем потом пытаться решить уже архитектурную проблему
единый плюс как по мне это аналитика и возможность привязать "кухонные оповещения" на мультимедиа или вообще в телегу/пуш.
с медикаментами и тд такое себе - проще на телефоне быстро поставить единоразово, к тому же (из личного опыта) таймер не гарантирует прием, но сложный таймер отвлекает
для подобного (особо кухни) рекомендую юзать готовое. Вот например такое https://aliexpress.com/item/1005008352585162.html причем энкодер удобен для взаимодействия грязными руками например (можно предплечьем "прокрутить)
Устаревает не софт, а говнокод который работал на вере и молитвах, но какие либо обновления нарушают стабильную ауру и софт ломается.
99.9% проблем "устаревания" возникают по очень тупым причинам - не проверяют тип, не обрабатывают ошибку, не очищают память. Как много было проблем с гранью 32/64 причем в серьезных тулзах низкого уровня, которым проверять размерность входных данных не стоит ничего.
Один говнокод порождает другой говнокод. Вот круг и замкнулся. Особенно если баги становятся фичами которые активно используют и вот уже даже не сделать нормально ведь кривизна уже часть функционала.
Хватает вещей которые актуальны десятилетиями. У меня у самого есть исторические bash-скрипты которые я писал сам для простой работы с гит-хуками и версионностью парой команд. И они у меня уже около 11 лет почти не меняются. Вот только в этом году решил уйти наконец-то от баш-скриптов православных и написать гошную cli-утилиту что бы в рамках самого голанда все было кроссплатформенно через go run раз уж это сейчас мой основной язык.
А по поводу статьи - практически со всем согласен кроме "мимолетности". Если убрать за рамки обновления безопасности то большая часть ощущения мимолетности создана менеджерами и маркетологами, а не программистами. Софт живет не в ввакуме, а вращается вокруг пользователей и задач, и вот как тут классическая проблема бизнеса "на стабильном не заработаешь" ведь хорошо монетизируются только постоянные изменения. Вот и возникает ощущения мимолетности, потому что за пару лет ОС начнет работать вообще иначе и старый софт не понимает что ему вообще тут делать, хотя по факту изменения косметические и зачастую еще и кривые как будто специально ломающие совместимость.
мда, неронки лучшее и худшее что было рождено в этом столетии
По UID - есть целая сфера знаний в в алгоритмах которая затрагивает генерацию минимально-уникального указателя в рамках заданной системы. Если уж ушли в эту степь то почитайте что люди пишут по этой теме. В целом при правильно подобранном алгоритме генерации указателя в 16 байт хватит что бы промаркировать все что только душенька пожелает с гарантированной уникальностью асинхронно и офлайн. Обычно даже меньше берут (я про всякие сервисы генерации временных ссылок где уникальных указателей милионы и более в час)
UUID используют просто от лени и нежелании разбираться в теме. Вообще UUID это стандарт под узкую сферу вот только та самая лень разработчиков (оно же гарантировано уникальное, берем!) растянула UUID везде где только можно и нельзя, а ведь достаточно только почитать как формируется UUID что бы "отрезать лишнее" и получить ключ с нужной глубиной уникальности конкретно для вашей задачи, а не огромный и неповоротливый UUID
я уже не вспомню за язык (Ruby вроде) но там можно было очень просто в коде задавать и работать с числами с произвольной числовой разрядностью. Хочешь 128 а хочешь 3 или 4. Причем вся алгебра так же подтягивалась.
Так вот, я в свое время наигрался с разными системами счисления и в целом получается шляпа. - Троичная логика условий не натягивается на привычное да/нет потому как или нужна четкость (или да или нет) или же произвольность так же в жестко заданных рамках - Много слышал тогда про то что "+1 бит в разы ускорит расчеты" и попытался это проверить. В итоге операций стало не сказать что меньше. Заметно становится на операциях с большим основанием и тут приходим к тому что четное основание проще для мысленного оперирования (компьютеру пофиг сколько он там считает)
Итог игр был в том что если я хочу "удобное ветвление" то ограничение в какое-то число не имеет смыла, удобно просто произвольный массив битов, где каждый бит это конкретный да/нет. А за арифметику в итоге пришел к классической криптографии, где оперирование числами большим основанием удобнее и быстрее чем разбиения на граничные int32 что бы работать с большими числами
По вашей работе - достойно уважения объем и глубина. Единое что не увидел ссылки на гитхаб или аналог что бы самому потыкать. Следующим развитием было бы круто написать генератор которому даешь разрядность и он под него генерирует компилятор. Хочешь трехразрядное число, хочешь семиразрядное.
просто напоминаю что мир гораздо больше видимого вами пузыря и то что вы видели в одном из поселков (и скорее всего со стороны) не означает что везде так
Сначала просим собрать данные в глоссарий, что бы вернул детерминировано в том же json. Важно что бы в контекстное окно с запасом влазил разбор с обсуждениями. Эти данные наполняют базу.
Далее базу переводим машинно по контексту и ОБЯЗАТЕЛЬНО вычитываем все глазами.
И наконец заряжаем "чистовой перевод" подставляя валидные куски глоссария под чанки (сопоставление по первой операции, где мы не только заполнили сам глоссарий но и сохранили в каких чанках какие значения были найдены)
В своей задаче с художественной литературой я еще выделил отдельную группу в "часто встречаемые значения" которая выдавалась с обычным глоссарием по чанку что значительно улучшило перевод ведь часто в книгах хватает иносказательности. Но я разрабатывал это еще во времена когда gpt только 4 вышла, сейчас с 1М окнами можно собирать и отдавать в качестве точки опоры гораздо больше данных.
У чувака на BMW обычно есть человек, что этим всем занимается
Для таких людей важна стабильность и беспроблемность - ему не важно как оно там работает и тд. Он обращает внимание если есть проблемы и/или не работает когда внезапно понадобится.
начиная от неизвестных андроид-китайцев которыми пользуются бабки и заканчивая свяким пограничным когда старая версия прошивки у айфона и именно на этой версии есть баг/конфликт ели запускать "новое" приложение. Про всякие виндовсфоны и прочее вообще молчу. Я когда то объяснял меджерам что для холодильников и смарт-телевизоров есть сайт потому что мы не можем поддерживать все модели и площадки одновременно.
QR-код - `просто существует` расклеивается банер по поселку и все
с приложением тоже нужно название помнить. а если уж помнишь название то опять таки сайт или приложение нет разницы, если сайт так же гуглится по названию
В целом проект хорош не только как переводчик, но и как генератор книги в удобную html-читалку.
Я сам как раз уже пол года как не добью GUI-приложение для перевода художественного текста через нейронки (в коде оно работает уже полтора года успешно)может тоже статью на хабр сделаю как закончу.
Интересная тема - переводы через AI потому как контекстное окно накладывает свои ограничения, как и тематика первоисточника. По опыту хочу заметить что скинуть буферную память на самих агентов (ваши же glossary.md) очень хреновое решение потому как каждую книгу тогда нужно тюнить и перечитывать на правки, потому как гарантировано будут артефакты там где пошакалило смысл (или глоссарий который тоже не нулевой шанс быть пошакаленым если агенты с ним работают напрямую)
добавлю что профилирование обязательно нужно включать в любое высоко нагруженное приложение как параметр запуска, что бы оно разворачивало на внутренний адрес или вообще отдельный порт
потому как очень часто синтетические тесты не дадут той динамики что бывает на боевом сервере, а пересобирать с профилированием может вести себя иначе в мелочах
главное помните что профилирование потребляет ресурсы потому его включать только когда у вас есть запас по памяти и процу, иначе "тонких мест" окажется еще больше (большее падение производительности по факту)
для json целое поле от easyjson до прориоретатных вещей которые тянут сами либы по типу protobuf
но вообще последние версии json (которые v2) довольно хороши и так
это как с http - когда-то на заре сторонние решения маст хев для высоко нагруженных систем, но сейчас все чаше и чаше отказываешься от стороннего в пользу встроенного. Чем меньше зависимостей у продукта тем лучше на долгой дистанции
Осталось только ответить на вопрос ЗАЧЕМ
да нет, просто нейросети экспоненциальны по сложности
то есть для текущих флагманов нужны целые ЦОДы когда локальные модели можно запустить на "домашнем ПК" и получим те самые флагманы годичной с гаком давности
даже если начнут закручивать с обоих сторон (и провайдеры ИИ в том числе) то люди просто перейдут на дешёвые аналоги. Для SaaaS в текущих ограничениях уже хватит с избытком локальной модели. просто потратится неделька на подготовку что бы обучить нейросеть работать с продуктом и убедится что она защищена как снаружи там и изнутри не делает ошибок (то есть пограмный кадавр написанный нейросетью где та самая нейросеть лишь один из вызываемых методов)
другое дело что это открывает целый новый сегмент атак, но в остальном будет все отлично работать по типу "кинь мне последний инвойс от контрагента" или "сколько за пол года чистого прихода"
то есть весь SaaaS-цирк схлопнется до двух пользователей максимум (общий агент и ответственный админ и последняя инстанция), а если жалко денег то и вовсе одного пользователя
и это я не поднимаю возможность создания прокладки, что было популярно и до ИИ, просто с нейросетью такое станут делать чаше. Я про возможность попросить проклацать ИИ весь функционал SaaaS-продукта, скопировать верстку и создать свой тонкий клиент с распределёнными ролями, что бы тонкий клиент работал с валидным SaaaS-сервером от лица одного пользователя, а мы при этом могли нормально работать в многопользовательском режиме со своей стороны
О, "супер". Теперь кроме наркомании с "продажей мест" для цифрового продукта скоро появится еще счетчик "потребляемого контента" что бы не дай боже не упустить прибыль когда в специально переусложненной системе будет ковыряться один сотрудник-агент
Единое что радует - с неросетями в разы упала планка для "своих костыльных решений" а потому чем сильнее будут закручивать гайки, тем больше людей будут уходить с продукта, а значит петля замыкается и продукт умирает. И останутся только те кто не страдают фигней и оплата им действительно стоит, а не обычная деньговыжималка.
заводские штрихкоды то мертвая затея, анализировал, у меня реально большая аптечка это проблема которую я давно хочу решить
самое простое что я придумал это взять магазинный настренный терминал с камерой и екраноми перешить под себя.
новое просто крутишь под камерой со всех сторон, а уже фотки сторон уходят на сервер где в фоне распознаются гуглятся и сводятся в базу, что бы не просто дата, но и поиск по названиям и показаниям что бы знать что у тебя вообще есть, что закончилось и что есть например чисто от простуды
но с подходом выше тоже свои подводные
шаг дальше - самому маркировать (печать наклеек) и раскладывать картотекой по сгенерированному названию, что бы искать можно было по индексу, но такое не для всех и я гарантирую что мои домашние нифига не будут складывать туда же где взяли, а без этого быстрый контроль расположения теряется
а просто перебирать под сотню номнклатур, даже зная название и фото как выглядит коробка такое себе
медикаментами в таком разрезе скорее в тему была бы апка или умная камера
сам думал на эту тему, аптечка в целый шкаф и отслеживать все надо 100%. Но это все руками забивать((( Можно попробовать нейронку по фото заряжать но это или дорого или чертовски долго для распознания (разве что какая-то интеграция с агентами по подписке, но это только десктоп тогда)
а за готовку у меня как раз отдельный таймер похожй на тот что я кидал. енкодер на вращающийся корпус чертовски удобно
самое главное правило при работе с нейронками - брать ношу по себе
кроссревью вычесывают от 95% проблем (а если это веб то все 99% так как агенты могут пользоваться браузером) но потом нужно самому вычитывать что бы упрощать код от архитектурных излишеств и пере усложнений
в фоне запускать "танго" что бы агенты сами танцевали между собой я бы лично не рискнул, потому как нужно пробегаться по каждой итерации ревью ибо мелочи важны и с нейронками проблемы лучше предвосхищать чем потом пытаться решить уже архитектурную проблему
единый плюс как по мне это аналитика и возможность привязать "кухонные оповещения" на мультимедиа или вообще в телегу/пуш.
с медикаментами и тд такое себе - проще на телефоне быстро поставить единоразово, к тому же (из личного опыта) таймер не гарантирует прием, но сложный таймер отвлекает
для подобного (особо кухни) рекомендую юзать готовое. Вот например такое https://aliexpress.com/item/1005008352585162.html причем энкодер удобен для взаимодействия грязными руками например (можно предплечьем "прокрутить)
Устаревает не софт, а говнокод который работал на вере и молитвах, но какие либо обновления нарушают стабильную ауру и софт ломается.
99.9% проблем "устаревания" возникают по очень тупым причинам - не проверяют тип, не обрабатывают ошибку, не очищают память. Как много было проблем с гранью 32/64 причем в серьезных тулзах низкого уровня, которым проверять размерность входных данных не стоит ничего.
Один говнокод порождает другой говнокод. Вот круг и замкнулся. Особенно если баги становятся фичами которые активно используют и вот уже даже не сделать нормально ведь кривизна уже часть функционала.
Хватает вещей которые актуальны десятилетиями. У меня у самого есть исторические bash-скрипты которые я писал сам для простой работы с гит-хуками и версионностью парой команд. И они у меня уже около 11 лет почти не меняются. Вот только в этом году решил уйти наконец-то от баш-скриптов православных и написать гошную cli-утилиту что бы в рамках самого голанда все было кроссплатформенно через go run раз уж это сейчас мой основной язык.
А по поводу статьи - практически со всем согласен кроме "мимолетности". Если убрать за рамки обновления безопасности то большая часть ощущения мимолетности создана менеджерами и маркетологами, а не программистами. Софт живет не в ввакуме, а вращается вокруг пользователей и задач, и вот как тут классическая проблема бизнеса "на стабильном не заработаешь" ведь хорошо монетизируются только постоянные изменения.
Вот и возникает ощущения мимолетности, потому что за пару лет ОС начнет работать вообще иначе и старый софт не понимает что ему вообще тут делать, хотя по факту изменения косметические и зачастую еще и кривые как будто специально ломающие совместимость.
мда, неронки лучшее и худшее что было рождено в этом столетии
По UID - есть целая сфера знаний в в алгоритмах которая затрагивает генерацию минимально-уникального указателя в рамках заданной системы. Если уж ушли в эту степь то почитайте что люди пишут по этой теме. В целом при правильно подобранном алгоритме генерации указателя в 16 байт хватит что бы промаркировать все что только душенька пожелает с гарантированной уникальностью асинхронно и офлайн. Обычно даже меньше берут (я про всякие сервисы генерации временных ссылок где уникальных указателей милионы и более в час)
UUID используют просто от лени и нежелании разбираться в теме. Вообще UUID это стандарт под узкую сферу вот только та самая лень разработчиков (оно же гарантировано уникальное, берем!) растянула UUID везде где только можно и нельзя, а ведь достаточно только почитать как формируется UUID что бы "отрезать лишнее" и получить ключ с нужной глубиной уникальности конкретно для вашей задачи, а не огромный и неповоротливый UUID
я уже не вспомню за язык (Ruby вроде) но там можно было очень просто в коде задавать и работать с числами с произвольной числовой разрядностью. Хочешь 128 а хочешь 3 или 4. Причем вся алгебра так же подтягивалась.
Так вот, я в свое время наигрался с разными системами счисления и в целом получается шляпа.
- Троичная логика условий не натягивается на привычное да/нет потому как или нужна четкость (или да или нет) или же произвольность так же в жестко заданных рамках
- Много слышал тогда про то что "+1 бит в разы ускорит расчеты" и попытался это проверить. В итоге операций стало не сказать что меньше. Заметно становится на операциях с большим основанием и тут приходим к тому что четное основание проще для мысленного оперирования (компьютеру пофиг сколько он там считает)
Итог игр был в том что если я хочу "удобное ветвление" то ограничение в какое-то число не имеет смыла, удобно просто произвольный массив битов, где каждый бит это конкретный да/нет. А за арифметику в итоге пришел к классической криптографии, где оперирование числами большим основанием удобнее и быстрее чем разбиения на граничные int32 что бы работать с большими числами
По вашей работе - достойно уважения объем и глубина. Единое что не увидел ссылки на гитхаб или аналог что бы самому потыкать.
Следующим развитием было бы круто написать генератор которому даешь разрядность и он под него генерирует компилятор. Хочешь трехразрядное число, хочешь семиразрядное.
да да, вы ж специалист
просто напоминаю что мир гораздо больше видимого вами пузыря и то что вы видели в одном из поселков (и скорее всего со стороны) не означает что везде так
Строгая типизация
Сначала просим собрать данные в глоссарий, что бы вернул детерминировано в том же json. Важно что бы в контекстное окно с запасом влазил разбор с обсуждениями. Эти данные наполняют базу.
Далее базу переводим машинно по контексту и ОБЯЗАТЕЛЬНО вычитываем все глазами.
И наконец заряжаем "чистовой перевод" подставляя валидные куски глоссария под чанки (сопоставление по первой операции, где мы не только заполнили сам глоссарий но и сохранили в каких чанках какие значения были найдены)
В своей задаче с художественной литературой я еще выделил отдельную группу в "часто встречаемые значения" которая выдавалась с обычным глоссарием по чанку что значительно улучшило перевод ведь часто в книгах хватает иносказательности. Но я разрабатывал это еще во времена когда gpt только 4 вышла, сейчас с 1М окнами можно собирать и отдавать в качестве точки опоры гораздо больше данных.
У чувака на BMW обычно есть человек, что этим всем занимается
Для таких людей важна стабильность и беспроблемность - ему не важно как оно там работает и тд. Он обращает внимание если есть проблемы и/или не работает когда внезапно понадобится.
Из той же рубрики - "один раз закладку сделал и все"
то у вас просто большого охвата не было
начиная от неизвестных андроид-китайцев которыми пользуются бабки и заканчивая свяким пограничным когда старая версия прошивки у айфона и именно на этой версии есть баг/конфликт ели запускать "новое" приложение. Про всякие виндовсфоны и прочее вообще молчу.
Я когда то объяснял меджерам что для холодильников и смарт-телевизоров есть сайт потому что мы не можем поддерживать все модели и площадки одновременно.
QR-код - `просто существует`
расклеивается банер по поселку и все
с приложением тоже нужно название помнить. а если уж помнишь название то опять таки сайт или приложение нет разницы, если сайт так же гуглится по названию
так баг может вылазить на границах, когда нагрузочные равномерно давят по максимуму.
все тестами не покроешь, некоторые моменты что бы покрыть нужно сначала столкнутся что бы узнать что и так может быть
Огонь!
В целом проект хорош не только как переводчик, но и как генератор книги в удобную html-читалку.
Я сам как раз уже пол года как не добью GUI-приложение для перевода художественного текста через нейронки (в коде оно работает уже полтора года успешно)может тоже статью на хабр сделаю как закончу.
Интересная тема - переводы через AI потому как контекстное окно накладывает свои ограничения, как и тематика первоисточника.
По опыту хочу заметить что скинуть буферную память на самих агентов (ваши же glossary.md) очень хреновое решение потому как каждую книгу тогда нужно тюнить и перечитывать на правки, потому как гарантировано будут артефакты там где пошакалило смысл (или глоссарий который тоже не нулевой шанс быть пошакаленым если агенты с ним работают напрямую)
добавлю что профилирование обязательно нужно включать в любое высоко нагруженное приложение как параметр запуска, что бы оно разворачивало на внутренний адрес или вообще отдельный порт
потому как очень часто синтетические тесты не дадут той динамики что бывает на боевом сервере, а пересобирать с профилированием может вести себя иначе в мелочах
главное помните что профилирование потребляет ресурсы потому его включать только когда у вас есть запас по памяти и процу, иначе "тонких мест" окажется еще больше (большее падение производительности по факту)
для json целое поле от easyjson до прориоретатных вещей которые тянут сами либы по типу protobuf
но вообще последние версии json (которые v2) довольно хороши и так
это как с http - когда-то на заре сторонние решения маст хев для высоко нагруженных систем, но сейчас все чаше и чаше отказываешься от стороннего в пользу встроенного. Чем меньше зависимостей у продукта тем лучше на долгой дистанции