HackerNoon Weekly Digest

01

Agentic RAG: бюджет на поиск и явная причина остановки

✍ superorange0707 HackerNoon agentic-rag rag ai-agents

О чём

Обычный RAG ошибается один раз и достаёт не те чанки. Агентный ошибается изобретательно и десять минут подряд: переписывает запрос, лезет в другой источник, зовёт субагента, рефлексирует, идёт на новый круг. Автор показывает, как превратить это в управляемую политику поиска: многомерный бюджет, контракт достаточности доказательств и явные коды остановки.

🔑 Главное

Бюджет — не одно число, а независимые оси: queries: 8, parallel_branches: 3, sources: 12, documents: 40, evidence_tokens: 12000, model_calls: 6, wall_clock_ms: 15000, estimated_cost: 0.20. Дочерняя ветка получает срез родительского бюджета, делегирование его не обнуляет, ретрай тратит тот же дедлайн.
Вопрос раскладывается на claims (C1…C5), и по каждому ведётся ledger: источник, класс авторитетности, дата публикации, дата извлечения, хеш цитаты, противоречия, пробелы. Тогда ответ умеет различать подтверждённое, спорное и неизвестное.
Прогон заканчивается одним из кодов: SUFFICIENT, BUDGET_EXHAUSTED, DEADLINE_EXCEEDED, SOURCE_UNAVAILABLE, PERMISSION_BLOCKED, CONTRADICTION_UNRESOLVED, NO_AUTHORITY_FOUND, USER_CLARIFICATION_REQUIRED. Только первый означает, что контракт доказательств выполнен.
Десять страниц с пересказом одного пресс-релиза — это не десять источников. Автор советует отслеживать происхождение и награждать прирост покрытия: новый claim, снятое противоречие, более авторитетный источник, более свежие данные. Если прироста нет, тратить нечего.
Извлечённый текст остаётся недоверенными данными. Системные инструкции держат вне retrieved-контента, авторизацию тулов — вне модели, пишущие тулы прячут на исследовательской фазе, egress браузера ограничивают. Бюджет заодно ограничивает и поверхность атаки.

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

Завести в своём retrieval-цикле словарь бюджета из статьи и списывать его в том числе с ретраев и вызовов субагентов.
Разложить один типовой запрос на claims и собрать ledger с полями source_id, authority, published_at, retrieved_at, supports.
Заменить «модель решила, что хватит» на коды остановки и отдавать пользователю честный BUDGET_EXHAUSTED вместо дописанного вывода.
Метрика: стоимость одного подтверждённого claim и распределение стоп-причин за неделю. Доля SUFFICIENT должна расти без роста числа запросов.

🔗 Read on HackerNoon

02

Поисковик с LLM: всё сломалось на стыках

✍ Ohad Farkash HackerNoon llm search ecommerce

О чём

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

🔑 Главное

Параметр min_sale_price принимает центы, а передавали доллары: порог «15» месяцами просил минимум пятнадцать центов и не отсекал ничего. Тест «передай абсурдный порог, выдача обязана опустеть» поймал бы это за пять минут в любой день.
Модель выдавала ID категорий правильной длины и числового диапазона. Часть не существовала, часть вела в чужой отдел, API принимал их молча и возвращал корректный по форме результат. Неверное предложение видно, неверный идентификатор — нет.
Парсер sort-интента вырезал слова подстрокой, поэтому newborn baby clothes искалось как born baby clothes, а cheaper earbuds — как er earbuds. Так работало годами: ни исключения, ни строчки в логе.
Граница слова \b в JS определена на ASCII и не срабатывает на иврите и арабском. Пришлось матчить по пробелу или краю строки: new RegExp("(^|\\s)" + escaped + "(?=\\s|$)", "i").
Латентность стоила дороже релевантности. Холодный поиск занимал 6–8 секунд, кэш на 24 часа увёл тёплый запрос примерно с 7 секунд до 0,2 секунды. Пара категорийных страниц вызывала LLM до проверки кэша: перенос проверки вперёд увёл их с 2,4 с до 0,2 с.

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

