Руководства, сравнения и новости об инструментах ИИ

Сообщение «You've hit your session limit · resets 3:45pm» в Claude Code — не ошибка и не баг, а то, как работают лимиты использования подписки. В официальном справочнике четыре варианта: session (скользящее 5-часовое окно), weekly (недельное окно), а также Opus и Sonnet (лимиты одного семейства моделей); поскольку лимиты сессии и недели общие для всех моделей, смена модели доступ не вернёт. В статье разобрано, что означает каждое сообщение и как менялся текст со времён старого «Claude usage limit reached», что больше всего расходует лимит и что делать в момент его достижения: при лимите Opus/Sonnet сменить модель через /model, дождаться сброса (с v2.1.234 автоматически), использовать кредиты использования через /usage-credits или перейти на API с оплатой по факту. Также — как посмотреть остаток через /usage и какие похожие сообщения не относятся к вашему лимиту.

Prompt is too long в Claude Code означает, что весь отправляемый ввод не помещается в контекстное окно. Статья различает длинную историю, слишком большой исходный ввод и ошибку самого сжатия; объясняет /context, /compact, /clear, откат разговора и отдельные окна субагентов. Также разобраны загрузка подробных определений MCP по запросу, условия 200K и 1M для модели, подключения и плана, разница между ёмкостью и оплатой, похожие ошибки и прямые обращения к API с подсчётом токенов.

Если MCP-сервер не подключается к Claude Code, сопоставьте статус, способ подключения и подробности Issue. failed может означать сбой запуска stdio, ошибку связи HTTP или отказ для фиксированного заголовка аутентификации. Статья объясняет Connection closed, переменные окружения и неопределённые ссылки, проектную конфигурацию и одобрение, запуск npx в Windows, журналы отладки и проверку операций после переподключения. Отдельно разобрано, почему ноль инструментов не обязательно означает ошибку, а отдельный запуск не гарантирует успешного подключения MCP.

В длинных сессиях Claude Code иногда на экран утекает строка с «court» (или «call») и сырыми тегами <invoke> / <parameter>, при этом команда не выполняется. Это не ошибка вашего окружения или команды, а сбой на стороне модели (семейство Opus 4.8 / 4.7), которая генерирует управляющий токен вызова инструмента в битой форме; харнесс отклоняет его по принципу fail-closed, поэтому риска запуска неверной команды нет. По-настоящему неприятна цепная реакция: битый блок остаётся в истории, модель его имитирует, и повторы в той же сессии бьют рикошетом. Главное правило — «промахнулся дважды, уходи в свежую сессию (/clear)». В статье разобраны механизм, две первопричины, типичные заблуждения, исправления для пользователей и разработчиков, отличие от похожих ошибок и официальный статус.

Аккаунт ChatGPT или Claude могут заблокировать и без злого умысла, а возвращение через другой аккаунт только ухудшит дело. Мы полностью прочитали на 4 октября 2026 года условия OpenAI (ChatGPT, Codex) и Anthropic (Claude, Claude Code) — Terms of Use, Usage Policies, Consumer Terms и Usage Policy — и их справочные центры и разобрали: официальные причины блокировки у каждой компании; чего нельзя делать, с пунктом правил к каждому случаю (общий аккаунт, автоматизация интерфейса, джейлбрейк, обход бана, Claude из неподдерживаемой страны через VPN, дистилляция, перепродажа, массовое создание аккаунтов); как между февралём 2026 года и сегодняшним днём изменилась позиция Anthropic по использованию входа личного тарифа в других инструментах (самому запускать Agent SDK — предусмотрено, отдавать токены чужому сервису — запрещено); предупреждения и проверки, которые не означают нарушения; различие между владением несколькими аккаунтами и их использованием (дополнение от 9 октября: официальный переключатель OpenAI, лимит подтверждения номера у Anthropic, почему ручное переключение после достижения лимита требует ответа на конкретный вопрос и чем оно отличается от передачи, перепродажи и обхода блокировки); чек-лист из восьми пунктов; и порядок апелляции (OpenAI — ссылка из письма или openai.com/form/appeal; Anthropic — вход на claude.ai под заблокированным аккаунтом; предупреждения — usersafety@anthropic.com).

