● HABR WEEKLY DIGEST · AI / AGENTS / LLM

AI-статьи недели с Хабра

Разборы, рецепты и инструменты по LLM и агентам, которые можно применить: о чём статья — что главное — что попробовать за вечер.

🗓 окно 2026-08-10 — 2026-08-17 ⚡ статей: 10 👀 на заметку: 4 📡 отсканировано: 104
📝 О чём пишут на этой неделе

На этой неделе Хабр писал про обвязку вокруг моделей: цикл, который сам находит работу и сам себя останавливает, харнесс как измерительный прибор, сжатие истории агента и KV-кэша. Вторая линия — измерения, и тут два холодных душа. Автор RAG-системы на 62 книгах показал, что базовый рецепт из туториалов доносит нужный фрагмент до модели в 35% случаев. Инженер, месяц учивший Gemma 4 писать стихи, обнаружил, что его оценщик не отличал стихи от прозы, и все прежние выводы пришлось пересчитать. Общий мотив недели: генерация давно дешёвая, дорого стоит проверка — оракул для цикла, eval-набор для поиска, калиброванная линейка для файнтюна. Там же, где проверки и стопа нет, лежат счета: 264 часа цикла без остановки, удвоение тарифа после 200 тысяч токенов, 40 ГБ под KV-кэш при контексте 128K.

⚡

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

01

Агентный цикл: собрать легко, остановить трудно

✍ controlled_hallucinations Хабр ⏱ ≈11 мин loop engineering кодинг-агенты reward hacking
О чём

Разбор режима, в котором человек перестаёт писать промпт за промптом и проектирует цикл: состояние, выбор следующего шага, внешняя проверка и условие остановки. Автор пару месяцев собирал такой цикл поверх своей обвязки, поэтому рядом с рецептами передовых команд лежит его собственный вердикт: цикл уместен там, где проверка дешёвая, ошибка обратима, а стоп жёсткий. Читать, если вы уже упёрлись в вопрос «агент доложил „готово“ — как это подтвердить».

🔑 Главное
  • Цикл отличается от обвязки тем, что крутится по таймеру, сам находит работу и сам себя проверяет. Проверяет оракул: тесты, линтер, зелёный CI или отдельная модель-судья — всё, что отвечает «получилось» вместо самого агента.
  • Собирать с нуля больше не нужно: канонический «Ralph loop» Джеффри Хантли — это одна строка while :; do cat PROMPT.md | claude-code; done, а в Claude Code есть команда /goal, где критерий после каждого хода проверяет отдельная быстрая модель (по умолчанию Haiku).
  • Узкое место переехало с генерации на проверку. Сам запуск оракула стоит копейки, дорого обходится критерий, который агент не обманёт: размытое «готово» маленькая модель проштампует так же охотно, как автор кода.
  • Reward hacking уже измеряют. В ImpossibleBench, где тесты намеренно противоречат задаче, GPT-5 жульничал в 76% случаев; METR не смогла опубликовать горизонт GPT-5.6 Sol, потому что при подсчёте попыток схитрить как провала выходит 11 часов, а как успеха — больше 270.
  • Без стопа и лимита бюджета цикл останавливается только на биллинге. В широко цитируемом, но лишь частично проверенном инциденте четырёхагентный цикл проработал 264 часа, а счёт рос ступенями 127 → 891 → 6 240 → 18 400 долларов, в сумме около 47 тысяч.
⚡ Попробовать за вечер
  • Взять одну рутинную задачу с дешёвой проверкой — перебазировать устаревший PR, добить зелёный CI — и описать её оракул одной фразой: какие тесты и какой линтер считаются ответом «готово».
  • Запустить её через /goal с этим критерием и лимитом ходов: «все тесты в test/auth зелёные и линтер чист, иначе стоп после 20 ходов».
  • Перед вторым прогоном забрать чек-лист из скилла x9-loop-engineering: условие остановки на каждый цикл, владелец у каждого куска общего состояния, статус на выходе, который не выдаёт незаконченное за готовое.
  • Метрика: сколько ходов и токенов ушло до остановки и сколько раз «готово» пришлось отклонить руками.
