Короткие разборы задач, на которых я застревал. Пишу, чтобы не забыть, и выкладываю, чтобы кто-то не терял на них вечер. https://kietos.me/feed.xml 2026-05-26T00:00:00Z Бехруз Авезматовbehruzavezmatov@gmail.com https://kietos.me/note.html?id=mask-before-model 2026-05-26T00:00:00Z

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

<p>Задача звучала просто: разбирать рабочие сообщения языковой моделью, но так, чтобы имена, телефоны и номера договоров не утекали наружу.</p> <p>Первая мысль была неправильная, и неправильная поучительно.</p> <h2>Как хотелось сделать</h2> <p>Отправить текст модели, получить ответ, вычистить из ответа персональные данные. Схема выглядит рабочей ровно до вопроса: а что уже произошло с исходным текстом?</p> <p>Он ушёл. Дальше можно чистить что угодно — данные уже вне контура. Если модель внешняя, они в чужих логах; если внутренняя, но с сетью — потенциально там же.</p> <h2>Как надо</h2> <p>Маскирование идёт первым:</p> <pre class="md-code"><code>сообщение → Presidio → [ИМЯ_1], [ТЕЛЕФОН_1] → модель → ответ → обратная подстановка</code></pre> <p>Модель физически не видит настоящих значений. Она работает с метками, и это не мешает ей понимать смысл: «свяжитесь с [ИМЯ_1] по [ТЕЛЕФОН_1]» разбирается не хуже оригинала.</p> <h2>Что из этого следует для архитектуры</h2> <p>Раз маскирование обязано случиться до обращения к модели, оно не может быть «фильтром на выходе» — его место в конвейере, до самого дорогого шага. У меня получилось так:</p> <ul><li><strong>шлюз</strong> принимает сообщение и кладёт в очередь;</li><li><strong>воркер</strong> достаёт, маскирует, зовёт локальную модель;</li><li><strong>обратная подстановка</strong> возвращает значения уже в готовый ответ.</li></ul> <p>Шлюз и воркер пришлось разделить: разбор идёт секунды, и держать на нём HTTP-соединение — значит упереться в таймауты на первом же десятке запросов.</p> <h2>Проверка, которая ловит регресс</h2> <p>Логи воркера пишут текст на каждом шаге. Если однажды кто-то поменяет порядок и маскирование съедет за вызов модели, это видно сразу — в логе будет настоящий телефон там, где должна быть метка.</p> https://kietos.me/note.html?id=why-hough-misses-bubbles 2026-05-04T00:00:00Z

HoughCircles на видео с пузырьками промахивается на восьми записях из десяти. Причина в том, что подаётся ему на вход.

<p>Пузырёк — это круг. Значит, находим круги. Так я думал первые полдня.</p> <p>На картинке из учебника HoughCircles находит круги. На настоящей записи он либо не видит ничего, либо видит сотни кругов там, где их нет, и настройка порогов из этого не выводит.</p> <h2>В чём подвох</h2> <p>Детектор ищет края. А края на реальном кадре сломаны сразу по трём причинам:</p> <ul><li><strong>освещение неравномерное</strong> — один угол кадра ярче другого, и порог, подходящий слева, съедает всё справа;</li><li><strong>пузырьки полупрозрачные</strong> — граница размытая, перепад яркости слабый;</li><li><strong>пузырьки мелкие</strong> — на них приходится десяток пикселей, и шум сопоставим с сигналом.</li></ul> <p>Крутить параметры детектора здесь бесполезно: он делает свою работу правильно, ему просто дают негодную картинку.</p> <h2>Что помогло</h2> <p>Кадр важнее детектора. Две операции перед ним делают больше, чем любые пороги.</p> <p><strong>CLAHE</strong> — выравнивание контраста по локальным участкам, а не по всему кадру целиком. Тёмный угол становится сопоставим со светлым, и один порог начинает работать везде.</p> <pre class="md-code" data-lang="python"><code>clahe = cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8, 8)) gray = clahe.apply(gray)</code></pre> <p><strong>Top-Hat</strong> — морфологическая операция: из картинки вычитается её же «открытие». Остаётся то, что мельче структурного элемента и ярче фона. То есть ровно наши пузырьки, без крупного фона и градиентов.</p> <pre class="md-code" data-lang="python"><code>kernel = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (15, 15)) gray = cv2.morphologyEx(gray, cv2.MORPH_TOPHAT, kernel)</code></pre> <h2>Вывод, который пригодился дальше</h2> <p>Алгоритм «не работает» — смотри на его вход. У меня из этого выросла привычка выводить промежуточную картинку после каждой ступени: видно, на какой из них всё разваливается.</p> https://kietos.me/note.html?id=transfer-race 2026-02-10T00:00:00Z

Проверил баланс, списал, зачислил. Между первым и вторым шагом помещается второй запрос, и баланс уходит в минус.

<p>Учебная платёжная система, перевод между счетами. Код читается как условие задачи:</p> <pre class="md-code" data-lang="python"><code>if account.balance &gt;= amount: account.balance -= amount target.balance += amount</code></pre> <p>Работает, пока запрос один.</p> <h2>Где ломается</h2> <p>Два перевода приходят одновременно. Оба читают баланс — у обоих проверка проходит. Оба списывают. Баланс уходит в минус на сумму второго перевода.</p> <p>Воспроизвести легко: два запроса в цикле, и через несколько итераций видно отрицательное число там, где его быть не может.</p> <h2>Что не помогает</h2> <ul><li><strong>Проверка после списания.</strong> Уменьшает окно, но не закрывает: гонка случается реже и потому всплывает уже в бою.</li><li><strong>Блокировка в приложении.</strong> Работает ровно до второго процесса. А второй процесс появляется в тот день, когда сервис ставят за балансировщик.</li></ul> <h2>Что помогает</h2> <p>Пусть решает база — она умеет. Строка блокируется на время транзакции:</p> <pre class="md-code" data-lang="sql"><code>SELECT balance FROM accounts WHERE id = :id FOR UPDATE;</code></pre> <p>Второй запрос ждёт на этой строке, пока первый не завершится, и читает уже новое значение. Плюс ограничение в схеме — как последний рубеж:</p> <pre class="md-code" data-lang="sql"><code>ALTER TABLE accounts ADD CONSTRAINT balance_non_negative CHECK (balance &gt;= 0);</code></pre> <p>Проверка в коде остаётся: она даёт человеку понятную ошибку вместо исключения базы. Но полагаться на неё одну нельзя — это подсказка, а не гарантия.</p> <h2>Что я из этого забрал</h2> <p>Правило, которое с тех пор проверяю первым: если между чтением и записью помещается чужой запрос — значит, однажды он туда поместится.</p>