Прогнать по своим API-фильтрам тест на абсурдное значение: передать заведомо невозможный порог и проверить, что выдача пустеет. Не пустеет — фильтр мёртв.
Собрать авторитетный справочник идентификаторов (категории, SKU, tenant) и валидировать по нему всё, что модель выдаёт как ID, с падением в keyword-fallback.
Нарисовать реальную последовательность вызовов при попадании в кэш и убедиться, что дорогой вызов не стоит перед проверкой кэша.
Метрика: p95 времени до первого рендера страницы результатов и доля уходов до рендера — до и после кэша.

🔗 Read on HackerNoon Демо: onefindme.com

03

Eval, который вы не гоняете: агент при лежащем туле

✍ Abhilash Rao Mesala HackerNoon ai-agents ai-evaluation-frameworks devops

О чём

Тул отвечает 503 или молча отдаёт пустоту, агент читает это как «данных нет» и уверенно идёт дальше. Модель рассуждает корректно по тому, что видит, но вход деградировал, и узнать об этом ей нечем. Автор предлагает две метрики и способ их получить, не переписывая eval-набор с нуля.

🔑 Главное

Необработанное исключение видно в трейсе — и LangChain, и OpenAI Agents SDK его показывают. Тихий таймаут ведёт себя иначе: агент получает валидный, просто бесполезный результат, и фреймворк спокойно продолжает.
Три повторяющихся сценария. Сканер безопасности отвалился по таймауту, агент пометил проверку выполненной и выпустил деплой. Перегруженный stock API и пустой склад дают одинаковый ответ, после чего отменяются заказы. Проверка зависимостей вернула пустоту на втором шаге, и весь конвейер поехал на ложной посылке.
Все eval-наборы, что автор видел, гоняются с исправными тулами и сравнивают вывод с ожидаемым. Это меряет качество модели и промпта, но не готовность к продакшену: если систему ни разу не гоняли на деградировавших зависимостях, она обрабатывает их каким-то неизвестным способом, который никто не мерил.
Дыру закрывают две метрики. Degraded-tool detection rate: узнаёт ли агент отказ тула вместо «нечего сообщать». Graceful degradation rate: останавливается ли он и говорит вслух или отдаёт полный на вид ответ по неполным данным.
Жёсткое «останавливаться на любой деградации» ломается по-своему: 503 от перегруженного эндпоинта часто временный, а эскалация на каждый сбой быстро становится дорогой, если требует человека. Где ставить порог — продуктовое решение, и команды почти никогда не принимают его явно.

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

Взять три существующих eval-сценария и вкрутить инъекцию отказов: ошибка, таймаут и пустой payload от конкретного тула посреди нормального прогона.
Замерить в точках инъекции обе метрики: узнал ли агент отказ и что сделал дальше.
Записать явный порог: на каких тулах агент обязан остановиться и позвать человека, а где можно продолжить с пометкой о неполных данных.
Метрика: degraded-tool detection rate по каждому тулу. Всё, что ниже вашего порога, — список на доработку обработчиков.

🔗 Read on HackerNoon

04

Бенчмарк меряет обвязку вместе с моделью

✍ Haoxiang Li HackerNoon llm evaluation-harness ai-model-evaluation

О чём

Автор гоняет модели в арене «Кости лжеца» и чуть не опубликовал четыре бага под видом четырёх характеров моделей. Разбор пригодится каждому, кто сравнивает модели у себя и делает выводы по итоговой таблице. Автор оговаривает, что статья отредактирована с помощью AI, а данные взяты из реальных батч-прогонов его арены Kai!

🔑 Главное