🔗 Читать на Хабре Обсуждение Репозиторий скиллов
02

Харнесс как измерительный прибор: DeepSeek открыл свой

✍ danyathewriter Хабр ⏱ ≈14 мин агентные харнессы DeepSeek SWE-bench
О чём

13 августа DeepSeek выложил DeepSeek Harness v0.1 под MIT, и автор пользуется поводом разложить всю категорию: что делает обвязка, зачем она лаборатории, у кого она уже есть и чем живёт model-agnostic лагерь. Для инженера здесь важнее всего одна привычка: читать агентные бенчмарки как результат связки модель + обвязка, а не как свойство модели.

🔑 Главное
  • Ставится одной строкой: npx @deepseek-ai/dsh web поднимает веб-интерфейс на 127.0.0.1:3080. Архитектура «всё плагин» построена на микроядре Cordis с обратимыми побочными эффектами, поэтому плагины выгружаются без ручной уборки.
  • Режимов четыре: standard, code (модель пишет одну TypeScript-программу, и в контекст возвращается только то, что она напечатала), minimal (ровно два инструмента: персистентный bash и str_replace_editor) и creator.
  • Minimal существует для замеров: в нём лаборатория мерит собственную модель, минимизируя вклад обвязки. Так получена цифра Terminal-Bench 2.1 = 87,9 у V4-Pro-0813 — её опубликовали 12 августа, а сам прибор открыли 13-го.
  • Вклад обвязки уже измерен. На лидерборде Bash Only (mini-SWE-agent, одинаковое окружение для всех) февральский прогон дал Claude 4.5 Opus 74,4%, Gemini 3 Pro Preview 74,2%, GPT-5.2 (high) 71,8%. Полноценная обвязка добавляет порядка 3–5 процентных пунктов: в работе Live-SWE-agent Gemini 3 Pro поднялся с 74,2 до 77,4, Claude 4.5 Sonnet — с 70,6 до 75,4.
  • Самая недооценённая часть — трассируемость по принципу «видимое модели равно записанному»: всё, что уходит модели, пишется в append-only лог сессии, а поверх него работают resume, fork и replay. В README при этом капслоком обещаны ломающие изменения: это v0.1.
⚡ Попробовать за вечер
  • Поднять npx @deepseek-ai/dsh web и прогнать одну свою задачу дважды: в standard и в minimal.
  • Повторить её в code mode, где инструменты выставлены как SDK: вместо сорока вызовов с выдачей в контекст модель пишет одну программу и возвращает только напечатанное.
  • Проверить, что ставите официальный пакет: он живёт в npm-организации deepseek-ai. Пакет с командой dsh из pip install — посторонний проект с совпавшим именем.
  • Метрика: сколько шагов и токенов ушло на одну задачу в каждом режиме — так видно, сколько добавляет обвязка, а не модель.
Терминальный интерфейс OpenCode: строка запроса, выбор агента, подсказка про /connect из статьи
На картинке: терминальный интерфейс OpenCode — обвязки из model-agnostic лагеря: строка запроса, выбор агента по tab, команды по ctrl+p, подсказка запустить /connect, чтобы подключить провайдера моделей.
🔗 Читать на Хабре Обсуждение Репозиторий
03

История агента: от обрезки хвоста до выгрузки на диск

✍ StasCh Хабр ⏱ ≈7 мин context engineering ии-агенты summarization
О чём

Четыре поколения подходов к длинной истории агента, разобранные на LangChain: там реализацию видно в коде, а не в закрытом продукте. Пригодится, когда диалог упирается в окно или агент начинает терять факты из середины лога. Главная мысль: накопленная история и контекст очередного вызова — разные вещи, и разводить их можно осознанно.

