CODERIKK

🔹 Как понять, хорош ли ответ генеративной модели (LLM — large language model)? 🔸 Метрики нужны, чтобы быстро ловить регрессии и сравнивать версии модели: автоматические дают сигнал на CI, человек проверяет факты и полезность. 🔸 BLEU и ROUGE измеряют n‑gram overlap с эталонными ответами: BLEU — «precision» совпадающих фрагментов, ROUGE — «recall/длинная общая подпоследовательность». Работают, когда есть надёжные референсы, но пропускают корректные парафразы. Пример: эталон «Кошка сидит на ковре», кандидат «На ковре сидит кошка» — высокая перекрываемость, но семантика может быть сложнее...

🔹 Что решает нормализация? 🔸 Нормализация нужна чтобы убрать избыточность и аномалии обновления: без неё данные дублируются и при изменении возникают рассинхроны. Нормализация снижает ошибки и упрощает поддержку. 🔸 1NF (первая нормальная форма) — поля атомарны: нельзя хранить списки в одном столбце. Users(id, name, phones) -- phones: "111,222" Нормализация: Users(id, name) Phones(user_id, phone) 🔸 2NF (вторая нормальная форма) — для таблиц с составным ключом: убираем частичные зависимости, выносим данные, зависящие от части ключа, в отдельные таблицы...

) 🔹 Как организовать retry и dead-letter для ETL, чтобы не терять данные? 🔸 Повторные попытки нужны, потому что большинство ошибок — временные (сеть, таймаут, блокировка). Без retry вы теряете записи или получаете неконсистентные состояния; exceptions нужно разделять на retryable и fatal. 🔸 Используйте retry с лимитом и backoff; при исчерпании попыток — помещайте запись в dead-letter queue (DLQ). Обрабатывайте exceptions отдельно: non-retryable сразу в DLQ. Введите идемпотентность и транзакции для consistency...

🔹 Когда и зачем применять materialized view? 🔸 materialized view хранит заранее вычисленные результаты (precompute) в отдельном storage, чтобы чтение шло из готовой структуры — это даёт заметное улучшение query speed за счёт избегания повторных тяжёлых вычислений. 🔸 Решает повторяющиеся дорогостоящие JOIN и агрегации, аналитические дашборды и latency‑чувствительные API (интерфейс прикладного программирования): вместо ре‑вычисления — чтение из materialized view. 🔸 Применять, когда данные меняются...

🔹 Когда лучше threading, а когда asyncio? 🔸 Без конкурентности (concurrency) приложение простаивает при I/O: клиенты ждут, throughput падает. threading и asyncio дают параллельность (parallelism) разными способами, чтобы не блокировать процесс. 🔸 threading — это OS‑потоки. Простая модель: запустил функцию в Thread. Хорошо для блокирующего I/O и когда есть C‑расширения, которые освобождают GIL (Global Interpreter Lock). 🔸 GIL (Global Interpreter Lock) мешает реальной параллельности Python‑байткода:...