Переобучать гигантский ИИ с нуля слишком дорого, но хочется настроить его под себя; LoRA (Low-Rank Adaptation) исполняет это желание, замораживая исходную модель и обучая лишь крошечную навесную деталь (адаптер), сокращая обучаемые параметры до менее чем 1% от исходной модели. LoRA делает файнтюнинг заметно дешевле и быстрее и чрезвычайно популярна в генерации изображений вроде Stable Diffusion как маленький файл, добавляющий персонажа или стиль. Статья объясняет её через аналогию заплатки. LoRA — флагман параметрически эффективного файнтюнинга (PEFT): огромные исходные веса остаются замороженными, в каждый слой вставляется небольшая навесная матрица, и обучается только она (W = W0 + BA, где W0 заморожена, а BA — небольшая добавленная часть). В основе — гипотеза, что адаптация ИИ не требует больших изменений (достаточно низкого ранга), которую подтвердили эксперименты оригинальной статьи (хотя в математике и программировании, по сообщениям, LoRA уступает полному обучению). Преимущества: обучаемых параметров меньше 1% от исходных (в оригинальной статье для GPT-3 175B — примерно в 10 000 раз меньше), меньше памяти GPU при обучении (там же 1,2 ТБ → 350 ГБ), быстрее и дешевле обучение, без задержки при инференсе после слияния адаптера, и модель меньше забывает исходные способности. Главная сила — сменные адаптеры: держите одну общую базу и мгновенно меняйте маленькие файлы LoRA под каждый случай (поддержка, тон компании, конкретный персонаж). Многие впервые встречают LoRA в генерации изображений, где широко распространяются LoRA для Stable Diffusion, обучённые персонажу, стилю или объекту (добавить стиль, обучить персонажу, лёгкие и удобные для обмена). QLoRA сочетается с квантизацией, обучая LoRA поверх базы на 4-bit: по статье, модель 65B, которой при полном обучении в 16 битах нужно более 780 ГБ, дообучается на одном GPU с 48 ГБ, а 33B — на потребительском GPU с 24 ГБ, с результатами на уровне 16-битных методов (сравнима ли 33B и 65B с полным обучением, статья, по её словам, не проверяла). По сравнению с полным файнтюнингом (обучение всех весов) LoRA отличается обучаемыми весами, стоимостью, результатом и областью применения; для большинства задач LoRA достаточно. Базу оставь как есть, приправляй понемногу. Цифры получены в условиях экспериментов оригинальной статьи и других работ, ориентировочно.

Огромная модель 70B, работающая на одном домашнем ПК вместо стойки дата-центровых GPU (то, что не влезает в потребительскую GPU, берут на себя CPU и оперативная память), возможна благодаря квантизации, которая снижает числовую точность весов модели, чтобы резко уменьшить размер и память. Если дистилляция переносит знания в отдельную меньшую модель, то квантизация делает ту же модель легче. Статья объясняет это через аналогию со сжатием фотографии. Квантизация заменяет веса, хранящиеся как дробные FP16/FP32, целыми INT8 (8-бит) или INT4 (4-бит), сокращая байты на вес (FP32=4, INT8=1, INT4=0,5); как сжатие RAW-фото в JPEG, жертвуем малой точностью ради большого выигрыша, и удивляет, как мало вы теряете. По памяти 4-bit использует около четверти от FP16: модель 70B падает с ~140GB до ~35GB, а 8B при 4-bit — ~4.5-5GB, умещаясь в средний GPU с 8GB VRAM для локального запуска (демократизация LLM). По точности INT8 почти без потерь, а INT4, по имеющимся данным, деградирует менее чем на 4% на обычных Q&A и задачах на здравый смысл, но потеря заметнее для математики, генерации кода и сложных рассуждений (проявляется как небольшой рост перплексии), поэтому выбирайте разрядность под задачу. Основные методы: GPTQ (первопроходец точного 4-bit), AWQ (защищает ~1% самых важных весов; превосходит ли он GPTQ, зависит от оценки), GGUF (формат llama.cpp/Ollama, Q2_K-Q8_0, гибрид CPU+GPU, для локального) и QLoRA (4-bit база плюс LoRA для файнтюнинга на потребительском GPU). Это отличается от дистилляции (перенос в отдельную малую модель) и файнтюнинга (добавление знаний задачи), и эти три обычно комбинируют (квантизовать дистиллированную модель; файнтюнить квантизованную базу). Чтобы начать, запустите модель GGUF с Ollama одной командой, выберите Q4/Q8 по VRAM и избегайте INT4 для кода или точной математики. Большинство крупных моделей поставляются уже квантизованными, так что вы просто скачиваете и используете их. Сохраняем ум, убираем только вес. Цифры взяты из публичных материалов, ориентировочны.

