Что вы сделаете в первую неделю на новой работе Senior AI Engineer?

Краткий тезис

Первая неделя Senior AI Engineer — это не про код, а про сбор информации и построение доверия. Ключевая ошибка — сразу предлагать переписать всё с нуля (это красный флаг). Вместо этого нужно понять бизнес-задачи, текущую архитектуру и болевые точки (галлюцинации, latency, пропуски ретрива). К концу недели вы должны иметь дашборд ключевых метрик, воспроизводимый тест для главной проблемы и quick win — небольшое улучшение, которое можно внедрить за день-два.

1. День 1: Погружение в бизнес-контекст и продукт

Цель — понять, какую ценность создаёт система и кто её пользователи.

1.1 Встречи с ключевыми стейкхолдерами

• Product Manager — какие фичи приоритетны? Какие метрики бизнеса (конверсия, retention, NPS)?
• Tech Lead / Architect — текущая архитектура, стек, репозитории, CI/CD.
• Domain Expert (если продукт в нише) — терминология, типичные кейсы.

1.2 Изучение документации

• README проекта, ADR (Architecture Decision Records), wiki.
• Диаграммы (C4, UML) — если их нет, попросите или нарисуйте сами.

1.3 Что записать

Термин SLA (Service Level Agreement) — согласованный уровень сервиса, например, p99 latency < 2 секунд.

2. День 2: Анализ текущей архитектуры и кодовой базы

Цель — оценить техническое состояние системы: retrieval pipeline, LLM integration, мониторинг.

2.1 Карта архитектуры

• Нарисуйте flow diagram от запроса пользователя до финального ответа:
  1. Вход (API → рерайтинг запроса? → retrieval → ранжирование → LLM → постобработка).
  2. Какие сервисы используются (векторная БД, LLM API, кэш, логгер).
  3. Какие эмбеддинги и модели (BERT, OpenAI, open-source).

2.2 Code review ключевых модулей

• Посмотрите основной RAG-пайплайн: как формируются промпты, как режется контекст, есть ли reranker.
• Выявите очевидные проблемы:
  • Жёстко заданные top-k без опции динамического выбора.
  • Отсутствие фильтрации по релевантности (все чанки попадают в LLM).
  • Нет fallback на случай пустого ответа.

Термин fallback — запасной план, если основная логика не сработала.

2.3 Пайплайн метрик

• Есть ли логирование каждого запроса с задержками, ответами, использованными чанками?
• Собираются ли offline метрики (hit rate, MRR)? Если нет — это первая проблема.

3. День 3: Выявление узких мест (bottlenecks)

Цель — найти главную боль, которую можно измерить и исправить.

3.1 Интервью с командой

• Спросите коллег: «Что вас раздражает? С чем вы тратите больше всего времени?»
• Типичные боли:
  • Галлюцинации (LLM выдумывает факты) → проблема faithfulness.
  • Высокая latency → долгий retrieval или вызов LLM с огромным контекстом.
  • Retrieval miss (ретривер не находит нужный документ) → низкий recall.

3.2 Быстрый анализ логов

• Возьмите 100–1000 последних запросов из продакшна (логи или дамп БД).
• Посчитайте вручную (или скриптом):
  • Среднее время ответа.
  • Доля ответов с отказом («Я не знаю»).
  • Частота повторных запросов от пользователя (переформулировка).

3.3 Определение критической метрики

• Например: p95 latency > 5 секунд, faithfulness < 80% (по оценке RAGAS).
• Выберите одну метрику, которую можно улучшить за 1–2 недели.

4. День 4: Создание дашборда ключевых метрик

Цель — визуализировать текущее состояние и отслеживать динамику.

4.1 Выбор инструмента

• Grafana + Prometheus (если микросервисы) или Datadog / New Relic.
• Для хранения метрик можно использовать PostgreSQL с временными рядами.

4.2 Какие метрики включить

4.3 Пример простого скрипта для offline метрик (Python)

import json
from collections import defaultdict

