Григорий Добряков

Howto-серия

Инженерные разборы

Показываю, как это устроено

Формат: задача из практики → как к ней подошёл → репозиторий или видеообозначение рисков и границ применимости. Разборы, которые можно изучить, перенести в ваш контур и адаптировать под свои задачи.

В каждом howto явно обозначаю зону применимости: где решение слабеет, при каких условиях его нельзя тиражировать, что может пойти не так. Конкретные сценарии отказа и принятые trade-off'ы.

03

Retrieval-слой под book-as-context

Vector-only теряет термины, которых нет в embedding. Retrieval с тремя режимами под book-as-context: у каждого чанка виден источник, агент может сказать, зачем взял именно его.

CTO Head of AI Architect Tech Lead
Читать разбор →
04 GitHub · ★8 / 4 forks

Async MCP server с job queue

Наивный MCP-сервер блокируется на долгих операциях. Async job queue: submit → poll, и 404-after-completion как сознательный stateless-trade-off.

CTO Head of AI Architect Tech Lead
Читать разбор →
07 GitHub · ★2

Cursor rules как governance

Как держать планку при массовом AI-кодинге: конвенции в toolchain, с которым работают каждый день — версионируемые Cursor rules в репозитории.

CTO Head of AI Tech Lead Architect
Читать разбор →
10

Eval как release-критерий

Eval зелёный, прод красный — часто потому что гоняли те же входы, что на демо. Release gate из трёх слоёв: regression по инцидентам, distribution diff к снапшоту, spot-check людьми до деплоя.

CTO Head of AI Tech Lead
Читать разбор →

Нужна такая инженерная планка в вашей команде?

Архитектурные разборы, AI-assisted разработка с governance, практики так, чтобы результат держался на процессе, а не на одном удачном промпте и героизме в review.

Написать на почту

Формат серии

  • • Задача из практики, не из учебника
  • • Репозиторий или видео — можно потрогать
  • • Методику можно унести в свой стек
  • • Риски и границы применимости — без приукрашивания