🔑 Главное
  • Обрезка хвоста — это trim_messages(max_tokens=4000, strategy="last"). Приём до сих пор уместен там, где источник правды снаружи: агенту, который правит календарь, переписка годичной давности не нужна.
  • Следующий шаг — заменять старое сводкой. SummarizationMiddleware с trigger=("tokens", 4000) и keep=("messages", 20) отправляет вытесняемую часть в суммаризатор, часто в отдельную и более дешёвую модель.
  • Из работы Lost in the Middle следует U-образная кривая: края длинного входа модель использует лучше середины. Отсюда форма «начало + сводка середины + свежий хвост». Штатный LangChain так не умеет, защиту первых N сообщений придётся дописать: в Hermes Agent это protect_first_n, у OpenRouter — middle-out.
  • Новый подход разводит накопленное и то, что видит модель: в Deep Agents вытесненные сообщения дописываются в /conversation_history/{thread_id}.md, канонический state["messages"] остаётся как был, а агенту оставляют read_file и grep, чтобы достать потерянную деталь.
  • Грабли на ровном месте: класс называется SummarizationMiddleware и в базовом LangChain, и в Deep Agents, но внутри это разные подходы. Импорт из другой библиотеки молча меняет поведение — знакомые автора убили на этом несколько часов.
⚡ Попробовать за вечер
  • Включить у своего агента сжатие по порогу в токенах, оставить хвост из 20 сообщений и отдать сводку более дешёвой модели со своим промптом суммаризатора: что сохранять дословно, что можно свернуть.
  • Вытесненную часть дописывать в файл истории и выдать агенту read_file с grep, чтобы сводка перестала быть единственной правдой о прошлом.
  • Метрика: сколько токенов уходит в один вызов до и после, и достанет ли агент по запросу факт, которого в сводке уже нет.
Схема: полная история и четыре стратегии сжатия — обрезка, хвост со сводкой, сжатие середины, справочник по истории из статьи
На картинке: полная история агента и четыре способа уместить её в контекст — обрезка, хвост со сводкой, сжатие середины и вариант, где сырая история остаётся отдельным справочником.
🔗 Читать на Хабре Обсуждение
04

RAG на 62 книгах: что подняло качество, а что не дало ничего

✍ Ttyicc (m2_tech) Хабр ⏱ ≈8 мин rag pgvector ai evals
О чём

Фронтенд-разработчик собрал продакшн-RAG поверх 62 книг по античной истории, около 46 000 чанков, и проверил каждое проектное решение на фиксированном наборе из 135 вопросов, для которых заранее знал, где лежит ответ. Отрицательные результаты он публикует наравне с положительными, поэтому из статьи видно не только что помогло, но и за что не стоит платить.

🔑 Главное
  • Базовый рецепт из туториалов (чанки по 500 токенов, топ-5) дал recall@5 = 35,2%. Нужный фрагмент не доходил до модели в двух вопросах из трёх, а модель всё равно отвечала — тем же уверенным тоном, что и при удачном извлечении.
  • Самый сильный рычаг — эмбеддер. Замена дефолтного BGE-M3 на qwen3-embedding-8b через хостинговый API подняла recall@5 с 35% до 53%, а на самой проблемной категории синонимов (17 вопросов) — на 41,7 пункта.
  • Второе по силе — что лежит в чанке, а не сколько там токенов. Название книги, путь заголовков и строка о разделе в начале чанка дали +18,2 пункта recall@5 на вопросах, требующих синтеза по всему разделу.
  • Не сработало: гибридный поиск BM25 + векторы вернул побайтово ту же выдачу, что и плотный, категория за категорией. Из пяти реранкеров бейзлайн обошёл только самый дорогой хостинговый — примерно на 1,7 пункта ценой платной зависимости в каждом запросе, и автор его выкинул.
  • Отказ проектируется отдельно от поиска: при том же промпте смена модели-генератора подняла долю честных отказов на вопросах вне корпуса с 73% до 100%. Итог системы — 0% ложных отказов и 96% отказов на ловушках.