def compute_hit_rate_mrr(queries, gold_docs, retrieved, k=5):
    """
    queries: list of query texts
    gold_docs: dict {query_id: list of relevant doc ids}
    retrieved: dict {query_id: list of retrieved doc ids (ordered)}
    """
    total = len(queries)
    hits = 0
    reciprocal_ranks = []
    for qid in queries:
        retrieved_k = retrieved[qid][:k]
        gold = set(gold_docs[qid])
        # Hit rate: at least one gold in top-k
        if any(doc in gold for doc in retrieved_k):
            hits += 1
        # MRR: 1 / rank of first gold, 0 if none
        rr = 0.0
        for rank, doc in enumerate(retrieved_k, 1):
            if doc in gold:
                rr = 1.0 / rank
                break
        reciprocal_ranks.append(rr)
    hit_rate = hits / total
    mrr = sum(reciprocal_ranks) / total
    return hit_rate, mrr

Формат дашборда: три панели — latency, retrieval метрики, faithfulness. Обновите дашборд к концу дня.

Термин RAGAS — библиотека для оценки RAG-систем: автоматически вычисляет faithfulness, answer relevancy, context relevance.

5. День 5–7: Быстрая победа (quick win) и план на 1–3 месяца

Цель — показать ценность за первую неделю и заложить фундамент.

5.1 Выбор quick win

• Увеличить top-k с 3 до 5 (если recall низкий, а latency позволяет).
• Добавить reranker (например, Cohere rerank или кросс-энкодер BERT) поверх ретривера.
• Улучшить промпт — добавить инструкцию «Если не знаешь — скажи, что не знаешь» (снижает галлюцинации).
• Починить очевидный баг — например, не используется флаг return_full_text у LLM (дублирует контекст).

5.2 Воспроизведение главной проблемы

• Напишите end-to-end тест, который демонстрирует проблему.
  Пример: запрос «Какой бюджет на 2025 год?» → ретривер возвращает документ 2019 года → LLM отвечает устаревшими данными.
• Тест должен быть автоматизирован (pytest + mock) и добавлен в CI.

5.3 Презентация плана на 1–3 месяца

• Неделя 2–3: внедрение выбранного quick win, замер эффекта на дашборде.
• Месяц 2: более глубокая оптимизация (chunking, эмбеддинги, fine-tuning ретривера).
• Месяц 3: A/B тестирование новой архитектуры (например, Hierarchical RAG).

Термин A/B тестирование — сравнение двух версий системы на случайных 50% трафика.

5.4 Документация решений

• Напишите ADR (Architecture Decision Record) для каждого изменения: «Почему выбрали reranker X, а не Y».
• Зафиксируйте ожидаемые метрики до улучшения и план замера.

6. Soft skills и коммуникация

Первая неделя — это также политика:

• Не критикуйте существующее без предложений. Вместо «Этот код ужасен» скажите «Я заметил, что здесь можно ускорить, если…».
• Предложите помощь коллегам в их задачах (code review, багфикс) — это создаёт доверие.
• Соберите обратную связь в пятницу: «Что я делаю не так?» → показывает готовность учиться.

Пет-проект для закрепления

Задача: Смоделировать первую неделю на вымышленном проекте — RAG-система для поддержки клиентов (5000 запросов/день).
Инструменты:

• FastAPI (заглушка API)
• Weaviate (векторная БД)
• OpenAI API
• Grafana + InfluxDB (дашборд)
  Шаги:

1. Запустите локально RAG-пайплайн с известной проблемой (например, low hit rate из-за маленького top-k).
2. Напишите скрипт для сбора логов (100 запросов в JSON).
3. Посчитайте hit rate, MRR, latency.
4. Создайте дашборд в Grafana (импортируйте готовый шаблон).
5. Предложите quick win (увеличение top-k) и покажите улучшение на дашборде.
6. Напишите тест, который ловит галлюцинации (LLM отвечает без контекста). Ожидаемый результат: Репозиторий с дашбордом, скриптом метрик, тестом и документом с планом на 1 месяц.

Связь с другими вопросами

Навигация

• Предыдущий: 99
• Следующий: 101
• Индекс: 00. Индекс разборов