AI Engineering: Основные навыки AI-разработчика

Давайте немного о книге выше.

Chip Huyen пишет:

AI-разработчик — это не тот, кто общается с ChatGPT. Это тот, кто умеет превращать модель в рабочую систему. Если классический разработчик пишет правила, то AI-разработчик пишет условия, в которых модель думает правильно.

Если вкратце, она определяет такие критерии:

1️⃣ Prompting

Нужно формулировать инструкции так, чтобы модель действовала предсказуемо. Это как писать ТЗ для гениального, но капризного подрядчика. Если инструкция двусмысленна, результат непредсказуем.

2️⃣ Контекст-инженерия

Умей превращать хаотичные документы в осмысленный контекст, который улучшает ответы. Она пишет, что модель умный собеседник, но половина ее интеллекта зависит от того, что вы ей расскажете перед вопросом.

3️⃣ Адаптация моделей: finetuning, выбор моделей, компромиссы

Нужно понимать, когда достаточно промпта, когда нужен RAG, а когда — дообучение. Как в готовке блюд. Иногда достаточно соли, иногда нужна новая специя, а иногда целый новый рецепт.

4️⃣ Оценка качества (evaluation): метрики, AI-судьи, тесты

Умей системно измерять качество, а не на глаз. Тут уже сравнение про медицину, где без диагностики улучшения невозможны.

Если применять кейсы к мобильной разработке, то знания устройства работы облачных LLMок поможет лучше делать приложения. Например, моя задача сверстать кнопку. Как помогут мне знания?

В идеале, нужно делать так:
1. Вместо обычного запроса "сверстай мне кнопку" дай АИ максимальное описание с API JSON'ом, стили, состояния
2. Опиши какие действия она выполняет.
3. Какие условия и ограничения есть.
4. Отдельно автор подчеркивает важность guardrails. Для UI это означает: проверка, что данные валидны. Убедись что AI не прислал недопустимый код. Убедись что поведение безопасно.
5. Огромный акцент на feedback loop: не забывайте писать аишки правильный ли результат она сделала. Даже ваши лайки влияют на ее следующие генерации.

Проектирование реальных фич: Feed App ч 1

Продолжаю тему книг.

Среди книг про моб систем дизайн самая практичная — это "Mobile System Design Interview" от ByteByte. Здесь нет философии в пусть и хорошей, но очень большой Mobile System Design.

В книге от ByteByte все главы направлены практику. Только хардкодному проектированию. В первой общедоступной главе разбирают одну из самых частых фичей — ленту новостей.

Вопреки заблуждениям, новостная лента — это не просто список постов.

Я разобью инфу на несколько постов. Первый про общие требования и ожидания.

Лента — это система, которая должна:
- быстро отдавать релевантные посты
- работать для миллионов пользователей
- обновляться почти в реальном времени
- быть стабильной при высокой нагрузке

Ключевая сложность — это как собрать правильные посты и отдать их быстро. Так как обычно ленты делаются для миллионой аудитории.

При проектировании фичи обычно выделяют:
- пагинация
- Низкая задержка. Лента должна открываться быстро
- Масштабируемость.
- Оптимизации для плохого интернета

Есть несколько основных подхода для формирования ленты

1️⃣ Pull model (on-the-fly)

Когда пользователь открывает ленту:
- сервер собирает посты прямо сейчас
- сортирует публикации
- отдает результат

Плюсы
- простая логика
- всегда актуальные данные

Минусы
- медленно при большом числе подписок
- тяжелая нагрузка на сервер

2️⃣ Push model (precomputed feed)

Когда кто-то публикует пост:
- он заранее раскладывается в ленты подписчиков
- при открытии ленты данные уже готовы

Плюсы
- очень быстрая загрузка ленты
- меньше вычислений при чтении

Минусы
- дорого по памяти
- сложнее поддерживать

Автор говорит, что на практике используют гибридный подход.

По мнению автора что хотят услышать интервьюеры:
- ты понимаешь trade-offs (push vs pull)
- ты думаешь про кэш
- ты учитываешь мобильные ограничения
- ты умеешь объяснять архитектуру шаг за шагом

1/3

wtf? Ждем переезда в Max?

Почему не надо идти в iOS сейчас

Очередное обсуждение что лучше iOS vs Backend для начала карьеры.

