Что делать с архитектурным дрифтом в эпоху ИИ?
С появлением ИИ-инструментов код в проектах начал расти быстрее. Новый сервис, багфикс или интеграцию теперь можно получить быстрее чем согласование изменений, но цена архитектурной ошибки на этом фоне только растёт.Проблема не в том, что ИИ пишет плохой код, а в том, что он ускоряет накопление расхождений между тем, какой систему задумывали изначально, и тем, во что она превращается по мере изменений. Если архитектурные ограничения не формализованы и не проверяются автоматически, команда рано или поздно начинает проигрывать собственной скорости.
Закон Конвэя внутри нас: инженерные системы ломаются по тем же причинам, что и люди
Linux пропитан магией. Тип файла определяется не по расширению, а библиотекой magic, которая смотрит на сигнатуру первых байтов. В системе живут демоны, процессы могут работать в режиме daemon, а исполняемые файлы хранятся в формате ELF и разбираются утилитой readelf. Это похоже на шутки старых разработчиков, но они появились не случайно.Инженерные системы наполнены метафорами, потому что так проще думать о сложном, объяснять невидимое и работать с тем, что нельзя потрогать руками. Со временем мы привыкаем к этой «магии» и перестаём замечать, что вместе с ней перенимаем определённый способ мышления.
Весело о серьёзном: социальная инженерия женского оргазма
Продолжение темы социального программирования.Мы привыкли обсуждать баги в нашем социальном коде (Legacy-код), но есть одна сфера, где разница в программной архитектуре между мужчинами и женщинами
Как устроена архитектура факторов ранжирования в runtime поиска Ozon
Привет, Хабр! Меня зовут Лев. Я работаю в поиске Ozon. Сегодня я буду рассказывать про одну из составляющих поиска, а именно про ранжирование.В этой статье расскажу:
MCP Tool Registry: автоматизированное создание систем RAG
Всем привет! Меня зовут Максим Максимов, я — NLP-инженер в AI R&D лаборатории в red_mad_robot. Мы работаем с прикладными AI-системами, проводим эксперименты и проверяем архитектурные подходы в реальных сценариях.
Как я тестирую крупные системы, которые невозможно протестить на статичных данных
Например, в управлении транспортом статичные данные (например, сет за «типичный вторник») не дают протестировать систему в условиях праздника, крупной аварии, сессии у студентов, скидки 99% на Лабубу в крупном супермаркете и так далее. Что мы сделали:— Стали брать реальные данные с прода, которые выбиваются за стандартные представления.— Обезличивать их.— Использовать ML-модель для генерации сценариев, где эти данные увязываются с остальными в системе. Это типа генерации новых данных с усилением трендов и их пересечением.
Архитектура ИТ решений. Часть 5. Техническая Архитектура
Содержание курсаПонятие «Архитектура»Бизнес-архитектураИнформационная архитектураАрхитектура прикладных решений. Область разработки прикладных системАрхитектура прикладных решений. Портфель прикладных системТехническая АрхитектураПодходы к построению АрхитектурыГрафический язык моделирования ArchiMateАрхитекторы
Архитектура ИТ решений. Часть 4. Архитектура приложений. 4.2. Портфель прикладных систем
Содержание курсаПонятие «Архитектура»Бизнес-архитектураИнформационная архитектураАрхитек��ура прикладных решений. Область разработки прикладных системАрхитектура прикладных решений. Портфель прикладных системТехнологическая АрхитектураПодходы к построению АрхитектурыГрафический язык моделирования ArchiMateАрхитекторыПортфель прикладных систем (Application Portfolio) -
Галлюцинации в больших языковых моделях: анализируем и разбираемся
В этой статье рассматривается проблема галлюцинаций ИИ — их причины и возможные способы решения на архитектурном уровне. Это явление является одним из ключевых в работе современных языковых моделей. Создать надежную программу на базе ИИ невозможно без понимания причин возникновения галлюцинаций, которые нарушают работу систем и подрывают доверие к таким помощникам. Помимо технических сложностей, важную роль играет и человеческий фактор. Но обо всем по порядку.Системная природа проблемы