DeepSeek V4-Pro делала почти 40% ставок вслепую, до просмотра своих костей — готовая история про интуицию и склонность к риску. Выяснилось, что обвязка сама подсовывала в промпт грубую оценку вероятности и сортировала по ней кандидатов. После починки утечки доля упала до 6%.
Рядом нашлись ещё три бага того же рода. max_tokens=400 резал длинные ответы, и это выглядело как «плохо держит формат». Реплики оппонента не доезжали до контекста — «слабое социальное рассуждение». В базу писались только первые сто символов суждения — «бессвязные рассуждения». На первых примерно шестидесяти матчах больше половины заметных различий между моделями сжались после починок.
Обвязка — это всё вокруг модели: промпты, сборка контекста, тулы, пространство действий, бюджеты токенов, роутинг провайдера, парсинг вывода, ретраи, фолбэки. Один и тот же промпт становится двумя разными задачами, если различаются порядок кандидатов, граница информации, бюджет и политика отказов.
«Честно» — это три разных протокола, а не одна конфигурация. Interface fairness (общий промпт, тулы и бюджет) отвечает, какая модель лучше ложится в ваш продуктовый контракт. Capability ceiling (тюним под каждую) — что модель может после адаптации, включая труд настройщика. Resource fairness (общие деньги, латентность или токены) — кто больше выдаёт при том же ограничении.
Дисциплина, которая держит обвязку за скобками: одно и то же зерно играется дважды со сменой мест; замораживаются порядок кандидатов, сериализация контекста, параметры сэмплинга, парсеры и версия кода (хеш промпта и git-коммит на батч); пишется, что реально сделал провайдер — completion- и reasoning-токены, finish reason, латентность, стоимость, фактический маршрут; ретраи, починки и подмены ботом лежат рядом со счётом, а не под ним.

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

Взять свой последний вывод вида «модель A смелее» или «модель B хуже следует инструкциям» и проверить контрфактом: если поменять только обвязку, различие выживет?
Прогнать один батч с фиксацией версий — хеш промпта, git-коммит, параметры сэмплинга, порядок кандидатов — и сохранить сырые ответы целиком, а не первые N символов.
Начать логировать finish_reason, фактический маршрут провайдера и долю фолбэков рядом с метрикой качества, плюс отдельный срез по прогонам без единого фолбэка.
Метрика: доля усечённых ответов и фолбэков в батче. Если она заметно различается между моделями, ваш лидерборд пока меряет обвязку.

🔗 Read on HackerNoon

05

Память агента: пять ворот, которые не заменит большое окно контекста

✍ Joshua Nwachinemere HackerNoon ai-agent-memory agent-memory-architecture context-engineering

О чём

Миллион токенов увеличивает склад, но не нанимает библиотекаря и не подсказывает погрузчику, какую коробку везти. Автор разбирает архитектуру памяти как набор отдельных контрольных точек, каждую из которых можно тестировать, инструментировать и сломать независимо. Текст плотный и со ссылками на бенчмарки, так что перед командой будет чем аргументировать.

🔑 Главное

Ёмкость и использование — разные вещи. Lost in the Middle показала U-образную зависимость от позиции факта на моделях образца 2023 года. В RULER около половины из 17 моделей, заявлявших не менее 32K, удержали порог бенчмарка (85,6% по его собственному определению) на 32K. NoLiMa убрала буквальные совпадения слов, и GPT-4o упала с 99,3% на коротком контексте до 69,7% на 32K.
Длинная история — отдельный отказ. LongMemEval: 500 вопросов на пять способностей памяти, и на историях около 115K токенов точность падала на 30–60%. Окно вмещало всю историю целиком, этого не хватило.
Подложка делится на три слоя: сырой журнал событий под аудит и правила хранения, курируемая долговременная память (типизированная, привязанная к принципалу, со ссылками на исходные события) и рабочий контекст хода, который собирается из курируемого слоя, а не переигрывается из сырых событий.
Пять ворот: admit (что вообще достойно памяти, и это же главная граница доверия: вредоносный вход попробует завысить собственную важность), retrieve (что относится к текущей задаче), consolidate (сворачивать со ссылками назад, чтобы сводку можно было размотать), revise (не перезапись, а версия с датой, источником и статусом конфликта), forget (истекло, опровергнуто или стало небезопасным).
И честная оговорка: строить всё это с самого начала не нужно. Для коротких ограниченных задач большое окно с компакцией или вовсе отсутствие durable-памяти проще и безопаснее, потому что персистентность приносит обязательства по провенансу, удалению и защите от отравления записей.

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

