HackerNoon Weekly Digest

Десять статей из 55, попавших в окно. Отбор жёсткий: остались только те, где есть переносимый приём и понятно, что делать руками.

Один gate вместо трёх списков команд: репозиторий, в котором агент не спорит с CI

✍ Médéric Hurier (Fmind) HackerNoon 13 авг ai-coding-agents ai-agent-tooling git

О чём

Автор перебрал четыре репозитория MLOps Coding Course специально под работу AI-агентов: удалил больше 900 строк конфигов и glue-кода, а статических проверок стало вдвое больше, с четырёх до восьми, и покрытие тестами вышло на 100%. Полезно, если агент у вас уже коммитит: он читает репозиторий целиком и запускает команды неинтерактивно, поэтому любое расхождение между локальными хуками, CI и инструкциями превращается в круги «локально зелено, в CI красно».

🔑 Главное

Дублирование команд — главный источник путаницы. В аудите нашли, что второстепенные списки в CI потеряли mise run build, а bake-тест Cookiecutter выполнял все сгенерированные задачи, кроме pytest: шаблон уезжал с CI, который ни разу не прогнал собственные тесты.
Лечится одним именованным gate: задача mise run all (format → check → test → build), которую вызывают git-хуки на lefthook, GitHub Actions и AGENTS.md. Список шагов может потерять шаг, именованный gate — нет. CI дополнительно проверяет, что рабочее дерево осталось байт-чистым.
Проза не исполняется: семь вендоренных agent skill-файлов разъехались с апстримом на 183 строки, один всё ещё учил агентов запускать just и pre-commit, удалённые из репозитория месяцами раньше. AGENTS.md задаёт намерение, корректность держат типы, тесты и линтеры.
Состояние БД в тестах: переход MlflowService на sqlite:///mlflow.db с миграциями для каждого изолированного теста раздул прогон с 34 до 339 секунд. Session-scoped шаблон БД плюс файловое копирование срезали накладные расходы примерно на 60% и оставили тесты на настоящей схеме.
Через месяц после тега v5.0.0 связка trivy и govulncheck показала 25 уязвимостей в транзитивных зависимостях MLflow. Вместо подавления сканера — явный override-dependencies = ["cryptography>=50"] в pyproject.toml, проверенный в обе стороны: с override прогон и деплой зелёные, без него аудит обязан падать.

⚡ Попробовать за вечер

Свести все проверки в одну задачу-gate (mise run all, just all или цель в Makefile) и переписать хуки, workflow в CI и AGENTS.md так, чтобы они вызывали именно её.
Добавить проверку, что каждая команда, путь и версия инструмента, упомянутые в AGENTS.md и в agent-skills, существуют в репозитории; вендоренные копии удалить в пользу ссылок на источник.
Если тесты трогают локальную БД, прогнать миграции один раз в session-scoped фикстуру и копировать готовый файл в tmp-каталог для каждого теста.
Метрика: длительность полного gate и доля агентских попыток, проходящих его с первого раза. У автора полный прогон занимает 1,5–3,5 минуты на восьми сканерах, поэтому быстрые линтеры живут в pre-commit, а полные — в pre-push и CI.

🔗 Read on HackerNoon Стандарт AGENTS.md

GraphRAG или обычный RAG: тест на окупаемость графа

✍ superorange0707 HackerNoon 13 авг graphrag rag knowledge-graph

О чём

Разбор с обратной логикой: сначала классифицируем вопросы, потом выбираем архитектуру поиска. Автор даёт четыре класса вопросов, список того, что покупаешь вместе с графом, и метрики для честного сравнения plain RAG, Local, Global и DRIFT-поиска. Пригодится, когда команда просит «давайте граф», а вы отвечаете за счёт за индексацию.

🔑 Главное