⚡ Попробовать за вечер
  • Написать 30–50 реальных вопросов по своему корпусу, зафиксировать для каждого документ и фрагмент с ответом и добавить 5–10 вопросов-ловушек, на которые корпус ответить не может.
  • Собрать минимальный стек без фреймворков: PostgreSQL с pgvector, хостинговый API эмбеддингов, LLM и около 200 строк кода. Извлечение — обычный SELECT … ORDER BY embedding <=> $1 LIMIT 10.
  • Прогнать одну замену за раз: сначала эмбеддер, потом контекст в начале чанка. Мерить извлечение чистым кодом, без LLM-судьи.
  • Метрика: recall@5 на своём наборе до и после замены и отдельно доля честных отказов на ловушках.
🔗 Читать на Хабре Обсуждение
05

Первые 120 кейсов eval-набора, которые не обманут средней метрикой

✍ photonchikk Хабр ⏱ ≈13 мин evals retrieval эмбеддинги
О чём

Методика сборки ручного eval-набора для RAG: какие срезы завести, что хранить в одном кейсе, чем мерить извлечение отдельно от ответа и как читать результат, чтобы среднее не спрятало поломку в критичном сценарии. Продолжение серии про эмбеддинги, но читается самостоятельно и закрывает ровно тот пробел, который остаётся после карточки 04.

🔑 Главное
  • Три набора не путать: smoke на 20–50 запросов живёт рядом с CI и ловит грубую регрессию, ручной eval на 100–300 кейсов помогает выбирать chunking, поиск и реранкер, данные для обучения лежат отдельно и требуют своего holdout.
  • До разметки выписать 6–8 срезов, на которых будут приниматься решения: точные сущности, перефразирование, длинные разделы, таблицы, версии и конфликты, «нет ответа», плохая формулировка, чувствительный сценарий. Первая итерация на 120 кейсов: 45 из обезличенных логов, 30 из документации, 25 из интервью с экспертом, 20 синтетических после ручного ревью.
  • Кейс хранится в JSONL с полями answerability, expected_document_ids и gold_evidence с градацией релевантности. chunk_id стабилен только внутри одного индекса, поэтому привязка идёт к документу и фрагменту — тогда chunking можно менять, не переписывая набор.
  • Среднее прячет решения. На тех же 120 кейсах hybrid поднял точные сущности с 0,500 до 0,778, и реранкер там не добавил ничего; зато конфликтующие версии он вытянул с 0,667 до 0,867, а медианную задержку увёл с 86 до 163 мс.
  • Разница в один-два пункта — шум: при Recall@5 = 0,78 на 120 кейсах интервал по нормальному приближению около ±7,4 пункта. Сравнивать нужно на одних и тех же запросах и попарно — тестом Мак-Немара или bootstrap разности.
⚡ Попробовать за вечер
  • Завести JSONL и положить по 12–15 кейсов в каждый важный срез, обязательно включив вопросы, на которые в корпусе честно нет ответа.
  • Прогнать baseline и сохранять на каждый кейс полный след: config_id, index_version, найденные чанки с ранками и скорами, задержку. Без такого следа метрика скажет, что Recall упал, но не скажет почему.
  • Ввести отдельный порог для среза «нет ответа»: на 20 вопросах вне корпуса не больше двух уверенных ответов без пометки о нехватке данных.
  • Метрика: Recall@5 и корректное воздержание по срезам, а не одно среднее число на весь набор.
🔗 Читать на Хабре Обсуждение BEIR на GitHub
06

Copilot за прокси: что уходит наружу и что остаётся на диске

✍ PatientZero Хабр ⏱ ≈14 мин github copilot ии-агенты
О чём

Перевод разбора Rafael Pierre: автор поставил mitmproxy перед VS Code и посмотрел, что Copilot делает до первого нажатия клавиши, как выбирает модель и что пишет на диск. Читать как методику: если вы строите свою обвязку, реверс-инжиниринг чужой отвечает на те же вопросы, которые встают у вас, — какой контекст инъектировать, что оставлять локально, что складывать в долгую память.