Огромный, высокопроизводительный ИИ умён, но тяжёл и дорог; дистилляция моделей (knowledge distillation) решает это, перенося знания крупной модели-учителя в небольшую модель-ученика и сохраняя близкую к учителю производительность при гораздо меньшем размере и большей скорости. Статья объясняет это через аналогию «учитель — ученик». Ключ — soft labels: обычное обучение учит только «ответ — кошка» (hard label), а дистилляция передаёт всё распределение вероятностей учителя, например «90% кошка, 8% собака, 2% лиса», чья степень сомнения несёт богатую информацию; параметр temperature смягчает вероятности, открывая тонкие отношения (реальный пример: функция API OpenAI 2024 года для обучения малых моделей на выходах крупных). Преимущества: быстро и дёшево, намного компактнее при близкой к учителю производительности (TinyBERT: в 7,5 раза меньше, более 96,8%), работа на edge, сила в специализации. Два подхода: white-box (полный доступ к весам и внутренним представлениям, более глубокий перенос; для своих или OSS-моделей) и black-box (видны только выходы/ответы API; чужой API как учитель может нарушать условия). Отличается от квантизации (сжатие точности весов той же модели) и fine-tuning (дообучение существующей модели под задачу) — дистилляция переносит знания в отдельную малую модель, и все три комбинируемы. Правовая сторона стала большой темой 2026 года: технология легитимна, но OpenAI, Anthropic и xAI имеют анти-конкурентные положения о дистилляции, запрещающие использовать выходы для создания конкурирующих моделей, поэтому дистилляция конкурента из ограниченного API может нарушать условия. Спор OpenAI против DeepSeek (OpenAI заявила, что связанные с DeepSeek аккаунты обходили ограничения, чтобы получить выходы для дистилляции, тогда как условия DeepSeek, по сообщениям, разрешают дистиллировать её выходы) показывает, что оценка зависит от того, чьи условия API применяются, а Claude Fable 5/Mythos 5 переключают запросы, помеченные как дистилляция, на менее мощную модель Opus. Советы: используйте свои или лицензированные OSS-модели как учителя, проверяйте анти-дистилляционные положения перед использованием коммерческого API и оценивайте, не является ли использование «разработкой конкурирующей модели». Ум — от большой модели, эксплуатация — от малой, но выбор учителя меняет результат технически и юридически. Цифры приведены по открытым материалам, ориентировочно.

В статье «Как построить мультиагентную систему» мы советовали инструментировать каждую передачу управления до добавления агентов; технология, которая обеспечивает это в продакшене, — наблюдаемость ИИ. Она делает видимым то, что LLM и агенты на самом деле делают в продакшене (какая модель с каким промптом, какие инструменты и поиски, что возвращено, сколько времени и денег), чтобы можно было проследить путь до причины. Решающее отличие от обычного мониторинга: ИИ может вернуть 200 OK за 50ms и при этом уверенно галлюцинировать, поэтому большинство сбоев ИИ — это сбои качества (галлюцинации, слабое извлечение, небезопасные ответы, незавершённые задачи, плохое использование инструментов, регрессии после изменения промпта), а не инфраструктуры. Наблюдаемость опирается на три столпа: trace (один запрос как дерево span с вызовами LLM, инструментами, извлечением, цепочками рассуждений; главный элемент наблюдения ИИ), метрики (задержка, стоимость, токены, частота ошибок, пропускная способность) и логи (детали по событиям). Отраслевой стандарт — соглашения GenAI в OpenTelemetry — фиксирует промпты, ответы, использование токенов и вызовы инструментов/агентов в схеме без привязки к вендору, которую можно направить в Datadog/Grafana. Чаще всего путают наблюдаемость и оценку (evals): наблюдаемость показывает, что произошло (легко измерить, но нельзя сказать, верен ли ответ), а evals измеряют, хорош ли ответ (точность, groundedness, безопасность), и требуют явной оценки. Поскольку стоимость и задержку измерить легко, а качество ответа — нет, инструменты 2026 года совмещают показ trace с оценкой выходов и оповещениями о деградации. Метрики делятся на операционные (стоимость, задержка, токены, частота ошибок) и качественные (галлюцинация, groundedness/достоверность, важнейшая для RAG, безопасность, завершение задачи); обнаружение галлюцинаций — через LLM-as-a-judge, семантическое сходство и оценки groundedness. Основные инструменты: LangSmith (LangChain), Langfuse (open-source self-host), Arize Phoenix (отладка RAG), MLflow (жизненный цикл), AgentOps (агенты) и OpenTelemetry (стандарт). Начните со сбора trace (совместимо с OpenTelemetry), визуализируйте операционные метрики, затем подключите evals до выпуска. Для мультиагентных систем наблюдение необходимо, так как сбои прячутся в многошаговых цепочках, видимых только в trace всей сессии. Наблюдать плюс оценивать — вот что делает ИИ продакшен-уровнем. Иллюстрации и характеристики приведены по публичным материалам, как ориентир.