Четыре класса вопросов: точечный lookup, окружение сущности, многошаговая связь, синтез по всему корпусу. Первый обычно выигрывают keyword-, metadata- и вектор-поиск, последний — Global Search по community-отчётам, который сама документация Microsoft называет ресурсоёмким.
Граф — это производный индекс, и он не становится истиной автоматически. Извлечение сущностей плодит алиасы и склейки, извлечение связей выдумывает или теряет рёбра, генерация отчётов упаковывает неопределённость в уверенную прозу. Ссылки на источник нужны на узлах, рёбрах, claim-ах и отчётах, а качество построения графа надо оценивать отдельно от качества ответов.
Считать надо полную стоимость индексации: вызовы модели на извлечение и суммаризацию, эмбеддинги, retries и кеш, entity resolution, ревью экспертами, переиндексация после смены промптов, миграции между версиями, распространение прав, эксплуатация. Делить её нужно на успешные ответы, которые выиграли от графа, а не на все вопросы: если 95% трафика — точечные lookup, а выигрывают 5%, в граф маршрутизируют только эти 5%.
Две шкалы свежести живут отдельно: у источника и у производного графа. Ответ должен раскрывать, каким снапшотом он пользовался; фраза «граф говорит» не годится, когда граф отстал на дни.
Права сложнее поиска. Community-отчёт, собранный из документов A, B и C, утечёт содержимое, даже если финальный запрос фильтрует чанки. Если модель безопасности не может объяснить, кому можно видеть сгенерированный отчёт, граф не готов к чувствительным данным. И hybrid — это маршрутизация, а не склейка результатов всех retriever-ов в каждом запросе.

⚡ Попробовать за вечер

Собрать 30–50 реальных вопросов из логов, разметить их по четырём классам и посчитать доли. Это и есть первый вход в расчёт окупаемости.
Поднять сильный baseline на plain RAG и сравнить с Local, Global и ограниченным DRIFT на одних и тех же парных вопросах, включив в стоимость индексацию и эксплуатацию.
Написать роутер на детерминированных признаках плюс маленький классификатор и логировать выбранный путь, чтобы потом считать ошибки маршрутизации.
Метрика: стоимость одного успешного ответа по классам вопросов, доля ошибок маршрутизации и unsupported-claim rate. В набор обязательно включить случаи, где правильный ответ — «данных нет».

🔗 Read on HackerNoon

RAG над своими текстами: локальные эмбеддинги против фронтир-модели

✍ Vanna W HackerNoon 14 авг rag-tutorial ai-engineering

О чём

Честный build-log: Q&A по собственным публикациям на четырёх площадках, с решениями по схеме, чанкингу и эмбеддингам в том порядке, в котором их приходилось принимать. Автор сразу оговаривает, что Python писал Claude Code под её управлением, а архитектура и решения по retrieval — её. Ценность для инженера в том, что главный риск проверен экспериментом, а не декларацией.

🔑 Главное

Дедупликация корпуса оказалась важнее хитрого чанкинга. HackerNoon переименовывает статьи под свои гайдлайны, поэтому наивная индексация блога и площадки дала бы конкурирующие почти-дубли под разными заголовками. Решение: один канонический документ, остальные площадки — метаданные в platform_urls и syndicated_titles. Маппинг заголовков взят из своего экспорта статистики, каждый URL проверен по живой странице.
Чанкинг по абзацам, всё короче 200 символов сливается с соседом: 16 постов дали 392 чанка, примерно 24 на пост. Умный чанкинг отложен до момента, когда заработает сквозной цикл.
Локальные эмбеддинги выбраны по расчёту: all-MiniLM-L6-v2, 384 числа на чанк, разовая загрузка около 90 МБ, дальше без ключей и оплаты за запрос. На корпусе примерно из сорока документов хостинговый API решает задачу другого масштаба.
Порога отсечения по расстоянию нет сознательно: на сорока документах нет разметки, чтобы его калибровать, и хардкод стал бы догадкой в костюме числа. Вместо него инструкция в промпте — сказать, если ответа в выданных отрывках нет.
Три вопроса прогнали через Claude и через локальную Llama 3.1 в Ollama. На вопросе-обманке про квантовые вычисления обе модели корректно отказались и ни одна не выдумала связь, формат цитирования соблюдали обе. Разошлись в глубине: Claude цитировал исходный текст и подтянул лишнее эссе в вопросе на синтез. Три вопроса через API Claude стоили девять центов.

⚡ Попробовать за вечер