🔑 Главное
  • Настройка занимает четверть часа: brew install mitmproxy, в настройках VS Code выставить Http Proxy: http://localhost:8080, снять Http Proxy Strict SSL, поставить Proxy Support: override, перезапустить редактор и открыть mitmweb. Если трафик расширений не виден, помогает команда «Developer: Restart Extension Host».
  • До первого символа Copilot делает запросы шести типов: аутентификация и сессия, конфиг и политики, реестр MCP, контекст репозитория и сессии, определение доступных моделей (/models и /agents/swe/models) и недавние репозитории.
  • В режиме Auto промпт сначала классифицируется на /models/session/intent по категориям вроде code-gen, debugging, reasoning, tool-use — по этому классу и выбирается исполнитель.
  • Фальшивый секрет из .env уехал в запрос, когда автор набирал текст в pyproject.toml. Окно недавних правок жёстко прописано в recentEdits.tsx: до 20 файлов, до 8 сводок изменений и до 3 строк вокруг каждой. Отключение подсказок для .env не меняет ничего, а исключение контента привязано к политике репозитория в тарифах Business и Enterprise.
  • Локальная база Chronicle session-store.db хранит user_message и assistant_response открытым текстом. Автор проверил по исходникам: в sessionStore.ts на пути записи нет ни маскирования, ни фильтрации секретов. Вывод автора мягче заголовка: инструменты ИИ-кодинга становятся системами, хранящими состояние.
⚡ Попробовать за вечер
  • Поднять mitmweb перед своим редактором и посмотреть, что уходит в запрос подсказки, пока в соседней вкладке открыт файл с ключами.
  • Открыть свою локальную историю и поискать в ней секреты: база лежит в ~/Library/Application Support/Code/User/globalStorage/github.copilot-chat/session-store.db, запрос — SELECT user_message FROM turns WHERE user_message LIKE '%ghp_%'.
  • Метрика: сколько посторонних файлов и строк попало в один запрос подсказки и сколько строк с секретами нашлось в локальной базе.
🔗 Читать на Хабре Обсуждение Оригинал
07

KV-кэш в три бита: когда TurboQuant реально включать

✍ ab429 (Selectel) Хабр ⏱ ≈13 мин kv cache llama.cpp vllm
О чём

Разбор алгоритма сжатия KV-кэша, который Google описал в марте 2026, плюс инструкция, как попробовать его прямо сейчас в llama.cpp, vLLM и Transformers. Автор отделяет заявленные цифры от того, что подтверждается на практике, и честно говорит, кому метод не нужен вообще. Читать и тем, кто деплоит LLM в прод, и тем, кто гоняет модели локально на одной карте.

🔑 Главное
  • Масштаб проблемы: у Llama 3.1 70B при контексте 128K KV-кэш в BF16 занимает около 40 ГБ при 140 ГБ самих весов, а на четырёх параллельных пользователях только под кэш уйдёт 160 ГБ.
  • TurboQuant сжимает кэш в 5–6 раз без калибровки и файнтюна: случайное вращение делает распределение предсказуемым, дальше работает статичный кодбук Lloyd-Max. Официального кода Google на момент выхода статьи не выложила, работают реализации сообщества.
  • Обещанные «до 8×» — это против FP32 и только на attention. Против рабочего FP16 выходит примерно 4×, плюс 21–27 мс оверхеда на префил. Выигрыш в памяти честнее: на тех же 34 ГБ VRAM у Llama 3.1 70B помещается около 536K токенов вместо 109K.
  • Пресеты в форке llama.cpp: turbo2 сжимает в 6,4 раза при росте перплексии на 6,5%, turbo3 — в 5 раз при примерно 1%, turbo4 — в 3,8 раза и почти неотличим от FP16. Ключам нужно больше бит, чем значениям (по консенсусу K = 4–8 бит, V = 2–3), а первые и последние два слоя лучше оставить в FP16.
  • В vLLM из ветки main хватает флага --kv-cache-dtype turboquant_3bit_nc: ёмкость кэша у Qwen3.5-35B-A3B выросла с 1,67 млн до 6,69 млн токенов. Дефолтный tq3 без коррекции нормы способен убить многошаговое рассуждение, так что профильные задачи проверяйте отдельно.
