Это смотря как настроить систему документации! Я вот полностью смог решить эту проблему, создав отдельную систему что документооборота там все через версионирование и в работе только последняя утвержденая человеком версия используется и правки вносятся в нее вместе с кодом только через утверждение и апрувы
Мне кажется сейчас такое время что пора признать что документацию пишет ИИшка ))))) А мы лишь рецензируем и решаем нравится нам то что написано или нет.
Хороший разбор. И мне кажется, что главный вопрос при внедрении LLM на устройство должен возникать ещё до выбора Core ML или MLX где то на этапе постановки задачи. Думаю что разработчику важно поговорить с продуктовой командой и вместе оценивать действительно ли локальная модель нужна, какие компромиссы по памяти, батарее, скорости и сложности поддержки команда готова принять.
На практике довольно часто желание «давайте запустим нейронку прямо на телефоне» появляется скорее из-за хайпа вокруг AI, а не из реальной потребности пользователя. Я сам часто такие предложения слышал. И да во многих сценариях дешевле, быстрее и надёжнее использовать серверную модель.
Было дело что я внедрял лмку для распознования лабораторных анализов. И в подобных случаях, где есть чувствительные данные, требования к приватности, офлайн-работа или минимальная задержка, локальные модели действительно становятся оправданным решением.
Ты тут прав, что обычно гибридный подход выглядит наиболее практичным... надо не пытаться превратить смартфон в дата-центр), а грамотно разделить задачи между устройством и облаком
Иногда, читая очередные новости о проблемах технологий, кажется, что всё идёт не туда... Но это лишь кажется!
Сейчас мы живём, пожалуй, в самое лучшее и удивительное время за всю историю человечества!
Обычный человек сегодня может за несколько часов оказаться на другом континенте, получить доступ к знаниям всех университетов мира, общаться с людьми из любой страны и пользоваться технологиями! Все это ещё недавно было доступно только государствам и крупнейшим корпорациям.
Я думаю для чувствительных данных лучше использовать локальные решения или обезличенные данные. Думаю все проблемы все равно сводятся к базовым нарушениям протоколов безопасности и политиками работы с данными
Пока мы тут обсуждаем как ускорить поиск документов, где-то в гос органах сервера всё ещё падают после того, как бабуля уборщица задевает шваброй единственный удлинитель)))
Но по существу: самая дорогая часть здесь даже не поиск, а проверка найденного — актуальна ли версия, кем она утверждена и можно ли вообще на неё опираться.
У себя мы в итоге связали документы со статусами согласования, версиями и задачами через governance-систему и MCP.
Основной эффект получили не только от сокращения времени поиска, но и от уменьшения повторной работы и ошибок по устаревшим либо неутверждённым данным.
Поэтому ROI таких решений я бы считал ещё и через стоимость неверных решений.... она часто заметно выше стоимости самого поиска )))
По существу статья очень крутая. Больше всего меня зацепило даже не то, что несколько десятых миллиметра экономят авиакомпании миллионы, а то, что вся система Active Clearance Control управляет зазором, который она фактически не видит)) То есть у тебя двигатель за десятки миллионов долларов, FADEC непрерывно считает температуры, обороты, режимы и износ, но в самом важном месте всё равно работает по принципу: По модели лопатка вроде бы ещё не упёрлась)))
Да статья, конечно, интересная автор молодец, но потом я поднимаю глаза и вспоминаю, что это блог Selectel — компании, у которой я вообще-то читаю материалы про серверы, облака и инфраструктуру.
А тут это примерно так, будто Coca-Cola внезапно выпустила подробный разбор регулировки клапанов на «Ладе», а «МегаФон» решил научить нас правильно выводить пятна с белой рубашки))
В авиации ради нескольких десятых миллиметра строят отдельную систему управления, тратят на неё огромные деньги и в итоге экономят миллиарды. А малому бизнесу приходится заниматься примерно тем же самым — считать каждую виртуалку, каждый гигабайт и в результате нередко всё равно выбирать зарубежные дата-центры. Причём это началось не после всех известных событий: ещё в доковидные времена серверы в Европе часто стоили дешевле российских. Мне правда интересно, из чего складывается такая разница: электричество у нас дешевле чем за границей, оборудование, налоги, масштаб бизнеса, дорогая поддержка или всё гораздо прозаичнее — рынок просто позволяет брать больше?
Есть ли у Selectel мысли когда-нибудь уменьшить этот зазор между стоимостью инфраструктуры и бюджетом маленького стартапа?))
Согласен про AGENTS.md как единый источник правил. Я тоже начинал с инструкций внутри репозитория создавал отдельные папки с документацией, связывал файлы ссылками и просил клода читать их перед началом работы
На небольшом проекте это удобно, но по мере роста всё стало превращаться в большую помойку. Документы разбухают, ссылки ломаются, старые решения лежат рядом с актуальными и потом черт ногу сломит во всем этом хаосе (( а агенты всё сложнее понимают, и говнокодят по жесткому. Приходилось либо загружать в контекст слишком много, либо надеяться, что он сам найдёт нужный документ.
В итоге я заколебался по 10 раз просить переписать код и потратил 3 недели на разработку отдельной Governance системы. По сути отделил постоянные инструкции репозитория и от динамического контекста проекта. Перенес в монгу техническую документацию и всякие юридическая приказы, директивы, и тп. Ну и вишенкой было сделать что то типа жиры, сейчас там веду задачи, и вообще все о проекте.
AI-агенты работают с этой системой через MCP клод и кодекс получает актуальное дерево знаний и видит связи между документами и задачами, выполняет поискб и по умолчанию использует только действующие версии. Кстати прежние версии сохраняются, поэтому агент не может незаметно затереть историю, или что то случайно отредактировать.
Актуализация базы знаний у меня стала частью самого процесса разработки: новая задача, изменение архитектуры или принятое решение должны отражаться не только в коде, но и в Governance. На мой взгляд, когда проект становится достаточно большим, то разумно перейти на организацию документов в папки, но с дальшейшим ростом будут решения типа как я себе сделал, меньшего просто не хватает — нужна отдельная управляемая база знаний с MCP-интерфейсом для агентов.
Как нибудь опишу свою архитектуру, версионирование апрувы документов, ограничения прав агентов и для коллег))) Думаю такая тема явно заслуживает самостоятельного разбора.
Hazelcast стоит выбирать, когда нужен не просто кэш, а именно распределённая память приложения. В остальном и редисочка прекрасно работает )))
Это смотря как настроить систему документации! Я вот полностью смог решить эту проблему, создав отдельную систему что документооборота там все через версионирование и в работе только последняя утвержденая человеком версия используется и правки вносятся в нее вместе с кодом только через утверждение и апрувы
Мне кажется сейчас такое время что пора признать что документацию пишет ИИшка ))))) А мы лишь рецензируем и решаем нравится нам то что написано или нет.
Хороший разбор. И мне кажется, что главный вопрос при внедрении LLM на устройство должен возникать ещё до выбора Core ML или MLX где то на этапе постановки задачи. Думаю что разработчику важно поговорить с продуктовой командой и вместе оценивать действительно ли локальная модель нужна, какие компромиссы по памяти, батарее, скорости и сложности поддержки команда готова принять.
На практике довольно часто желание «давайте запустим нейронку прямо на телефоне» появляется скорее из-за хайпа вокруг AI, а не из реальной потребности пользователя. Я сам часто такие предложения слышал. И да во многих сценариях дешевле, быстрее и надёжнее использовать серверную модель.
Было дело что я внедрял лмку для распознования лабораторных анализов. И в подобных случаях, где есть чувствительные данные, требования к приватности, офлайн-работа или минимальная задержка, локальные модели действительно становятся оправданным решением.
Ты тут прав, что обычно гибридный подход выглядит наиболее практичным... надо не пытаться превратить смартфон в дата-центр), а грамотно разделить задачи между устройством и облаком
Пожалуй, никогда раньше у человека не было столько возможностей влиять на свою жизнь как сегодня.
Иногда, читая очередные новости о проблемах технологий, кажется, что всё идёт не туда... Но это лишь кажется!
Сейчас мы живём, пожалуй, в самое лучшее и удивительное время за всю историю человечества!
Обычный человек сегодня может за несколько часов оказаться на другом континенте, получить доступ к знаниям всех университетов мира, общаться с людьми из любой страны и пользоваться технологиями! Все это ещё недавно было доступно только государствам и крупнейшим корпорациям.
Я думаю для чувствительных данных лучше использовать локальные решения или обезличенные данные. Думаю все проблемы все равно сводятся к базовым нарушениям протоколов безопасности и политиками работы с данными
Пока мы тут обсуждаем как ускорить поиск документов, где-то в гос органах сервера всё ещё падают после того, как бабуля уборщица задевает шваброй единственный удлинитель)))
Но по существу: самая дорогая часть здесь даже не поиск, а проверка найденного — актуальна ли версия, кем она утверждена и можно ли вообще на неё опираться.
У себя мы в итоге связали документы со статусами согласования, версиями и задачами через governance-систему и MCP.
Основной эффект получили не только от сокращения времени поиска, но и от уменьшения повторной работы и ошибок по устаревшим либо неутверждённым данным.
Поэтому ROI таких решений я бы считал ещё и через стоимость неверных решений.... она часто заметно выше стоимости самого поиска )))
По существу статья очень крутая. Больше всего меня зацепило даже не то, что несколько десятых миллиметра экономят авиакомпании миллионы, а то, что вся система Active Clearance Control управляет зазором, который она фактически не видит)) То есть у тебя двигатель за десятки миллионов долларов, FADEC непрерывно считает температуры, обороты, режимы и износ, но в самом важном месте всё равно работает по принципу: По модели лопатка вроде бы ещё не упёрлась)))
Да статья, конечно, интересная автор молодец, но потом я поднимаю глаза и вспоминаю, что это блог Selectel — компании, у которой я вообще-то читаю материалы про серверы, облака и инфраструктуру.
А тут это примерно так, будто Coca-Cola внезапно выпустила подробный разбор регулировки клапанов на «Ладе», а «МегаФон» решил научить нас правильно выводить пятна с белой рубашки))
В авиации ради нескольких десятых миллиметра строят отдельную систему управления, тратят на неё огромные деньги и в итоге экономят миллиарды. А малому бизнесу приходится заниматься примерно тем же самым — считать каждую виртуалку, каждый гигабайт и в результате нередко всё равно выбирать зарубежные дата-центры. Причём это началось не после всех известных событий: ещё в доковидные времена серверы в Европе часто стоили дешевле российских. Мне правда интересно, из чего складывается такая разница: электричество у нас дешевле чем за границей, оборудование, налоги, масштаб бизнеса, дорогая поддержка или всё гораздо прозаичнее — рынок просто позволяет брать больше?
Есть ли у Selectel мысли когда-нибудь уменьшить этот зазор между стоимостью инфраструктуры и бюджетом маленького стартапа?))
Согласен про AGENTS.md как единый источник правил. Я тоже начинал с инструкций внутри репозитория создавал отдельные папки с документацией, связывал файлы ссылками и просил клода читать их перед началом работы
На небольшом проекте это удобно, но по мере роста всё стало превращаться в большую помойку. Документы разбухают, ссылки ломаются, старые решения лежат рядом с актуальными и потом черт ногу сломит во всем этом хаосе (( а агенты всё сложнее понимают, и говнокодят по жесткому. Приходилось либо загружать в контекст слишком много, либо надеяться, что он сам найдёт нужный документ.
В итоге я заколебался по 10 раз просить переписать код и потратил 3 недели на разработку отдельной Governance системы. По сути отделил постоянные инструкции репозитория и от динамического контекста проекта. Перенес в монгу техническую документацию и всякие юридическая приказы, директивы, и тп. Ну и вишенкой было сделать что то типа жиры, сейчас там веду задачи, и вообще все о проекте.
AI-агенты работают с этой системой через MCP клод и кодекс получает актуальное дерево знаний и видит связи между документами и задачами, выполняет поискб и по умолчанию использует только действующие версии. Кстати прежние версии сохраняются, поэтому агент не может незаметно затереть историю, или что то случайно отредактировать.
Актуализация базы знаний у меня стала частью самого процесса разработки: новая задача, изменение архитектуры или принятое решение должны отражаться не только в коде, но и в Governance. На мой взгляд, когда проект становится достаточно большим, то разумно перейти на организацию документов в папки, но с дальшейшим ростом будут решения типа как я себе сделал, меньшего просто не хватает — нужна отдельная управляемая база знаний с MCP-интерфейсом для агентов.
Как нибудь опишу свою архитектуру, версионирование апрувы документов, ограничения прав агентов и для коллег))) Думаю такая тема явно заслуживает самостоятельного разбора.