Частичные индексы

Представьте ситуацию. В БД PostgreSQL есть таблица с данными водителей:
id
company_id
name
phone

Внутри одной компании номер телефона водителя должен быть уникален. Для этого заведен индекс уникальности по (phone, company_id).

Затем добавляется возможность удалять водителей из кабинета компании. Удаление реализуем через soft delete: добавляем в табличку поле is_deleted. Все работает корректно.

Проходит время, и от пользователей приходит баг: при добавлении нового водителя возникает ошибка.

В логах видно, что БД ругается из-за нарушения уникальности. Оказалось, что запись с таким номером телефона уже существовала и была удалена.

Перед вставкой записи о новом водителе в коде делали проверку, нет ли уже в этой компании водителя с таким телефоном, но проверка была для неудаленных водителей: WHERE is_deleted = false, поэтому она не находила ранее удаленного водителя (и это правильно).
Для просмотра списка водителей тоже возвращались только неудаленные записи.

А индекс уникальности по (phone, company_id) при добавлении поля is_deleted изменить забыли. Поэтому при попытке добавить ранее удаленного водителя с тем же номером телефона возникала ошибка 😢

Разобрались, сделали, чтобы индекс уникальности тоже учитывал только неудаленные записи:
create unique index uc_drivers_phone_company_id
on drivers(phone, company_id)
where is_deleted is false;

Такой индекс называется частичным.

Частичный индекс — это индекс, который строится не по всем строкам таблицы, а по их подмножеству, определяемому условием WHERE. Это не обязательно должен быть индекс уникальности, может использоваться для индексов поиска.

Обратите внимание, что поле из WHERE не обязано быть индексируемым. В примере мы строим индекс по полям phone, company_id, а в предикате используем поле is_deleted.

Когда частичный индекс может пригодиться:

➡️ Как в разобранном выше кейсе, если нужно сделать уникальность по условию.

➡️ Когда в таблице 90% записей "неинтересны" для запросов, можно построить частичный индекс по оставшимся 10%, он будет работать быстрее и занимать в несколько раз меньше места.

Например, у вас есть таблица счетов.
90% счетов имеют статус "Оплачено", а запросы касаются счетов в других статусах.

Если сделать частичный индекс, проиндексировав для поиска оставшиеся 10% неоплаченных счетов, то такой индекс будет занимать значительно меньше места, чем индекс по всем строкам.

Это имеет смысл на больших таблицах, от миллионов строк, когда индекс по всей таблице становится слишком тяжёлым. Плюс запросов к тем 90% непроиндексированным строкам действительно должно быть минимум, ведь они будут обрабатываться без индекса.

⚡️ Ещё кейс из практики.

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

В рамках одной из задач мне нужно было поддержать уникальность связки полей (a, b, c). Я добавила индекс и стала писать тесты. Поле c могло быть null, и в процессе тестирования я обнаружила, что несмотря на индекс могу добавить в таблицу две одинаковые записи со значениями:
a = 1, b = 2, c = null
a = 1, b = 2, c = null

Я знала, что c NULL используется не !=, а IS NULL и IS NOT NULL, так как для PostgreSQL NULL — это не значение, а маркер отсутствия данных. Но оказалось, что с null-значениями еще и уникальный индекс не видит конфликт.

И если мы хотим разрешить только одну такую запись a = 1, b = 2, c = null, то нужно сделать два частичных индекса уникальности:

1️⃣ Уникальность связки (a, b) where c is null
2️⃣ Уникальность связки (a, b, c) where c is not null

Частичные индексы — нечастая история, но могут пригодиться.

Читала, что в некоторых компаниях отказываются от constraints на уровне БД, таких как foreign keys и индексы уникальности, все необходимые проверки существуют только на уровне кода. Поделитесь, пожалуйста, как у вас?

🔗 — у нас созданы foreign keys и индексы уникальности в БД

💅 — у нас все проверки на уровне кода, индексы только для ускорения поиска

Я ставлю крест на RAG: почему поиск по базе — это теперь задача для джуна, а будущее — за Generic Agent

Байт засчитан =)

Капля истории
Мы с вами начали с фундамента AI-инфраструктуры тестировали Llama на кластерах 4090, показывал вам тюн Whisper и считали экономику on-premise решений
Затем углубились в сложный RAG и Vibe Coding: заняли топ с малыми моделями в Enterprise RAG Challenge изучили Circuit Tracing для поиска галлюцинаций и научились собирать MVP за 7 дней
В середине 2025 перешли к автономным системам: запустили open-source SGR Deep Research доказали эффективность на бенчмарках и выпустили фреймворк SGR Agent Core


Честно говоря к концу 2025 года стало очевидно что RAG превратился в стандартную инженерную задачу которую может собрать джун по туториалам

Настоящий вызов сместился к агентам
И вот тут начинается самое интересное потому что большинство того что называют агентами на рынке это просто красивые цепочки в no-code конструкторах Workflow где вы заранее продумали каждый if-else
Это не агенты это детерминированные пайплайны с LLM внутри

Я потратил последние месяцы на то чтобы понять как строить настоящие автономные системы (Запускал демо ERC3, строил решения для демо в agentic comerce)
Результат всей моей работы оказался тут sgr-agent-core фреймворк уже набрал 815 звезд на GitHub и работает в продакшене у реальных клиентов
Но главное не звезды а то понимание физики процесса которое я получил, и это так же ответ зачем было его делать

Generic Agent = Based Prompt + ReAct+PlanAct + Context Engineering + Memory + Tool Search

Это не просто формула это средя для автономности Based Prompt задает законы физики для модели как она должна думать планировать реагировать на ошибки