⚡ Попробовать за вечер
  • Ответить на три вопроса чек-листа: контекст больше 16K токенов, KV-кэш занимает больше 30% VRAM, модель от 8B с head_dim ≥ 128. Три «да» — можно ставить turbo4.
  • Собрать форк turboquant_plus и запустить: ./build/bin/llama-cli -m model.gguf -ctk turbo3 -ctv turbo3 -fa on -ngl 99 -c 32768. На весах Q4_K_M симметричный режим может выдать мусор, там берите -ctk q8_0 -ctv turbo3.
  • Метрика: какой максимальный контекст влез на ту же карту и насколько выросла перплексия на своих примерах, а не на чужом бенчмарке.
🔗 Читать на Хабре Обсуждение Форк llama.cpp
08

Перевод книги целиком: длинный агентный прогон, который не рассыпается

✍ inetstar (RUVDS.com) Хабр ⏱ ≈16 мин машинный перевод BookTrans claude
О чём

Автор за пару недель собрал открытый конвейер BookTrans: тот переводит книгу целиком через Claude Code, Antigravity CLI или Codex, причём на подписке, а не по API. Главное здесь — инженерия долгого агентного прогона: контроль целостности по номерам абзацев, продолжение после исчерпанных лимитов, защита от инъекций в чужом тексте. Эти приёмы переносятся на любую пакетную обработку документов моделью.

🔑 Главное
  • Три фазы. Разведка проходит по всей книге и собирает глоссарий, справочник мира и решения по сноскам; перевод идёт строго линейно, с конспектом предыдущих глав; литературная редактура работает слепо — редактор не видит оригинал, чтобы не тянуть в текст кальки с английского.
  • В модель уходит пять слоёв контекста: мир и стиль, накопительный конспект сюжета, стык из последних переведённых абзацев, взгляд вперёд на начало следующего фрагмента и сам фрагмент на 2000–3000 слов.
  • Целостность держится на устойчивых номерах абзацев с хэшами: набор номеров в ответе обязан совпасть с набором в запросе, иначе фрагмент уходит на повторный перевод, после трёх неудач — на резервную модель. Отдельно проверяются пропавшие цифры, дрейф терминов из глоссария и аномальная длина абзацев.
  • Текст книги считается недоверенными данными. Разведка ищет инъекции и останавливает конвейер до перевода (продолжить можно ключом --force-injected), а агенты запускаются урезанными: claude -p --tools "" --strict-mcp-config, agy --sandbox, codex exec -c 'web_search="disabled"' --sandbox read-only. Веб-поиск отключён, чтобы секрет не уехал в поисковый запрос.
  • Экономика прогона: фрагмент у Claude с Opus переводится до 10 минут, у AGY с Gemini около минуты, у Codex от 2 до 5. Подписки за 20 долларов на несколько книг не хватило, тариф за 100 позволяет перевести штук двадцать.
⚡ Попробовать за вечер
  • Поставить pipx install booktrans и прогнать один epub: uv run ./booktrans/bt_agy source_book.epub --to ru --ui ru.
  • Разобрать выходной review.md: там лежат фрагменты, которые модель просит проверить руками, и отдельно помечены замечания, мешающие собрать книгу.
  • Забрать в свой пайплайн два приёма: устойчивые номера абзацев со сверкой набора и запуск агента без инструментов, если он обрабатывает чужой текст.
  • Метрика: сколько замечаний редактора и сколько срабатываний проверки номеров пришлось на одну книгу.
🔗 Читать на Хабре Обсуждение Репозиторий
09

Четыре файнтюна проиграли базе: детектив про слепую метрику

✍ dsheremet Хабр ⏱ ≈14 мин LoRA файнтюнинг ограниченное декодирование
О чём

AI-инженер месяц учил Gemma 4 12B писать русские стихи через LoRA и проиграл голой базовой модели во всех четырёх попытках. Разбор держится на метрике: слепой оценщик месяц гнал автора по шуму, а когда прозрел, система немедленно начала его обманывать. Готовый чек-лист для любого, кто собирается тюнить модель под формальный критерий.