Практическое продолжение статьи «Что такое мультиагентная система?». Главное правило: сначала строить на одном агенте и добавлять агентов минимально, только упёршись в предел (в исследовании Google Research все мультиагентные схемы были на 39–70% хуже на строго последовательной задаче, а Anthropic сообщает, что мультиагентные системы расходуют примерно в 15 раз больше токенов, чем чат). Базовая форма — паттерн supervisor: субагенты в Claude Agent SDK, agents as tools в OpenAI Agents SDK. Помимо 5 шагов (декомпозиция, определение worker, проектирование supervisor, передачи, измерения) — минимальный код для обоих SDK по официальной документации (один supervisor, исследователь и проверяющий), ограничение инструментов каждой роли, три уровня лимитов (maxTurns, max_turns, расходы), когда выбирать handoff, удачные и неудачные разбиения ролей и реальные ошибки Anthropic (50 субагентов на простой запрос, дублирование поиска) с решениями.

Теперь, когда ИИ-агенты стали обыденностью, следующий вызов — как заставить агентов работать сообща. Если MCP соединяет агента с его инструментами, то A2A (Agent2Agent) соединяет агента с другим агентом — это открытый стандарт, позволяющий ИИ, построенным на разных платформах и фреймворках, находить друг друга, общаться и сотрудничать через общую договорённость. Google выпустил его в апреле 2025 года, в июне передал Linux Foundation, и в 2026 году он достиг версии v1.0. Это руководство для новичков объясняет, что такое A2A (аналогия с этикетом делового партнёрства), зачем он нужен (специализированные агенты передают работу по эстафете — агент планирования, агент бронирования отелей, агент оплаты), чем отличается от MCP (MCP — это вертикаль, агент ↔ инструменты; A2A — это горизонталь, агент ↔ агент; совмещение обоих — стандартная двухслойная схема), как это работает (Agent Card — JSON-«визитка» по адресу /.well-known/agent-card.json — используется для обнаружения возможностей, затем Task несёт запрос через состояния working, input-required, completed, а Artifact возвращает результат, и всё это поверх HTTP, Server-Sent Events и JSON-RPC 2.0, причём агенты держат своё внутреннее устройство скрытым), а также каково текущее состояние и реализация (по состоянию на апрель 2026 года: 150+ поддерживающих организаций, 22 000+ звёзд на GitHub, SDK на пяти языках — Python, JavaScript, Java, Go, .NET — при участии Microsoft, Salesforce, SAP и ServiceNow). Запомнить просто: подключение к инструментам = MCP, подключение к равным = A2A.

Вы собрали RAG, но качество поиска посредственное — именно тогда помогает реранкинг. Реранкинг заново оценивает кандидатов, грубо собранных эмбеддинг-поиском (векторным поиском), по их релевантности запросу и переупорядочивает их, оставляя только лучшие; один этот шаг способен резко изменить качество ответов RAG-системы. Этот гид для новичков объясняет, что такое реранкинг (аналогия с первичным отбором и финальным собеседованием), зачем он нужен (эмбеддинг-поиск векторизует запрос и документы по отдельности, поэтому судит о релевантности лишь грубо, а плохой порядок напрямую снижает качество ответа — исследования показывают, что реранкинг может заметно повысить точность поиска, а его наложение поверх гибридного поиска стало стандартом 2026 года), как устроен двухэтапный поиск («собрать широко» быстрым эмбеддинг-поиском ради recall, затем «отсеять умно» реранкером ради precision и передать лучшее LLM), почему реранкер точнее (bi-encoder векторизует запрос и документ по отдельности — быстро, но приблизительно; cross-encoder подаёт их вместе и выдаёт оценку релевантности 0–1, точно, но тяжело — поэтому собирают быстрым bi-encoder и сужают точным cross-encoder), а также модели и реализацию (тип API вроде Cohere Rerank, Voyage и Jina; open-source вроде BGE reranker, mixedbread и FlashRank; и скоринг через LLM вроде RankLLM — просто извлеките 50–100 и сузьте до топ-5). Принцип: собрать широко, отсеять умно и подстроить числа с помощью оценки ИИ.