Развести в своём агенте три слоя явно: сырой журнал, курируемая память со ссылками на исходные события и рабочий контекст хода.
Написать write-gate: классификатор, который решает, что попадает в durable-память, и правило, запрещающее контенту из недоверенного хода попадать туда с высокой уверенностью.
Мерить indexing, retrieval и reading отдельными числами, а не одной точностью ответа, и завести счётчики устаревших записей, конфликтов и протечек между пользователями.
Метрика: доля ответов, где нужная запись лежала в памяти, но не доехала до рабочего контекста. Это отдельный показатель ворот извлечения, и в общей точности он тонет.

Схема памяти агента: поток событий, ворота допуска, сырой архив, курируемая память, ворота извлечения и рабочий контекст — **На картинке:** архив держат широким, активируют узко. Допуск, извлечение, ревизия и забывание — четыре отдельные точки, где можно ошибиться независимо.

🔗 Read on HackerNoon

06

Агенту нужна шина событий, когда процесс переживает запрос

✍ Jayakumar Ramalingam HackerNoon ai-agents event-driven-architecture idempotency

О чём

Демо агента помещается в один запрос: план, вызов тула, ответ. Реальный процесс — нет: один тул думает пять минут, другой агент проверяет результат, изменение в проде ждёт согласования человека, а пока согласование висит, сервис перезапускается. Статья про то, где проходит граница между «дописать промпт» и «поменять архитектуру».

🔑 Главное

Событие, предложение модели и авторизованная команда — три разные сущности. Безопасный путь: событие → предложение агента → политика или согласование человеком → AuthorizedCommand → детерминированный ключ идемпотентности → исполнение → событие результата. Ключ выводит код из авторизованной команды, модель им не управляет.
Фраза LLM «отмасштабировать сервис» не означает, что сервис отмасштабирован, и не означает, что действие разрешено. Разделение остаётся полезным и когда модель меняется: она становится способнее, не получая при этом права перезапускать прод или выдавать возвраты.
Память агента и состояние процесса — не одно и то же. Транскрипт сжимают, обрезают и иначе интерпретируют после обновления модели; если единственная запись о выданном возврате — фраза в окне контекста, возврат однажды выдадут повторно. Идентификаторы событий, статусы команд, согласования, счётчики ретраев и результаты держат в долговременном хранилище.
Брокер не делает систему надёжной, он меняет набор отказов. Дубликаты закрывают стабильными event id и ключами идемпотентности. Нарушенный порядок — версиями, таймстемпами и отказом от переходов, не подходящих текущему состоянию. Петли между агентами — глубиной причинности и лимитами по времени, токенам и шагам. Конфликтующие решения по одному ресурсу — сериализацией или проверкой версии.
Шина нужна не всем: суммаризатору документа хватит синхронного запроса. События окупаются, когда работа переживает таймаут запроса, несколько агентов действуют независимо, в процесс вмешивается человек или у действия есть операционные и денежные последствия. Цена — схемы сообщений, retention, трассировка, разбор недоставленного и асинхронная отладка.

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

Взять один свой агентный сценарий и нарисовать на нём ожидания, ретраи, согласования и побочные эффекты. Первое событие ставят там, где эти границы спрятаны внутри синхронной цепочки.
Найти самый долгий блокирующий шаг — обычно это согласование человеком или медленный внешний тул — и дать ему durable-запись состояния плюс событие, которое возобновляет процесс.
Добавить ключ идемпотентности каждой команде, меняющей что-то снаружи: sha256 от канонического JSON авторизованной команды (workflowId, workflowVersion, action, resource, targetState), и требовать его у исполнителя.
Метрика: число повторно выполненных внешних действий за неделю. После ключа идемпотентности оно должно стать нулевым.

🔗 Read on HackerNoon

07

Коду-агенту дают контекст до того, как он полезет искать

✍ Beth HackerNoon coding-agents claude-code token-optimization

О чём

Первые действия агента в чужом репозитории предсказуемы: ищет имена файлов, открывает манифесты, читает конфиги, сканирует директории. Так появился Agent Token Optimizer — локальный детерминированный хук, который отдаёт агенту небольшой пакет релевантного контекста до начала этих раскопок. Проект открытый, и в статье прямо сказано, чего он пока не доказал.