Проиндексировать свой корпус (заметки, статьи, внутреннюю вики) по той же схеме: канонический документ, словарь URL-ов площадок, чанки по абзацам с порогом 200 символов.
Поднять all-MiniLM-L6-v2 локально и прогнать один и тот же набор вопросов через API-модель и через локальную в ollama.
Обязательно вставить в набор вопрос-обманку, которой в корпусе нет, и потребовать в промпте признавать отсутствие ответа.
Метрика: на вопросах-обманках — доля честных отказов и число процитированных источников. Если система придумала связь, тюнить размер чанка бессмысленно: ломается доверие, а не качество.

🔗 Read on HackerNoon Репозиторий

Ёмкость LLM-платформы: шесть единиц вместо одного QPS

✍ superorange0707 HackerNoon 12 авг ai-infrastructure gpu observability

О чём

Требование «платформа должна держать 100 000 QPS» на практике скрывает пять разных нагрузок в одном плаще. Статья предлагает другую модель единиц: воронка от живых соединений до токенов и tool-операций, TTFT как бюджет из слагаемых, отдельный SLO на темп генерации и admission control вместо надежды. Прикладной текст для тех, кто подписывает SLO и закупает GPU.

🔑 Главное

Воронка: живые соединения → запросы на ingress → прогоны оркестрации → вызовы модели → входные и выходные токены → операции retrieval и инструментов. На каждой стрелке работа множится, гасится, кешируется или задерживается, поэтому для каждой стадии нужны arrival rate, service time, concurrency, глубина очереди, доля ретраев и fan-out.
Нагрузку на модель создают токены, а не запросы: prefill обрабатывает контекст, decode рождает токены по одному, и грузят они железо по-разному. Планировать по средним нельзя — нужны бакеты длин (до 2K, 2K–8K, 8K–32K, свыше 32K), доля кеш-хитов по входу и KV-байты на последовательность.
TTFT — это бюджет: gateway и аутентификация, retrieval и reranking, сборка контекста, оркестрация, очередь планировщика, prefill, передача KV, доставка по сети. Дашборд с одной «latency модели» уводит починку не туда: в работе июля 2026 про load-aware prefill deflection сам prefill занимал малую долю p95 TTFT, остальное съели очередь и передача между узлами.
Скрытые очереди живут вне GPU: retrieval, workflow с чекпойнтами, инструменты со своими rate limit и человек с апрувом, который держит состояние минуты и дни. Система с низкой утилизацией GPU может быть перегружена по воркерам, соединениям и бюджетам зависимостей.
Admission controller решает, что делать на перегрузке. На входе оцениваются ожидаемые токены, fan-out retrieval, максимум шагов модели и tool-вызовов, память и KV, приоритет тенанта, дедлайн. Дальше один из явных исходов: впустить как есть, увести на меньшую модель, урезать retrieval, отдать кеш или детерминированный ответ, поставить в очередь с честной оценкой, отказать с контрактом на retry. Ретраи тратят тот же бюджет: один дедлайн и журнал попыток на запрос.

⚡ Попробовать за вечер

Нарисовать свою воронку из шести единиц и посчитать коэффициент усиления на каждой стадии на реальном пике.
Разложить p95 TTFT по слагаемым в рамках одного trace id и найти очередь, которая доминирует.
Прогнать нагрузочный тест матрицей: бакеты входа и выхода, кеш-хиты и промахи, fan-out retrieval, streaming и не-streaming, короткие и длинные агентские прогоны, тёплые и холодные модели, деградация зависимостей.
Метрика: стоимость одного успешного таска вместо стоимости вызова модели, плюс доля отказов, возраст очереди и p99 по каждой стадии. Рядом фиксируются условия: версия модели, тип GPU, параллелизм, квантование, распределение длин, конфиг планировщика.

🔗 Read on HackerNoon

Память агента по правилам операционных систем: scope, decay, provenance

✍ ezekiel HackerNoon 11 авг ai-memory memory-management system-design

О чём

Автор ведёт несколько клиентов и каждый раз объясняет модели одно и то же. Его диагноз: продукты умеют персистентность, но не умеют политику — что хранить, на каком уровне, как долго и зачем. Дальше он переносит на память агента механики ОС: сборку мусора, вытеснение по LRU и LFU, компактизацию и namespacing. Готовый чек-лист для тех, кто проектирует стор памяти.

🔑 Главное