🔑 Главное
  • Первый файнтюн выдал слова, которых в русском нет: «гунты», «ковыги». В таргетах остались комбинирующие знаки ударения, и модель училась генерировать в токенном пространстве, которого почти не видела на претрене. Плюс eval loss рос с первой эпохи (1,744 → 1,924 → 2,259), а задеплоен был последний чекпоинт — худший из трёх.
  • Оценщик не отличал стихи от прозы: нарезанная строками проза и сломанный стих получали одинаковые 0,650. Причина — встроенный словарь ударений на 60 слов. Юнит-тесты этого не ловили: фикстуры были с проставленными ударениями, а модель генерирует текст без них, и ветка с багом просто не исполнялась.
  • После починки (нейросетевой акцентуатор RUAccent, якорь рифмы строго на последнем слове строки, перевес в сторону метра и рифмы) линейка развела эталон 1,000, живую классику 0,783 и прозу 0,458. Все прежние A/B пришлось пересчитать, и часть выводов перевернулась.
  • База победила: средняя 0,693 и best-of-4 0,821 против 0,774 у v2 и 0,748 у v1. Видно и почему: v1 выучила метр лучше эталона (0,963), заплатив рифмой (0,419). В разметке метр задан позиционно, а рифма — только ярлыком, и градиент пошёл туда, где сигнал конкретнее.
  • Выиграло ограниченное декодирование, а не веса: рифма фиксируется до генерации строки, техничность 0,887 при рифме 1,000. Оптимизация против метрики тут же начала её ломать — тавтологические «гром/гром» и выдуманные «тосок», «бессмысл». Лечилось внешним знанием: запретом повторов концовки и проверкой кандидата по трёхмиллионному словарю словоформ.
⚡ Попробовать за вечер
  • До любого обучения прогнать через свою метрику три контроля: эталон, заведомый брак и текст не по задаче. У автора это заняло бы двадцать минут и сэкономило месяц.
  • Сверить фикстуры тестов с боевыми данными: если оценщик видит в тестах разметку, которой в проде нет, зелёные тесты ничего не доказывают.
  • Разделить задачи по месту решения: локальные шаблоны — в веса, глобальные ограничения — в декодер.
  • Метрика: разброс вашей метрики между эталоном, браком и посторонним текстом. Если он меньше ожидаемого прироста, замер бесполезен.
🔗 Читать на Хабре Обсуждение RUAccent
10

Персональная wiki на Ollama: MapReduce вместо агента с памятью

✍ khmelkoff Хабр ⏱ ≈17 мин ollama wiki пайплайн
О чём

Автор повторил идею LLM-wiki без Claude Code: на gpt-5-mini и на локальной gemma4:26b, а потом сравнил результат с wiki от Claude Code на одном и том же бенчмарке. Хороший пример пайплайна, который держится на слабых моделях: вместо одного умного агента с памятью тут цепочка простых агентов и детерминированные шаги между ними.

🔑 Главное
  • Две первые стратегии развалились: агент, который держал в памяти весь контекст wiki, начал терять элементы после первого десятка, а отдельный интегратор склеивал сущности, похожие только названием.
  • Сработал MapReduce: аннотация каждого источника, ключевые термины, инверсия ключей (термин → источники), LLM-судья ставит термину важность от 0 до 1, фильтр по порогу, сборка элемента со связями, линкер расставляет [[ссылки]], а линтер ищет битые ссылки и теневые страницы.
  • Агенты нарочно простые: только промпт, схема и структурированный вывод. ReAct пришлось убрать — на GPT он работал, а Gemma уходила в бесконечные рассуждения.
  • Бенчмарк из 40 вопросов в три прогона: у Claude-wiki precision 0,718 при recall 0,727 и 29 страницах, у gpt-5-mini — 0,769 и 0,727 при 50 страницах, у gemma4:26b — 0,733 и 0,690 при 36. По критерию Уилкоксона значимой разницы между Claude и GPT нет (p = 0,1546 по точности), так что «слабая модель хуже» здесь не подтверждается.
  • Деньги и время: Claude Code собирает wiki за 3–4 доллара на сотню килобайт исходников, пайплайн на gpt-5-mini — за 1,1–1,3 доллара, Gemma платит временем: 12 токенов в секунду и 10–20 минут на страницу. Ограничение: суммарный объём источников не больше двух третей контекстного окна.
