Полный разбор для банковского сценария «обработка документов»: паспорт, выписка, заявка. Это твой честный пробел — покажи, как ты проектируешь то, чего не деплоил.
Что говорит кандидат:
«Уточню до архитектуры. Какие типы документов и какие поля критичны? Это сканы/фото или нативные PDF? Есть ли требования по скорости — синхронно при загрузке или фоновая очередь? Какая точность нужна и что с полями, где машина сомневается — HITL? Куда идут данные после извлечения — в CRM, в заявку? И какой допустим false-accept на сумме: лучше переспросить человека, чем записать неверную сумму».
Почему это сильно: ты сразу показал, что думаешь о типах входа (скан vs PDF — разные пайплайны), о синхронности, о HITL и о cost-of-error (false-accept на деньгах).
Вопрос: «Ты же сказал, что OCR не деплоил. Как спроектируешь то, чего не знаешь?»
Ответ (честно, без защиты): «Верно, промышленный OCR не запускал. Но пайплайн „тип → качество → извлечение → валидация → HITL" — это стандартная архитектура обработки документов, и я её спроектирую, а точность проверим на ваших данных: field-level F1, exact match на деньгах, false-accept rate. Я не буду утверждать, что знаю, какая модель OCR победит, — это решает eval на вашей выборке».
Почему это правильный ответ: не прячешь пробел, показываешь процесс и метрики. Это из твоей таблицы «честные пробелы».
Что говорит кандидат:
«Offline: field-level F1 по полям (сумма, дата, имя, номер), exact match на деньгах, false-accept rate (записали неверную сумму как верную — худшая ошибка), % straight-through без человека. Online: доля документов, обработанных без HITL, время до результата, очередь не растёт. HITL-точность: когда человек правит поле — сколько раз машина ошиблась».
Вопрос: «Почему exact match на деньгах, а не F1?»
Ответ: «F1 по полям — общая картина, но для суммы важна абсолютная точность: 1234.56 vs 1234.65 — это деньги. Exact match на деньгах жёстче и ловит то, что средний F1 сглаживает. Плюс false-accept: если модель уверенно записала неверную сумму — это хуже, чем попросить человека перепроверить».
Что говорит кандидат:
«50k загрузок/мес ≈ 1700/день ≈ пик 3–5 документов/сек. Средний документ: 1–3 МБ, обработка 2–5 секунд на GPU-OCR. Пик — это фоновая очередь, не синхронный ответ. Хранилище: объектное (S3), метаданные полей — в БД».
Что рисует кандидат:
Загрузка → объектное хранилище (S3) → очередь (job_id)
→ воркеры:
тип документа (классификатор)
→ quality check (blur/rotate/exposure) → плохо → «переснимите»
→ OCR (текст) + layout (поля)
→ extract полей (LLM или NER, T=0)
→ cross-page + сверка с заявкой
→ confidence score
→ выше порога → structured store (БД) → «готово»
→ ниже порога → HITL (человек правит) → store
→ лог: job_id, doc_type, conf, latency, queue_ageКлючевые решения:
Вопрос: «Почему LLM для извлечения полей, а не классический NER?»
Ответ: «LLM лучше понимает layout и контекст („сумма к оплате" vs „сумма прописью"), но может выдумать. Поэтому: T=0, схема выхода Pydantic/JSON, и сверка — цифра из поля должна совпадать с распознанной. Для стабильных полей с большим объёмом данных — NER/fine-tune дешевле и быстрее; выбор решает eval. После OCR это тот же entity-linking, что schema linking в Text-to-SQL — у меня есть опыт там».
Вопрос: «Что если OCR вернёт мусор вместо текста?»
Ответ: «Quality check перед OCR ловит кривизну/размытие. После OCR — минимальный порог текста (пусто/каша → „нечитаемо, переснимите"). И confidence на уровне полей: если сумма не извлеклась уверенно — HITL, не догадка».
Что говорит кандидат:
«Копну в точность. Field-level F1 по каждому полю отдельно — не средний балл: сумма и имя имеют разные пороги. False-accept rate — отдельно, это худшая ошибка. Порог HITL настраиваю по кривой: сколько процентов документов уходит человеку при данном пороге vs сколько ошибок ловим. Дальше — data flywheel: ошибки HITL (что человек поправил) возвращаются в датасет, переобучаем/правим промпт, точность растёт. Для оценки судьи — те же TPR/TNR на holdout».
Вопрос: «Какой % straight-through приемлем?»
Ответ: «Зависит от цены ошибки. Для паспорта (стабильные поля) цель 90%+ straight-through. Для финансовых документов (сумма, подпись) — 70–80%, потому что ошибка дороже человеко-часа. Порог — это бизнес-решение: сравниваем стоимость HITL с ценой false-accept. Я дам кривую „straight-through vs false-accept" и решение примем по ней».
Что говорит кандидат:
«Кривой скан → quality check, „переснимите". Другой тип документа, чем ожидал → классификатор + fallback. PII в документе (паспорт!) → маскировка в логах, никаких копий в открытом виде. Воркер упал на середине → очередь + идемпотентность (job не выполнится дважды). Очередь растёт → автоскейлинг воркеров + алерт. LLM выдумал поле → T=0 + сверка + confidence + HITL».
Что говорит кандидат:
«v0: очередь + OCR + LLM-экстракция + порог + HITL. v1: fine-tune на накопленных парах (если формат стабилен), vote двух моделей на сумме, документы из RAG по полям. Сознательно не беру: полную автоматизацию без HITL на деньгах, обработку подписей/печатей без отдельного проекта».
Вопрос: «С чего начнёшь?»
Ответ: «Соберу 200–500 реальных документов с полями, размечу 50–100 (benevolent dictator — я/домен-эксперт), прогоню 2–3 OCR + 2 промпта экстракции, посчитаю field-level F1 и false-accept. По кривой порога решу, где HITL. Очередь и схему — параллельно, они от точности не зависят».
| Критерий | Ты показал |
|---|---|
| Честность про пробел | «OCR не деплоил» + процесс и метрики вместо блефа |
| Очередь/асинхронность | job_id, воркеры, идемпотентность |
| Cost-of-error | false-accept на деньгах, HITL по порогу |
| Data flywheel | ошибки HITL → датасет → улучшение |
| Связка с опытом | entity-linking = schema linking из Text-to-SQL |