Три уровня вместо одного: global (стиль письма, таймзона, инструменты по умолчанию), contextual (голос бренда клиента, открытые решения проекта) и ephemeral (черновик, время встречи — умирают вместе с сессией). Плоская память не применяет вообще никаких правил хранения, а контекст клиента лежит рядом с постоянными фактами о пользователе.
Decay по релевантности, а не по таймеру. «Предпочитает формальный тон» живёт годами, «в следующем месяце едет в Японию» перестаёт значить что-то через недели. Отсутствие обращений — сигнал: запись не удаляют сразу, а понижают уверенность, с которой её используют.
У каждой записи тег происхождения: observed (сказал сам), inferred (система вывела из поведения), confirmed (пользователь подтвердил вывод). Долговечными делают только confirmed, а перед важным ответом вывод проверяют у пользователя. Один вопрос про Python не делает пользователя питонистом.
Замена вместо накопления: у атрибутов идентичности одно текущее значение, история версий живёт в фоне для аудита. Это аналог компактизации памяти — противоречия сводятся к одному актуальному представлению.
Retention оправдывается извлечением: запись, которая давно ни на один ответ не повлияла, теряет право на место. И всё это работает только при временном рассуждении: получить дату в контексте и уметь про неё думать — разные способности, а без надёжного «сейчас» и decay, и provenance бессмысленны.

⚡ Попробовать за вечер

Разложить текущий стор памяти агента на три scope и запретить contextual-записям утекать между проектами и тенантами.
Добавить в схему поля origin (observed / inferred / confirmed), last_reinforced_at и confidence; понижать confidence у записей без подкреплений.
Ввести правило замены для атрибутов идентичности: текущее значение одно, предыдущие уходят в теневую историю.
Метрика: сколько записей за неделю реально попали в ответ хотя бы один раз, и сколько осталось случаев «подставил устаревший контекст» после включения decay.

🔗 Read on HackerNoon

Агент дороже ошибается: outbox, inbox и идемпотентность вокруг tool-вызовов

✍ Admilson Cossa HackerNoon 11 авг distributed-systems software-architecture fintech

О чём

Большой разбор dual-write и доставки at-least-once в мире, где событие поднимает не проекцию, а агента: тот назначит проверку на фрод, поставит платёж на удержание, инициирует возврат или дёрнет внешний финансовый API. Ядро текста — граница между рассуждением и исполнением плюс конкретные паттерны с SQL и схемой конверта события. Читать, если ваши агенты уже вызывают инструменты с побочными эффектами.

🔑 Главное

Брокер не решает dual-write. Атомарности между БД и брокером нет, отсюда три состояния: состояние записано, а событие не ушло; событие ушло, а транзакция откатилась; брокер принял, ACK потерялся, producer повторил. Kafka, Redpanda, RabbitMQ и NATS JetStream решают разные задачи и ни один не убирает эту границу.
Transactional Outbox фиксирует рождение события: UPDATE состояния и INSERT в outbox в одной локальной транзакции, после чего публикация становится восстановимым асинхронным процессом, а не второй точкой отказа.
Outbox не даёт exactly-once. Рабочий инвариант звучит так: записать атомарно один раз, доставить хотя бы один раз, применить эффект один раз. Inbox с уникальным eventId, записанным до применения эффекта, гасит повторы локально, а последний хоп во внешнюю систему требует своего ключа идемпотентности или сверки. Таймаут означает UNKNOWN, а не FAILED.
Порядок — свойство бизнеса, а не маркетинговая фича брокера. Последовательность v17 → v19 → v18 даёт невалидное состояние, поэтому в конверте нужен aggregateVersion, чтобы консьюмер видел устаревшие события, дубликаты и разрывы. Рядом с ним eventId, correlationId и causationId — они становятся обязательными, как только в поток входит агент.
Граница ответственности: AI рекомендует, политики решают, системы исполняют. Агент анализирует и предлагает, детерминированный сервис проверяет лимиты, права и разделение обязанностей, идемпотентный исполнитель делает внешний эффект. Вывод модели — доказательство в решении, а не источник финансовой истины. Наблюдаемость при этом мерит корректность: лаг CDC и публикации, redelivery, конфликты inbox, разрывы последовательности, рост DLQ, расхождения сверки. Самое опасное состояние не service = DOWN, а payment = UNKNOWN.

⚡ Попробовать за вечер