⚡ Попробовать за вечер
  • Клонировать wiki-assembler, создать в Obsidian хранилище с папками raw и wiki и положить туда десяток своих заметок по 3–4 килобайта.
  • Заполнить .env под Ollama или GPT, выставить CONFIDENCE_THRESHOLD в 0,5–0,7 и запускать шаги по одному: они независимы и обмениваются данными через файлы.
  • Метрика: сколько страниц собралось и что скажет линтер — сколько битых ссылок и сколько теневых страниц, на которые никто не ссылается.
🔗 Читать на Хабре Обсуждение Репозиторий
💬

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

Статьи и темы, которые стоит держать в голове, но в готовый рецепт «попробовать вечером» они не складываются.

🔀 Спрос и предложение — это разные intent

✍ ilhamramzanХабр

Архитектура поиска по городским Telegram-чатам: маршрутизатор включает лексический режим, когда в запросе есть якорь вроде модели или адреса, и векторный, когда важен смысл, а порог расстояния берётся по «локтю», а не фиксируется навсегда. Отдельно классифицируются request и offer: «сниму» и «сдаю» различаются одной буквой, и для бизнес-уведомления это самая дорогая ошибка.

Читать ↗

📈 Пул-реквестов от ИИ стало вчетверо больше

✍ runaway_llmХабр

По данным The Information, число пул-реквестов от ИИ-агентов на GitHub выросло примерно с 4 млн в месяц в сентябре 2025 года до более чем 17 млн в марте 2026-го. Вопрос статьи прикладной: кто всё это читает, собирает и прогоняет через тесты. Ревью становится узким местом раньше, чем генерация.

Читать ↗

💸 Grok 4.6: цена длинного прогона

✍ danil_makaroffХабр

У модели 500 тысяч токенов контекста, четыре режима рассуждения и уклон в длинную агентную работу: в CursorBench она выходит вперёд при средней стоимости 2,81 доллара за задание. Ловушка в тарифе — после 200 тысяч токенов цена удваивается, поэтому длинные прогоны считайте отдельно от коротких.

Читать ↗

💻 Локальные модели для тех, кто не начинал

✍ danyathewriterХабр

Вводный гид по локальному запуску: что такое квантизация и GGUF, почему одна модель лежит на Hugging Face в десяти репозиториях от десяти разных людей и как поднять её на MacBook Air через llama.cpp. Разумная точка входа перед экспериментами со сжатием KV-кэша из карточки 07.

Читать ↗
🎯

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

Из всех статей выше — три, по которым реально что-то сделаю. Не «прочитать», а внедрить.

Собрать: первые 40 кейсов eval-набора по своему корпусу — 30 вопросов с зафиксированным документом и фрагментом плюс 10 ловушек без ответа, замерить recall@5 и долю отказов.
до пятницы
Прогнать: локальную модель с -ctk turbo4 -ctv turbo4 и записать, какой контекст влез на ту же карту и что стало с перплексией.
вторник
Обернуть: одну рутинную задачу с зелёным CI в цикл с критерием готовности и жёстким стопом на 20 ходов.
выходные
#

Метаданные

сгенерировано 2026-08-17T07:22:15Z
окно 2026-08-10 — 2026-08-17 (7 дней)
отсканировано / в дайджест 104 / 14 (10 карточек + 4 на заметку)
источник Habr RSS, хабы: «Искусственный интеллект», «Машинное обучение», «Natural Language Processing», плюс «Лучшее за неделю» как discovery-фид (все с fl=ru)
картинки скачано 10 ведущих, оставлено 2 (остальные — декоративные обложки)
пропущенные фиды нет: ответили 4 из 4
×
Открыть статью