🔑 Главное

Большее окно не означает лучший отбор. Если в контекст приезжает больше нерелевантного, важные детали всё равно конкурируют за внимание, а новый запрос заставляет агента переоткрывать то, что он только что смотрел.
Инструмент цепляется к Claude Code и Codex через user-prompt хук. При отправке задачи хук отрабатывает локально: оценивает задачу и собирает ограниченный пакет контекста — пути, символы, структурные сводки, выбранные фрагменты — с бюджетом около 1 200 оценочных токенов. Для тривиальных запросов активация пропускается.
Хук выбран вместо MCP-тула сознательно. Опциональный тул агент должен вспомнить и вызвать, то есть оптимизация зависит от поведения модели. Хук вызывает сам хост в рамках жизненного цикла запроса, поэтому активация от модели не зависит. MCP-сервер в проекте остался, но в путь установки по умолчанию не входит.
Local-first — тоже осознанное ограничение: рантайм не ходит в сеть, не требует своего API-ключа и не сохраняет сырые промпты, исходники, учётные данные и сгенерированные фрагменты. Локальный кэш хранит структурную информацию, пути, хеши и свидетельства выполнения без содержимого.
Автор не публикует процент экономии и объясняет почему: проект до 1.0, а меньший стартовый пакет не обязан уменьшать полную стоимость задачи — агент способен добрать исследованием позже или, наоборот, потерять важное. Честная оценка обязана мерить и экономию, и корректность.

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

Склонировать репозиторий и поставить хук: git clone, corepack enable, pnpm install --frozen-lockfile, pnpm build, pnpm ato install --hosts codex,claude-code.
Сначала посмотреть, что именно правится в конфиге хоста: pnpm ato install --hosts codex,claude-code --dry-run --json. Хуки выполняют команды в цикле агента, так что конфиг стоит прочитать до согласия.
Прогнать pnpm ato doctor и сравнить парные baseline- и optimized-сценарии из репозитория на своём проекте.
Метрика: суммарные токены на задачу и доля доведённых до конца задач — обе цифры сразу, иначе экономия окажется мнимой.

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

08

Четыре блока промпта: из просьбы в спецификацию

✍ Sandeep Dhuri HackerNoon prompt-engineering secure-ai-coding software-architecture

О чём

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

🔑 Главное

Блок 1, context — то, что модель не угадает: домен, инварианты системы, окружение. Пример автора: платёжный сервис в регулируемом банковском контуре, .NET 9, все денежные значения в USD и хранятся как decimal, любой внешний вызов может быть повторён, все записи идемпотентны, мультитенантность со скоупом по tenant_id.
Блок 2, constraints — что обязано и что запрещено, с приоритетом. Safety выше correctness, correctness выше style, и порядок записан прямо в промпте, чтобы конфликты разрешались в вашу пользу, а не в среднюю по корпусу.
Блок 3, output contract — что именно возвращается: реализация, тесты на перечисленные ограничения и список тех ограничений, которые выполнить не удалось, с причиной. Молча ослаблять ограничение запрещено.
Блок 4, verification — проверки, названные прямо в промпте. Его пропускают чаще всех, и он же меняет результат: модель генерирует в сторону объявленных тестов, а ревьюер проверяет по ним же. «Напиши обработчик вебхука для платёжных уведомлений» — это желание, и средний обработчик из публичного корпуса приедет без идемпотентности, без проверки подписи и с логированием payload.
Почему вкладываться стоит именно во вход: по отчёту Veracode 2026 (более 150 моделей) доля задач кодогенерации, вносящих известную уязвимость, держится около 45%. Возможности растут, безопасность стоит на месте, потому что модель достраивает паттерны публичного корпуса, пока ваш промпт их не перевесит.

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

Взять один промпт, который вы гоняете регулярно, и переписать его в четыре блока.
В блок verification вписать конкретные проверки: точность 0.1+0.2 для денег, повторную доставку с тем же ключом идемпотентности, инъекционные строки, попытку доступа в чужой tenant (обязана падать).
Положить промпт в git и ревьюить как код — у изменений появится история, а у требований одно место жительства.
Метрика: сколько ограничений из блока constraints модель нарушила в выдаче до и после переписывания. Считать по списку, а не на глаз.

