Agaltsov Anton | TeamLead-блог

🏗️ Clean Architecture: правило зависимостей сильнее любой диаграммы Clean Architecture Роберта Мартина разделяет систему на концентрические слои: в центре — бизнес-логика (сущности и сценарии использования), на периферии — фреймворки, интерфейс и базы данных, объявлённые «деталями». Единственное жёсткое правило стиля: все зависимости исходного кода направлены строго внутрь, к домену. Это правило превращает архитектуру из набора красивых схем в проверяемое свойство кодовой базы: направление зависимостей измеряется статическим анализом, и нарушение можно ломать сборкой. Внутренние слои не знают имён внешних классов — поэтому домен не меняется вместе со сменой фреймворка, UI или СУБД. 💡 Мартин не претендовал на новизну идеи: гексагональная архитектура Коубёрна, Onion Палермо и BCE Якобсона — вариации одной темы. Вклад Clean Architecture — единый словарь из четырёх колец (Entities → Use Cases → Interface Adapters → Frameworks & Drivers) и связь с принципами SOLID, применёнными не к классу, а к системе целиком. Практическая граница применимости: для чистого CRUD без бизнес-правил интерактор-транзит лишь добавляет слой без содержания. Слои следуют за сложностью, а не наоборот. 🔗 https://agaltsovav.ru/docs/architecture/clean-architecture/

📊 Метрики LLM: как превратить «кажется, стало лучше» в измеримые данные LLM по своей природе вероятностны: на один и тот же запрос модель может вернуть разные ответы, а правильность нельзя проверить простым сравнением строк. Классические unit-тесты здесь бессильны — метрики превращают субъективные ощущения в объективные, воспроизводимые данные. Универсальной «одной метрики качества LLM» не существует. На практике комбинируют несколько категорий: качество генерации (Perplexity, BLEU, ROUGE, BERTScore), соответствие задаче (Exact Match, F1, следование инструкциям), LLM-as-a-judge, метрики RAG (faithfulness, релевантность контекста), безопасность и операционные характеристики — латентность, throughput, стоимость за миллион токенов. Отдельный слой — стабильность: консистентность ответов, робастность к перефразированиям и опечаткам, калибровка уверенности. Некалиброванная модель, уверенная в неверных ответах, опаснее той, что честно отвечает «не знаю». 💡 Метрики выбираются под продукт, а не наоборот. Для чат-бота это win-rate и скорость первого токена, для RAG — набор RAGAS, для кодогенерации — pass@k. Разумный старт: одна-две метрики качества под основной сценарий, пара операционных под экономику и одна метрика безопасности. 🔗 https://agaltsovav.ru/docs/ai/llm-metrics/

🎯 Product-Market Fit — точка, после которой рынок тянет продукт сам Product-Market Fit (PMF) — состояние, при котором продукт удовлетворяет реальную потребность достаточно большого рынка. Формула Марка Андриссена короткая: рынок сам тянет продукт из ваших рук. Жизнь стартапа делится на две части — до PMF и после, и управляются они по разным правилам. Соответствие продукта рынку складывается из трёх элементов. Ценность — продукт закрывает настоящую потребность, пользователи называют его «must-have». Лёгкость — путь до ценности короткий, пользователь быстро доходит до сути. Охват — аудитория достаточно велика, чтобы поддерживать растущий бизнес. Дефицит любого элемента разрушает PMF. Главный опрос для замера — методика Шона Эллиса: «Как вы расстроитесь, если продукт исчезнет?» Если «очень расстроены» отвечают более 40% активных пользователей — у продукта, вероятно, есть PMF. PMF можно потерять — это спектр, а не разовое достижение. Рынок сдвигается, конкуренты переманивают ядро, погоня за новыми сегментами распыляет разработку. Сигналы потери: снижение Sean Ellis score в новых когортах, кривые удержания ниже предыдущих, рост оттока, падение доли органики. Поэтому PMF мониторят регулярно, а не «получают один раз и навсегда». 🔗 https://agaltsovav.ru/docs/product-managment/product-market-fit/