Завести таблицу outbox и переписать один сценарий с побочным эффектом на схему «одна транзакция: состояние плюс событие», а публикацию вынести в релей или CDC.
Добавить в конверт событий eventId, aggregateVersion, correlationId, causationId и завести inbox-таблицу на стороне консьюмера, который дёргает агента.
Вынести решение из агента в детерминированный policy-сервис: агент отдаёт рекомендацию с доказательствами, политика проверяет лимиты и права, исполнитель работает по ключу идемпотентности.
Метрика: число задвоенных бизнес-эффектов и операций в состоянии UNKNOWN за неделю, плюс доля событий, отклонённых inbox как повторные.

🔗 Read on HackerNoon

Спекулятивный декодинг: почему tok/s без распределения задач ничего не значит

✍ Michał Piszczek HackerNoon 13 авг long-context-llm performance machine-learning

О чём

Ночь тюнинга: dense-модель на 30B, контекст 262 144 токена, vision-проектор и DFlash-драфтер на одной 24-гигабайтной карте с лимитом 70 ватт. Один и тот же сетап выдаёт 84,64 tok/s на коде, 38,34 на смешанной агентской работе и 21,56 при заполненном KV-кеше. Полезно всем, кто выбирает квант и драфтер для локального агента по чужим скриншотам с tok/s.

🔑 Главное