Схема Specification Frame: четыре блока промпта на одной странице и стрелка к агенту — **На картинке:** одностраничная форма фрейма — цель, ранжированные ограничения, контекст и проверки. Подпись автора: двадцать минут на написание, и дальше фрейм задаёт всё, что идёт следом.

🔗 Read on HackerNoon

09

Qwen3.8 27B: 50 ток/с на полном 256K-контексте и одной 24-ГБ карте

✍ Michał Piszczek HackerNoon local-llm llama-cpp quantization

О чём

Самый тяжёлый технический разбор недели: dense-модель на 27B, весь её контекст в 262 144 токена, мультимодальный вход и спекулятивное декодирование на одной RTX PRO 4000 Blackwell SFF с 24 ГБ. Ценность не только в цифрах, но и в методе: автор отдельно разносит гейты замеров и отказывается складывать их в один красивый разгон.

🔑 Главное

Итог по отдельным гейтам: 50,44 ток/с в текущей серии из десяти прод-прогонов; в строгом A/B рантайма кастомная сборка llama.cpp даёт 55,40 против 45,42 у чистого master (+21,97%); встроенный MTP против greedy-декодирования только целевой модели — 21,19 → 59,46 ток/с (2,81×); на реально заполненном 256K-кэше остаётся 12,61 ток/с без OOM.
Первым победил Q4_0 и оказался неверным победителем: он обгонял Q3_K_M и Q4_K_M, потому что метка кванта и размер файла ничего не говорят про CUDA-ядро, которое реально запустится. На коротком контроле WikiText-2 у IQ4_XS перплексия 6,1175 против 6,3798 у Q4_0 — слишком дорого за пару сотен миллисекунд.
Готовый NVFP4-MEDIUM провалил качество (6,4949 PPL): рецепт конверсии загнал в NVFP4 и чувствительные тензоры attention и DeltaNet. Поддержка формата железом не подсказывает, где тратить биты. Собственный гибрид — bulk в NVFP4, отобранные тензоры в Q5_K и Q6_K по iMatrix-ранжированию на 5 472 сообщениях из 296 собственных сессий, эмбеддинги Q6_K, выходная голова Q8_0 — дал 5,01 BPW при PPL 6,1197.
Развёртка по n_max для MTP немонотонна: значения с 4 по 7 замедляли, а n=8 подпрыгнул до 49,31 ток/с. Девятый кандидат не быстрее и стоит ещё около 150 МиБ, а при полном 256K падает на очередном 162-мегабайтном буфере CUDA-графа. Автор оставил 8 как последнюю быструю точку перед аллокатором. Более точный драфтер сделал хуже: 69,2 МиБ лишней точности в MTP-весах увели пропускную способность с 50,44 до 37,02 ток/с, потому что драфтер и цель работают как одна квантованная система.
«Загрузилось на 262K» не доказывает ничего. Автор залил 261 500 входных токенов, сгенерировал ещё 256, зафиксировал VRAM после заливки, состояние усечения и хеш вывода, и запретил формулировку «262K loaded» в таблице результатов. Финальный запас около 500 МиБ оставлен намеренно: при 76 МиБ свободных всё работало, пока 31-мегабайтное выделение под планировщик и фрагментация графа не показали разницу между арифметикой и операционным запасом.

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

Собрать калибровочный корпус из своих реальных сессий (код, тул-вызовы, ваши языки), прогнать по нему секрет-скан и llama-imatrix, и квантовать по своей карте важности вместо чужого пресета.
Прогнать у себя развёртку по n_max для спекулятивного декодирования: кривая рваная, и лучшая точка может стоять сразу после провала.
Заменить проверку «модель загрузилась с --ctx-size N» на честную: залить контекст почти доверху, сгенерировать хвост, записать VRAM после заливки, факт усечения и хеш вывода.
Метрика: ток/с на дальнем конце заполненного кэша и свободная VRAM в этот момент. Арифметически свободная память и операционный запас — разные числа.