Я, как и многие у нас в чате, уже давно советуют идти в иос не ради денег, а по любви.

Тот же бэкенд уже давно обогнал по вилкам мобилки. А ML улетели в космос.

Комментаторы подсвечивают, что эпоха, когда всем нужны были приложения - уже закончилась. Сейчас безопасная зона только в бигтехах и фаангах. На долгосрочной поддержке.

Кстати, кто не помнит, то напоминаю. Сейчас заканчиваю последний курс очно-заочного обучения. Учился 4 года на бизнес-информатика. Пришло время выбирать выпускную квалификационную работу.

Сразу побежал смотреть список тем от универа и нашел самую подходящую для меня: "Применение генеративного ИИ для создания персонализированных образовательных программ"

Будем делать ее с научным руководителем. Интересно как эта работа пробустит меня и чему обучают современные программы универов

Покидаю самые интересные инсайты

А вы поделитесь пожалуйста где подобное по теме уже встречали? В курсах, работе, универе?

Записываем нормальный подкаст в нормальном офисе с нормальным светом.

Network: Мобильная связь и квота пропускного канала

Зачем думать о 2G интернете? Ведь далеко не все тестят свои апки в этой сети.

Тема мобильной сети — гиперчувствительная. И при этом сильно недооцененная в мобильной разработке.

Недавно я брал консультацию у core команды Яндекс Плеера о том, как оптимизировать видео. Формально разговор был про форматы, коллекции и устройство плеера. Но самым откровенным и очевидным для меня оказался совсем другой пласт — это нетворк-квоты и приоритизация запросов. Казалось бы, очевидно. Но почему мы не задумываемся об этом?

Об этом редко задумываются, когда речь идет об обычной верстке или стандартных апи-запросах. Но в видео все иначе: общий трафик, количество соединений и их приоритет критически важны.

Да, в некоторых крупных компаниях есть платформенные или перфоманс-команды (Авито, Т-Банк), которые глубоко оптимизируют нетворк-слой клиента. Но возникает логичный вопрос: почему обычному мобильному разработчику важно понимать, как работает сеть?

Многие разработчики воспринимают сеть как что-то простое: отправил запрос и получил ответ. В реальности мобильная сеть: нестабильная, медленная, непредсказуемая. Именно поэтому в системном дизайне ей всегда уделяют отдельное место. Игнорировать сеть значит проектировать приложение для идеальных условий, которых у пользователя чаще нет.

О сети можно говорить часами. В этой серии постов я хочу детально разобрать, как работает network в мобильных приложениях и с какими проблемами мы сталкиваемся на практике.

Начнем с базовых, но очень важных сложностей:

1️⃣ Соединение постоянно меняется

Этот вопрос очень важен. Особенно при звонка, которые должны работать даже из парковки и в лифте. Тот же Zoom удивляет многих как работает стабильно с 3G или плохим интернетом, когда же конкуренты, телега или ватсап, еще до замедлений, работали плоховато.

Здесь множество оптимизаций: от хитрых алгоритмов сжатия, то заигрывания с соединениями.

2️⃣ Высокая задержка (latency)

Есть cold и hot ответы. И чаще ответы CDN или других хранилищ нужно заранее "прогревать". Ведь даже при хорошем соединении холодный старт может быть отдавать первый байт долго.

3️⃣ Ограниченный и дорогой трафик

В некоторых регионах, странах, трафик может быть дорогой. В том же Пакистане интернет в 2 раза хуже РФ, но некоторые сервисы уже получают денег больше, чем у себя в стране. Чтобы конкурировать нужно уметь подстраивать под их сеть и быть быстрее конкурентов.

4️⃣ Нетворк квота устройства

Устройство условно на момент соединения имеет доступную пропускную способность 5 Мбит/с. Это общий канал, которым пользуются все процессы сразу: ваше приложение, системные сервисы, другие приложения в фоне. Под наше приложения нет отдельного канала. Все делят один и тот же ресурс.

Если одновременно идут загрузка видео, аналитика, картинки, обработка данных — все запросы конкурируют за один канал. Видео хочет 4 мб/с, аналитика 0.1 мб/с, апи запросы 0.9 мб/с. Канал полностью забит. Если появляется еще один запрос, то появляются лаги и зависания.

И тут еще сложность, что ОС распределяет ресурсы, а не приложение.

В след постах разберем все детальнее