Тема: Часть 18. Витрина кредитного портфеля
Уровень сложности: Средний
Расчётное время изучения: 3-4 часа
Предварительные требования: Базовые знания SQL (SELECT, GROUP BY, агрегатные функции, NULL-обработка)
Понимание концепции витрин данных (data marts) и слоистой архитектуры (staging → mart)
Знакомство с принципами data quality, воспроизводимости и валидации данных
Общее представление о кредитной отчётности и терминах stage/principal/days_past_due
Цели обучения: Объяснить назначение учебной витрины mart_credit_portfolio_quality и её минимальный контракт
Различать факты источника (stage, principal, days_past_due) и методологические интерпретации, не заложенные в спецификацию
Применять проверочные инварианты для агрегированной кредитной витрины (NOT NULL, неотрицательные суммы, соответствие числа строк)
Составлять корректные спецификации и заметки ревью, предотвращающие внедрение ложной банковской методологии
Формулировать Qwen-запросы для анализа витрины без модификации исходных файлов
Обзор: Часть 18 посвящена витрине кредитного портфеля mart_credit_portfolio_quality — учебному артефакту, демонстрирующему работу SDD Data с агрегированной отчётностью. Здесь центральная опасность смещается с PII-утечек на риск ложной методологии: слова stage, principal, просрочка и качество портфеля звучат как элементы серьёзной банковской модели (IFRS 9, PD, LGD, ECL), и агент может попытаться «улучшить» учебный пример, внедрив в него внешние знания. Глава учит отделять факты источника от интерпретаций, фиксировать границы витрины через спецификацию и заметку ревью, а также собирать проверочные инварианты, обеспечивающие воспроизводимость и честность отчёта.
Ключевые концепции: Витрина mart credit portfolio quality: Учебный data mart, агрегирующий синтетические кредиты по признаку stage. Минимальный контракт: stage NOT NULL, principal агрегируется воспроизводимо, просрочка не теряется при агрегации, источник stage описан явно, бизнес-интерпретация не выдумывается агентом.
Stage как синтетический признак: В реальном банке stage связан с IFRS 9 и risk methodology, но в учебном примере stage — это просто поле источника. Его нужно явно трактовать как синтетику, иначе агент начнёт «достраивать» методологию там, где её нет.
Принцип разделения фактов и интерпретаций: Любое поле витрины должно быть классифицировано как (а) факт источника, (б) учебное упрощение или (в) требует отдельной банковской спецификации. Без такой классификации витрина выглядит убедительно, но может означать разные вещи.
Минимальный контракт витрины: Набор обязательств: stage not null, суммы principal не отрицательные (если задано правилами источника), число строк соответствует числу уникальных stage-значений, ревьюер подтвердил, что stage не переопределён в SQL, заметка о влиянии на контракт зафиксирована.
Спецификация vs. реализация: Плохая спецификация: «Посчитать качество кредитного портфеля». Хорошая спецификация: «Группировать синтетические кредиты по исходному stage; показать loan_count и principal_rub; не выводить правила staging по IFRS; трактовать stage как поле источника». Реализация должна точно следовать спецификации.
Qwen-запрос для ревью витрины: Стандартизованный промпт вида: «Сравни stg_loans и mart_credit_portfolio_quality. Покажи, какие бизнес-допущения делает SQL. Отдели факты источника от выведенных правил. Файлы не меняй.» — позволяет проводить аудит без модификации исходников.
Заметка ревью: Фиксированная структура из шести блоков: исходный stage, агрегация, показатели, допущения, проверка, требуется подтверждение. Это скромная роль: ревьюер не становится кредитным комитетом, а лишь проверяет границы витрины.
Типичная ошибка: ложная методология: Агент может знать термины IFRS, PD, LGD, ECL и попытаться внедрить их в учебный проект. Вне продуктовой спецификации это ошибка: витрина начинает утверждать больше, чем способна доказать.
Days past due как факт источника: Число дней просрочки — это данные системы, а не методологическое решение о качестве портфеля. Решение, как именно days_past_due влияет на стадию, — это уже отдельная методология, требующая спецификации.
Principal rub и его двойственность: Может означать остаток долга или исходную сумму кредита. Если это не уточнено в спецификации, агрегат выглядит правильно, но интерпретируется неоднозначно. Спецификация должна либо закрыть вопрос, либо явно оставить его открытым.
Важные даты: 1 января 2018: Дата вступления в силу IFRS 9 — стандарта, который в реальных банках связывает stage с расчётом ожидаемых кредитных убытков (ECL). В учебной витрине это внешний контекст, упоминаемый только для понимания природы поля stage.
Дата не указана — учебный контекст: В рамках курса stage трактуется как синтетический признак без привязки к реальной методологической дате. Любая «дата расчёта ECL» в учебном примере выдумана агентом и должна быть удалена.
Практические упражнения: Название: Аудит минимального контракта витрины
Проблема: Вам дан SQL-запрос, формирующий mart_credit_portfolio_quality:
SELECT stage, COUNT(*) AS loan_count, SUM(principal_rub) AS total_principal FROM stg_loans GROUP BY stage;
Проверьте его на соответствие минимальному контракту учебной витрины. Какие инварианты проверяются на уровне данных, а какие — на уровне спецификации?
Решение: Шаг 1. Проверка NOT NULL: убедиться, что stage не содержит NULL (например, SELECT COUNT(*) FROM stg_loans WHERE stage IS NULL). Шаг 2. Проверка неотрицательности: SUM(principal_rub) >= 0 для каждой группы, либо явно зафиксировать, что отрицательные значения допустимы правилами источника. Шаг 3. Проверка числа строк: количество строк в витрине равно количеству уникальных значений stage. Шаг 4. Подтверждение, что stage не переопределён в SQL (нет выражений вида CASE WHEN days_past_due > 90 THEN 3 ... — это была бы методология). Шаг 5. Заметка о влиянии на контракт фиксирует, что методология не изменилась.
Сложность: intermediate
Название: Написание заметки ревью
Проблема: Заполните заметку ревью по кредитной витрине, используя шаблон из главы. Считайте, что stg_loans содержит 1200 синтетических кредитов с тремя значениями stage (1, 2, 3), principal_rub находится в диапазоне 50 000–5 000 000, days_past_due — от 0 до 180.
Решение: Исходный stage: поле stg_loans.stage, синтетический признак без привязки к IFRS 9. Агрегация: GROUP BY stage, агрегаты loan_count (COUNT) и principal_rub_total (SUM). Показатели: loan_count, principal_rub_total, средний principal_rub (только как производная метрика источника). Допущения: stage трактуется как поле источника; principal_rub — сумма исходных значений, без учёта остатка; days_past_due в витрине не интерпретируется. Проверка: stage NOT NULL — OK; суммы >= 0 — OK; число строк = 3 — OK; stage не переопределён в SQL — OK. Требуется подтверждение: методологические интерпретации (например, какой stage считать «проблемным») — не входят в скоуп учебной витрины.
Сложность: intermediate
Название: Обнаружение ложной методологии в SQL
Проблема: Коллега написал витрину со следующим фрагментом:
SELECT CASE WHEN days_past_due <= 30 THEN 1 WHEN days_past_due <= 90 THEN 2 ELSE 3 END AS stage, COUNT(*) AS loan_count, SUM(principal_rub) AS total_principal FROM stg_loans GROUP BY 1;
В чём здесь нарушение принципов главы? Перепишите запрос в корректной форме.
Решение: Нарушение: stage переопределяется в SQL на основе days_past_due. Это внедрение методологии (по сути — упрощённый IFRS 9 staging), которой нет в спецификации. Агент (или коллега) подменил поле источника собственной логикой. Корректная форма:
SELECT stage, COUNT(*) AS loan_count, SUM(principal_rub) AS total_principal FROM stg_loans GROUP BY stage;
Stage используется как поле источника без переопределения. Если нужна разбивка по days_past_due — это отдельная витрина с собственной спецификацией.
Сложность: intermediate
Название: Классификация поля витрины
Проблема: В витрине mart_credit_portfolio_quality появились поля: stage, loan_count, principal_rub_total, avg_days_past_due, ecl_provision. Классифицируйте каждое поле по трём категориям: (а) факт источника, (б) учебное упрощение, (в) требует отдельной банковской спецификации.
Решение: stage — факт источника (поле stg_loans.stage). loan_count — факт источника (производный от числа строк, воспроизводимый). principal_rub_total — факт источника (если трактуется как сумма исходных значений), но требует уточнения: остаток или исходная сумма. avg_days_past_due — учебное упрощение (агрегация факта источника без методологической интерпретации). ecl_provision — требует отдельной банковской спецификации, так как IFRS 9 ECL — это полноценная методология расчёта ожидаемых убытков; её нельзя добавлять в учебную витрину без отдельного ТЗ.
Сложность: intermediate
Название: Формулировка Qwen-запроса для ревью
Проблема: Сформулируйте Qwen-запрос для сравнения stg_loans и mart_credit_portfolio_quality. Запрос должен: (1) не модифицировать файлы, (2) выделить бизнес-допущения SQL, (3) отделить факты источника от выведенных правил.
Решение: Эталонный запрос из главы: «Сравни stg_loans и mart_credit_portfolio_quality. Покажи, какие бизнес-допущения делает SQL. Отдели факты источника от выведенных правил. Файлы не меняй.» Альтернативные формулировки допустимы при сохранении трёх инвариантов: режим «только чтение», явное требование выделить допущения, явное требование разделить источник и интерпретацию.
Сложность: beginner
Кейсы: Название: Кейс 1: Агент «улучшил» учебную витрину банковской методологией
Сценарий: Студент работал с учебной витриной mart_credit_portfolio_quality. Получив задание «посчитать качество кредитного портфеля», LLM-агент сгенерировал SQL, который рассчитывал stage по правилам IFRS 9 (12-month ECL для stage 1, lifetime ECL для stage 2 и stage 3 на основе days_past_due и PD/LGD-показателей). Витрина выглядела профессионально и содержала десять метрик, включая ecl_provision_rub.
Задача: Витрина утверждала методологические вещи, которых не было в спецификации. Студент не мог проверить корректность PD/LGD-логики, так как исходные данные были синтетическими. При этом отчёт выглядел «настоящим» и мог быть ошибочно воспринят как банковская аналитика.
Решение: Студент вернулся к спецификации, переписал её в явной форме: «Группировать синтетические кредиты по исходному stage; показать loan_count и principal_rub; не выводить правила staging по IFRS; трактовать stage как поле источника». SQL был переписан под эту спецификацию. Агент повторно вызван с уточнённой спецификацией — все ECL-поля удалены.
Результат: Витрина сократилась до трёх полей (stage, loan_count, principal_rub_total), но стала честной и воспроизводимой. Заметка ревью зафиксировала, что методология не входит в скоуп. Студент усвоил ключевой урок: реализация следует за спецификацией, а не за «здравым смыслом» агента.
Извлечённые уроки: LLM-агент может знать термины IFRS 9 / PD / LGD / ECL и внедрять их без спецификации — это типичная ошибка учебных проектов
Спецификация должна быть явной и закрывать методологические решения, иначе их примет за студента агент
Воспроизводимость важнее мнимой полноты: маленькая витрина, которая не врёт, ценнее большой, которая утверждает лишнее
Связанные концепции: Stage как синтетический признак
Принцип разделения фактов и интерпретаций
Типичная ошибка: ложная методология
Спецификация vs. реализация
Название: Кейс 2: Расхождение в principal_rub — остаток или исходная сумма
Сценарий: Аналитик строил витрину mart_credit_portfolio_quality и взял поле principal_rub из stg_loans как есть. Витрина показала SUM(principal_rub) = 4.2 млрд руб. по 1200 кредитам. При показе руководству возник вопрос: «Это текущий остаток или сумма выдач?». Аналитик не смог ответить сразу.
Задача: Без уточнения в спецификации одно и то же число могло означать принципиально разные вещи. Если это остаток — портфель здоров; если это выданная сумма без учёта погашений — картина другая. Витрина выглядела достоверно, но интерпретация была неоднозначной.
Решение: Аналитик обратился к источнику, установил, что principal_rub — это исходная сумма кредита на момент выдачи. Спецификация была дополнена явным указанием: «principal_rub трактуется как исходная сумма кредита (gross principal at origination), без учёта погашений». Если бы поле означало остаток, формулировка была бы соответствующей.
Результат: Заметка ревью получила уточнение в блоке «Допущения». Теперь любая интерпретация витрины однозначна. Аналитик сформулировал правило: «В кредитных данных особенно полезно отделять факт источника от интерпретации».
Извлечённые уроки: principal_rub — двусмысленное поле: остаток или исходная сумма. Спецификация обязана это закрывать
Убедительно выглядящий агрегат может означать разные вещи — это риск качества данных
Спецификация должна либо закрыть вопрос, либо явно оставить его открытым — но не молчать
Связанные концепции: principal_rub и его двойственность
Принцип разделения фактов и интерпретаций
Минимальный контракт витрины
Название: Кейс 3: Учебная витрина случайно попала в регуляторный отчёт
Сценарий: Внутренний учебный проект по SDD Data показал витрину mart_credit_portfolio_quality с реалистичными цифрами. Демо-данные случайно были подключены к рабочему BI-дашборду, который использовался для еженедельного обзора портфеля. Один из кредитных аналитиков скопировал число из витрины в служебную записку.
Задача: Учебная витрина не имела отношения к реальному портфелю, но её внешний вид (stage, principal_rub, days_past_due) был неотличим от боевой отчётности. Возник риск использования синтетических данных для реального управленческого решения.
Решение: Команда добавила в витрину явный технический признак учебности: комментарий в начале DDL-файла, водяной знак «EDUCATIONAL MART — NOT FOR REGULATORY REPORTING» в названии, отдельную схему базы данных. Заметка ревью пополнилась блоком о границах применения.
Результат: Случайное использование прекратилось. Команда зафиксировала правило: учебные витрины должны иметь явные маркеры учебности в названиях, схемах и метаданных, чтобы их нельзя было спутать с боевой отчётностью.
Извлечённые уроки: Внешний вид витрины (stage, principal, просрочка) не должен маскировать её учебный статус
Технические маркеры (схема, префикс, водяной знак) обязательны для учебных артефактов
Хороший отчёт ревьюера проверяет не только SQL, но и контекст применения витрины
Связанные концепции: Stage как синтетический признак
Заметка ревью
Граница между учебной витриной и реальной методологией
Советы по изучению: Перед написанием SQL всегда возвращайтесь к спецификации и проверяйте, не внедряете ли вы методологию, которой там нет
При работе с LLM-агентом используйте явные запреты: «не выводить правила staging по IFRS», «трактовать stage как поле источника», «файлы не менять»
Заведите привычку заполнять заметку ревью по шаблону из шести блоков — это дисциплинирует и предотвращает «уверенный текст вокруг недоказанной методологии»
Разделяйте в голове три категории полей: факт источника, учебное упрощение, требует отдельной банковской спецификации — и применяйте эту классификацию к каждому полю витрины
Не путайте воспроизводимость с полнотой: маленькая витрина, которая не врёт, всегда лучше большой, которая утверждает лишнее
При анализе days_past_due помните: число — факт, а решение, как оно влияет на качество портфеля, — уже методология
Используйте Qwen-запрос из главы как стандартный промпт для ревью витрин — он хорошо отделяет факты от интерпретаций
Помните о скромной роли ревьюера: он не кредитный комитет, а проверяющий границ. Это профилактика главного учебного дефекта
Дополнительные ресурсы: Ifrs 9 — financial instruments (обзор): https://www.ifrs.org/issued-standards/list-of-standards/ifrs-9-financial-instruments/ — для понимания того, как stage связан с ECL в реальном банке. Используйте только как контекст, не для внедрения в учебный SQL
Документация по data marts (kimball): https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/ — классические принципы построения витрин данных
Dbt documentation — mart слой: https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview — пример организации mart-слоя в современных ELT-проектах
Dbt assertions и тесты на not null: https://docs.getdbt.com/docs/build/tests — для автоматизации проверки инварианта stage NOT NULL
Great expectations — валидация данных: https://docs.greatexpectations.io/docs/ — инструмент для проверки неотрицательности сумм и соответствия числа строк
Русскоязычный курс по sdd data: Части 1–17 учебника — для понимания предыдущего контекста по staging-слою и общим принципам работы с PII
Резюме: Часть 18 учит работать с агрегированной кредитной отчётностью, где главный риск — не PII-утечка, а ложная методология. Витрина mart_credit_portfolio_quality агрегирует синтетические кредиты по полю stage, которое трактуется исключительно как поле источника, без переопределения в SQL. Минимальный контракт требует: stage NOT NULL, воспроизводимая агрегация principal, явное описание источника stage, отсутствие выдуманной бизнес-интерпретации. Проверочные инварианты включают контроль NULL, неотрицательность сумм, соответствие числа строк числу уникальных stage-значений и подтверждение ревьюера, что методология не изменилась. Глава закрепляет три ключевых навыка: разделение фактов источника от интерпретаций, составление заметки ревью по фиксированному шаблону и формулировка Qwen-запросов для аудита без модификации файлов. Главный урок: учебная витрина должна ясно показывать, где заканчивается пример и начинается реальная банковская методология, — иначе агент внедрит внешние знания (IFRS, PD, LGD, ECL) без спецификации, и отчёт начнёт утверждать больше, чем способен доказать.