Таблица результатов: гейт, результат, значение — от прод-серии до декодирования на полном кэше — **На картинке:** цифры, которые автор оставил, — каждая со своим гейтом. Складывать их в один заголовочный разгон автор отказался намеренно.

🔗 Read on HackerNoon

10

2 940 описаний от LLM: где рвётся конвейер данных

✍ Naoto Yamabe HackerNoon data-quality llm postgresql

О чём

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

🔑 Главное

Английские названия брались как sorted()[0] из неупорядоченного списка народных имён, где флага «предпочтительное» просто нет. Это фильтр по алфавиту, никак не связанный с правильностью: отпечаток такого выбора несут около 60% из 2 940 записей. Ранняя выборка на 200 дала 48%, и автор прямо пишет, что цифры не свёл. Исправлено 410 названий за два раунда.
Иногда подпись указывала на совсем другое животное. Carcharhinus sorrah подписали School Shark, хотя это имя принадлежит Galeorhinus galeus из другого семейства; Chelidonichthys kumu назвали Flying gurnard, а это Dactylopterus. Тесты молчали: значение было непустой, корректно оформленной и правдоподобной английской строкой.
Радиус поражения одной неверной строки оказался больше ожидаемого. Имя подавалось в промпт как входное поле, а описания генерировались до починки имён, поэтому модель уверенно писала про другое животное, и правка имени тянула перегенерацию описания. Дальше строка уехала в манифест заказа иллюстраций: у Takifugu xanthopterus (シマフグ, «полосатый фугу») в описании стояли чёрные пятна — обе картины пришли пятнистыми и их перерисовывали вручную.
Два соседних поля на одной странице расходятся, если заземлено только одно. Генератор ареала получал реальную сетку наблюдений и запрет от неё отходить, генератор описания — только имена и таксономию, но его тоже просили написать, где рыба живёт. Epinephelides armatus с 1 030 наблюдениями в четырёх ячейках юго-запада Австралии описан как широко распространённый по Индо-Пацифике, притом что заземлённое поле на той же странице указывало ареал верно.
Вывод, который переносится куда угодно: ранжируйте работу над качеством данных по тому, что читает поле, а не по тому, насколько важным оно выглядит. Каждое поле, которое читает промпт, имеет собственный радиус поражения.

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

Найти в своём пайплайне все места, где выбор из неупорядоченного списка сделан через first или sorted()[0], и заменить на явное правило с флагом предпочтения либо на честный отказ.
Выписать список полей, которые уходят в промпт, и для каждого указать, что читает результат дальше: другие генераторы, задания подрядчикам, экспорт. Это и есть ваш радиус поражения.
Сравнить попарно поля, описывающие одно и то же с разной заземлённостью: если одно получает доказательства, а второе нет, второе врёт молча.
Метрика: доля сгенерированных записей, у которых есть ссылка на источник-доказательство. Остальное — черновик, и в интерфейсе его стоит помечать именно так.

Сравнение заказанных и перерисованных иллюстраций фугу: пятнистая версия против полосатой — **На картинке:** цена одной неверной строки. Описание ушло художнику как референс, и обе картины пришлось перерисовывать.

🔗 Read on HackerNoon

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

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

Agentic RAG: бюджет на поиск и явная причина остановки

Поисковик с LLM: всё сломалось на стыках

Eval, который вы не гоняете: агент при лежащем туле

Бенчмарк меряет обвязку вместе с моделью

Память агента: пять ворот, которые не заменит большое окно контекста

Агенту нужна шина событий, когда процесс переживает запрос

Коду-агенту дают контекст до того, как он полезет искать

Четыре блока промпта: из просьбы в спецификацию

Qwen3.8 27B: 50 ток/с на полном 256K-контексте и одной 24-ГБ карте

2 940 описаний от LLM: где рвётся конвейер данных

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

🧠 Векторное хранилище ищет, но не помнит

⚙️ Быстрый LLM-ранкер — это две разные задачи

🛒 Агенты стали покупателями

🔌 Локальный AI-проект переезжает на публичный URL

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

Метаданные