ReAct это безальтернативный цикл без которого автономности не существует модель должна рассуждать действовать анализировать результат и корректировать план

Context Engineering потому что контекст не резиновый и агент должен уметь управлять своим вниманием сжимать историю отбрасывать неактуальное держать фокус

Memory это не просто кэш это архитектурное решение о том что помнить что забывать когда делать compaction

Tool Search критически важный компонент для энтерпрайза когда у вас 500 плюс API-ручек вы не можете скормить их все в контекст настоящий агент сначала понимает задачу находит нужный инструмент в репозитории и только потом использует

В ближайшие дни у меня будет несколько площадок где я буду давать очень скромный прогноз без хайпа обещаю

Очень хочу показать что курсы по AI-агентам дают вам базу с langchain или n8n и обещают что теперь вы зарабатываете 300к в наносекунду но они не расскажут про управление форматом и структурами внутри tools про constraint и args про то как на самом деле работает structured output (пришлите в коменты если такой курс есть) как управлять ризонингом в агентах и как его вызывать самому (наш тул reasoning+plan)

Must Read от создателей LLM

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

OpenAI A Practical Guide to Building Agents

OpenAI Building Agents Track

Anthropic Building Effective Agents

Anthropic Context Engineering

Anthropic Building Agents with Claude Agent SDK

Все они говорят +- одно начинайте с простого не тащите сразу LangGraph на 20 нод сделайте одного агента с одним инструментом заставьте работать потом масштабируйте

Я строю агентов на локальных моделях и как оказалось что бы строить generic agent нужно мощное железо 🗿
Это не потому что я против OpenAI это потому что я хочу полный контроль над инференсом над латенси над стоимостью
Когда ты делаешь продакшен на локальных моделях ты понимаешь каждый байт контекста каждый вызов инструмента каждую миллисекунду задержки
Это сделать тебя лучшим инженером над API вызовами

По этому далее будет усиление на контент именно про них, про агентов, и про sgr-agent-core будем выводить фреймворк на 10к звезд!
Если ты со мной ставь 🖥 Linux =)


Stay tuned!

🌟NSM, пирамида и дерево метрик: три всадника продуктовой аналитики

Собрала вам базу по основным понятиям.
В pdf краткий конспект для ленивых энергосберегающих 🔋.
Кстати, тут pdf с диагностикой отрицательного роста.

❓Какие бывают метрики:
https://gopractice.ru/product/added_value_metrics/ - метрики продукта, роста, эффективности и добавочной ценности
https://amplitude.com/books/north-star/the-north-star-checklist - North Star Metric чек-лист

➡️Иерархия метрик:
https://www.youtube.com/watch?v=DgvUq4D0IUQ - лекция ШМЯ
https://www.youtube.com/watch?v=xh0GTIkYhOw - Денис Теплов из Лиги Ставок про фейлы с NSM. Очень классное выступление!
https://www.youtube.com/watch?v=0KColE4-MdY&t - Глеб Кудрявцев онлайн без регистрации и смс строит дерево метрик
https://library.wannabe.ru/article/kak-postroit-ierarhiyu-metrik-i-ispolzovat-ee-v-rabote

🔼Пирамида метрик:
больше материала найдете в канале Лены Серегиной
https://www.youtube.com/watch?v=7wTO1GonUj4&t=53s - краткое пояснение за разницу между иерархией и пирамидой
https://master-strategy.ru/tpost/nrpt840r71-kak-sdelat-put-razvitiya-kompanii-produk
https://www.agima.ru/blog/analytics/piramida-metrik-pozhaluy-luchshiy-sposob-ponyat-chto-ne-tak-s-vashim-produktom/ - пирамида метрик как способ понять, что не так с продуктом

📱 канал AI Engineer

В посте выше я ссылался на доклад с AIE митапа. Так вот, у них есть болшой YT канал с очень годным контентом от передовых лаб и AI стартапов.

Канал тут.

Выступления все в среднем по 20 минут и крайне прикладные. Тут вы никогда не увидите формул, глубоких деталей методов или какие-то строгие специфичные eval-ы. Но можно зацепить много идей, посмотреть что делают в индустрии, набраться ключевых слов и ссылок и потом пойти копать дальше.

Большой дисклеймер: Да, крутого контента много, но еще больше бесполезного маркетингового мусора, которое слово в слово дублирует какой-нибудь релиз. Благо, видео короткие, можно быстро отсеять.

Мне, например, очень понравились доклады про разный RL, многие совсем свежие:

1. OpenAI про Agent RL, во второй части доклада рассказывают про пилоты с реальными кастомерами
2. Про эффективный RL, где боттленеки обучения, где простаивают GPU
3. про обучение своих агентов с помощью RL, вот тут вообще кайфовый case study от сбора данных до reward-hacking-ов

Happy Learning!

—
кстати, митапы проходят не только в SF, но и в других локациях. В этом году состоялся первый в Париже и несколько прошло в Лондоне. Здесь все скромнее по масштабу, но все равно очень интересно. Запланировал выступить в следующем году на таком.

#образование

ClearML Agent: обучение модели в Google Colab

Продолжаем обзор MLOps-экосистемы ClearML, которая покрывает полный цикл разработки и выкатки ML-моделей. Ранее мы разобрали, как работают компоненты ClearML Data и ClearML Session.
А в новой статье рассказали о ClearML Agent — компоненте, который позволяет отправлять задачи в очередь и исполнять их на удалённых машинах. 📡

Из статьи вы узнаете:
- как работает ClearML Agent
- как использовать Google Colab в качестве воркера для ClearML 🍯
- и как можно добавлять задачи в очередь для ClearML Agent

Читайте новую статью по ссылке!👈

🪔 DeepSchool