Спекулятивный декодинг не делает проход target-модели дешевле, он покупает несколько токенов за один проход. Драфтер из пяти слоёв получает признаки target-модели со слоёв 1, 13, 25, 37 и 49, предлагает блок (n_max=15), target проверяет, и принятый префикс обрывается на первом несовпадении.
Acceptance rate выбирает не ту конфигурацию: draft 4 дал 47,46% принятых и 34,50 tok/s, draft 15 — 17,99% и 47,20 tok/s. Смотреть надо на среднюю длину принятого префикса τ (на кодовом прогоне 6,39) — это и есть ответ на вопрос, сколько токенов купила одна дорогая проверка.
Узкое место оказалось на границе устройств: greedy-выбор draft-токена уходил на CPU и сериализовал самый горячий цикл. Перенос argmax в граф бэкенда (PR llama.cpp #26842) поднял смешанную серию с 36,30 до 38,34 tok/s, а в финальной кодовой конфигурации против 17,98 tok/s без спекуляции получилось 80,87.
Самый быстрый квант проиграл: гибрид NVFP4 и Q4 выдал 94,36 tok/s, но perplexity 5,6493 против 5,5420 у Q5_K_M — отклонён по качеству. С другого края Q5_K_XL улучшил perplexity на 0,26% (внутри погрешности ±0,1179) и стоил около 13% скорости. Метка кванта не описывает модель: важно, каким тензорам достались биты.
Скрытый дефолт сэмплера стоил 8,1%: сервер применял min-p=0.05 поверх заданных temperature, top-p и top-k; с min-p=0 результат вырос с 78,29 до 84,64 tok/s. И контекст не проверен, пока не заполнен: на 262 116 входных токенов VRAM занят на 93,68% (22 920 из 24 467 МиБ), обработка промпта 371,24 tok/s, а decode на дальнем конце кеша падает до 21,56 tok/s.

⚡ Попробовать за вечер

Прогнать свой драфтер отдельно на коде, на планировании и на смешанной агентской нагрузке вместо одного демо-промпта, и записать τ рядом с tok/s.
Проверить в трейсе, что выбор draft-токена не уходит на CPU, и зафиксировать все параметры сэмплера, включая скрытые дефолты вроде min-p.
Заполнить контекст до предела и замерить decode на дальнем конце кеша, а не только факт успешной загрузки с --ctx-size.
Метрика: τ и tok/s отдельно по типам вывода при зафиксированных кванте, сэмплере и позиции в KV-кеше, плюс perplexity рядом со скоростью, чтобы не выбрать быстрый и глупый вариант.

🔗 Read on HackerNoon Патч в llama.cpp

Карта пост-тренинга: reward-модель — это не RL

✍ Pavel Yakovlev HackerNoon 14 авг llm-training fine-tuning-llms rlhf

О чём

Разбор стадий после претрейна без алфавитного супа: где кончается supervised-обучение и начинается RL, чем ORM отличается от PRM, почему все policy-gradient алгоритмы растут из одной формулы и когда вместо reward-модели достаточно проверяльщика. Нужен, если вы собираетесь дотюнивать модель и хотите выбрать стадию, а не собрать все аббревиатуры.

🔑 Главное

Обучение reward-модели — supervised-задача: ни политики, ни роллаутов, ни PPO. Bradley-Terry берёт пары chosen и rejected и учит контрастивным лоссом скаляр с линейной головы над скрытым состоянием последнего токена. Значение имеет только разница оценок, абсолютный уровень не определён, и обучают обычно одну эпоху, чтобы не переобучиться.
ORM и PRM — это другие лоссы, а не варианты RM. ORM даёт per-token BCE по корректности финального ответа и не поймает ошибку в середине рассуждения; PRM размечает шаги (+1, 0, −1) и даёт плотный сигнал вместо разреженного «правильно только в конце».
RL начинается на policy gradient, и вся семья — одна формула с двумя вопросами: как считать advantage и как ограничить шаг. REINFORCE берёт baseline по батчу, RLOO — leave-one-out по группе, PPO добавляет критика с GAE и клиппинг, GRPO выбрасывает критика и нормирует награды внутри группы, GSPO переносит importance ratio на уровень последовательности, CISPO клиппит сами веса и оставляет градиент на всех токенах.
DPO обходит и reward-модель, и RL-цикл: награда зашита в политику через log-ratio к reference, KL фиксируется через β, log-prob-ы reference можно посчитать один раз и закешировать. Автор в продакшене почти всегда начинает с DPO — данные важнее алгоритма, а полный PPO с четырьмя моделями — это отдельная инфраструктура, которую разворачивают, упёршись в потолок офлайн-подхода.
RLVR меняет обученную reward-модель на детерминированный проверяльщик: сошёлся числовой ответ или прошли тесты — награда 1, иначе 0. Алгоритмически это тот же policy gradient, чаще всего GRPO, а KL-штраф в этом режиме нередко выключают совсем.

⚡ Попробовать за вечер

Выписать, какая стадия нужна вашей задаче: нужен формат ответа → SFT, есть пары предпочтений → DPO, результат проверяется программно → RLVR с чекером.
Собрать пары chosen и rejected на своих данных и прогнать DPO в обычном тренировочном стеке, закешировав log-prob-ы reference-модели одним проходом.
Если у задачи есть автоматическая проверка, написать чекер и подменить им reward-модель — обучать отдельный скорер не придётся.
Метрика: win-rate на отложенных парах против SFT-бейзлайна и стоимость прогона. Упёрлись в потолок DPO — это и есть сигнал разворачивать полный RL-цикл.

🔗 Read on HackerNoon

Ревью AI-кода: порог 400 строк и три категории решений для человека

✍ Duy Cao HackerNoon 14 авг ai-code-review human-in-the-loop fintech-startups

О чём

Автор работает с регулируемыми продуктами и разбирает, в какой момент подпись «reviewed» перестаёт что-то значить. Начинает с того, что автоматика хорошо ловит: известные классы уязвимостей, стиль, типовые баги. Дальше — про размер ревью и про решения, которые нельзя отдать модели ни при каком качестве инструмента.

🔑 Главное

Разбор SmartBear по команде Cisco Systems: обнаружение дефектов резко падает после примерно 400 строк в одном ревью. AI-фича легко приезжает одним PR на 600 строк и больше, разработчик пролистывает, видит зелёные тесты и мержит.
Automation bias измерен: в систематическом обзоре 2012 года ошибочным автоматическим советам следовали на 26% чаще среди тех, кто опирался на автоматические рекомендации. При этом 38% разработчиков говорят, что ревью AI-кода требует дополнительных усилий — ровно то состояние, в котором человек проверяет только цвет тестов.
Три категории решений всегда идут к named-ревьюеру: соответствие регуляторному замыслу, а не только работоспособность кода; архитектурные решения с последствиями для комплаенса (изменение логирования или retention выглядит как мелкий рефакторинг, а через месяцы решает, аудируема ли система); и выбор, что эскалировать — какая аномалия важна именно в этом регуляторном контексте.
Проверка на «одолженную ответственность»: до аппрува ревьюер должен сформулировать, как выглядело бы «неправильно». Не может описать failure mode — ставит штамп, а не делает ревью.

⚡ Попробовать за вечер

Поставить в CI предупреждение на размер ревью около 400 строк и научить агента разбивать задачу по этой границе вместо одного PR в конце спринта.
Прописать три категории решений в CODEOWNERS или чек-листе с явным named-ревьюером, а не растворять их в общем ревью.
Добавить в шаблон PR поле «как выглядела бы ошибка в этом изменении», без заполнения которого аппрув не ставится.
Метрика: медианный размер PR и доля мержей, где ревьюер сформулировал ожидаемый failure mode до аппрува.

🔗 Read on HackerNoon

LLM как переводчик в проверяемые критерии, а не как оракул

✍ pikafenger HackerNoon 11 авг llm ai-tools ai-in-fintech

О чём

Продуктовая ретроспектива скринера акций по индийским биржам, из которой снимается схема для любого интерфейса «спроси данные словами». Люди описывают идею историей, база ждёт точные поля, операторы и периоды, поэтому вся работа сводится к мосту между ними. Автор раскрывает промежуточное представление интента и правила, по которым мягкие формулировки не превращаются в жёсткие фильтры.

🔑 Главное

Пайплайн выглядит так: вопрос → извлечение интента → структурированные критерии → валидация и получение данных → детерминированная фильтрация → ранжирование и объяснение → результат, который можно проверить. Модель работает на первом и последнем шаге и не придумывает значения в середине.
Промежуточное представление разделяет проверяемое и требующее уточнения: hard_constraints с метрикой, оператором и значением, directional_preferences с направлением и отдельный список unresolved_terms для слов вроде «strong». Появляется место, где система имеет право остановиться и переспросить.
Жёсткие фильтры и мягкие сигналы нельзя смешивать: если каждая фраза становится отсечкой, выдача пустеет; если каждая становится предпочтением, наверх всплывают кандидаты, нарушающие явные требования. Отсюда формула: eligible — это правила рынка и явные ограничения, а score складывается из мягких сигналов с поправкой на качество данных.
Объяснение — следствие доказательств, а не пересказ. Полезное объяснение отвечает на четыре вопроса: какие критерии выполнены, на каких данных, за какой период и чего не хватает. Направление evidence → evaluation → explanation, а не «имя компании → убедительный абзац».
«Ничего не подошло» — правильный ответ. Ослаблять ограничения, пока что-нибудь не найдётся, значит тихо подменить запрос пользователя; вместо этого стоит показать, какое условие отсекло больше всего кандидатов. И интерпретацию нужно показывать: «low debt» превратился в debt_to_equity < 0.5 — пользователь может не согласиться, и это полезная обратная связь.

⚡ Попробовать за вечер

Описать JSON-схему интента для своей предметной области с полями hard_constraints, directional_preferences и unresolved_terms и заставить модель отдавать строго её.
Показать в интерфейсе, как система перевела нечёткие слова в критерии, и дать эти критерии править.
Заменить обезличенный спиннер на реальные стадии пайплайна и научить продукт возвращать пустой результат с указанием отсекающего условия.
Метрика: доля числовых утверждений в ответе, которые прослеживаются до конкретного поля данных, и доля честных пустых выдач вместо тихо ослабленных ограничений.

🔗 Read on HackerNoon

AI-статьи недели с HackerNoon

Главные статьи недели

Один gate вместо трёх списков команд: репозиторий, в котором агент не спорит с CI

GraphRAG или обычный RAG: тест на окупаемость графа

RAG над своими текстами: локальные эмбеддинги против фронтир-модели

Ёмкость LLM-платформы: шесть единиц вместо одного QPS

Память агента по правилам операционных систем: scope, decay, provenance

Агент дороже ошибается: outbox, inbox и идемпотентность вокруг tool-вызовов

Спекулятивный декодинг: почему tok/s без распределения задач ничего не значит

Карта пост-тренинга: reward-модель — это не RL

Ревью AI-кода: порог 400 строк и три категории решений для человека

LLM как переводчик в проверяемые критерии, а не как оракул

На что обратить внимание

🔁 Модель, проверяющая модель, замыкает круг

⏱ Субмиллисекунда на edge как метрика тщеславия

🛰 AWS уходит от fat-tree в дата-центрах

🔖 Anthropic собирается помечать всё, что пишет Claude

Мой план на эту неделю

Метаданные