Разборы · Статья: · Видео: · 20:40
Docling: как превратить PDF, таблицы и картинки в контекст для LLM — локально и дёшево
Доклад инженера Red Hat про open-source-инструмент Docling: почему качество AI-приложения решается на этапе парсинга документов, как извлекать структуру из PDF, таблиц и картинок в markdown/JSON без облака и GPU, и как строить RAG и агентов поверх этого.
Смотреть на YouTube Structuring the Unstructured - Cedric Clyburn, Red Hat
AI Engineer · 20:40
Главы видео — нажми, чтобы перейти к моменту 9
- 0:00 Контекст решает, но данные неструктурированы PDF, презентации, договоры, сканы, таблицы и картинки надо превратить в то, что LLM реально понимает.
- 2:06 Зачем нужна продвинутая обработка документов RAG или fine-tune — данные ключевой ингредиент, а способ обработки определяет, будет ответ верным или нет.
- 3:05 Цена ошибки: фейковый термин в 20 статьях AI склеил два слова из двух колонок отсканированного PDF — и несуществующее слово расползлось по научной литературе.
- 4:01 Три пути: простой парсер, frontier-модель, Docling Дешёвый парсер теряет структуру; frontier-модель точнее, но дорогая и недетерминированная. Нужна золотая середина.
- 5:34 Что умеет Docling Локально: конвертация в markdown/JSON/Pydantic, аннотация картинок через VLM, структурированный вывод (например, поля из инвойса).
- 9:36 Демо: текст, таблицы и картинки из PDF Извлечение восьми таблиц в DataFrame, разбор картинок с подписями, визуализация layout по bounding-box, PII-модель.
- 14:08 Chunkless RAG без векторной базы Индекс — markdown-структура документа; агент в цикле сам находит нужную секцию без embeddings и vector store.
- 16:33 Масштаб: docling serve как REST-сервис Развёртывание микросервисом в контейнере/Kubernetes для потока из сотен тысяч документов.
- 17:27 Docling MCP для агентов MCP-сервер даёт Claude Code, Codex или Cursor инструменты конвертации и генерации документов без знания всех аргументов.
Коротко
Большая часть корпоративных данных заперта в PDF, таблицах и сканах, а качество любого RAG или агента решается не в промпте, а на этапе извлечения этих данных. Docling делает это локально, дёшево и детерминированнее, чем прогон документов через дорогие frontier-модели.
Выжимка голосом
Самое ценное из разбора — за пару минут
Показать текст выжимки Скрыть текст выжимки
Озвучено синтезом речи · голос alena
Объясни проще
Суть без жаргона
Простыми словами
Компьютеру легко работать с аккуратной таблицей в базе данных и трудно — с PDF, презентацией или сканом договора, где текст, картинки и таблицы свалены вперемешку. Чтобы нейросеть могла отвечать по таким документам, их сначала надо аккуратно разобрать на понятные ей куски (обычно в markdown или JSON). Docling — бесплатный инструмент, который делает это прямо на твоём компьютере, без отправки данных в чужое облако и без мощной видеокарты.
Как ребёнку
Представь толстую книжку с картинками, таблицами и подписями. Робот-помощник умный, но читать такую книжку целиком не умеет — ему надо, чтобы кто-то заранее разложил всё по полочкам: тут заголовок, тут таблица, тут картинка и что на ней. Docling — это как аккуратный помощник, который перерисовывает страницы в понятный роботу список, чтобы робот потом правильно отвечал на вопросы.
Аналогия — «это как…»
Это как перевод грузов с поддонов разной формы на стандартные контейнеры. Пока коробки лежат как попало, ни один погрузчик их быстро не возьмёт; но стоит переупаковать всё в одинаковые контейнеры с маркировкой — и любая машина (то есть любая нейросеть) обрабатывает их без ошибок и в разы дешевле.
Зачем это мне
В большинстве компаний ценные знания лежат не в базах данных, а в PDF, договорах, инструкциях и сканах. Если извлекать их неаккуратно, RAG и агенты будут уверенно врать, а исправлять это промптами бесполезно. Понимание, что качество решается на этапе парсинга, экономит недели отладки и деньги на дорогих API.
Для тех, кто в теме
Docling (Linux Foundation) даёт локальный CLI/библиотеку: OCR + layout-модели + VLM-аннотация → унифицированный Pydantic-документ с экспортом в markdown/JSON/HTML/DataFrame, извлечением таблиц, bounding-box визуализацией, PII-моделью и hybrid chunking. Поверх этого — chunkless/agentic RAG, где индексом служит markdown-структура документа (без embeddings и vector store), docling-serve как REST-микросервис для масштаба и MCP-сервер (conversion/generation/manipulation tools) для интеграции с Claude Code/Codex/Cursor. Кейс FinePDFs от Hugging Face: ~50x экономия на CPU против наивного VLM+OCR.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Обработка неструктурированных данных под LLM — одна из горячих тем 2026 года, а Docling активно развивается в Linux Foundation.
Плотный доклад с живыми демо: извлечение таблиц, картинок, chunkless RAG, serve и MCP — от проблемы до продакшн-масштаба.
Chunkless RAG и локальный пайплайн — свежий взгляд, но сам подход к парсингу документов уже есть у ряда конкурентов.
Всё воспроизводимо: pip install, открытый workshop-репозиторий, готовые serve и MCP — можно повторить в тот же день.
Показан весь путь, но многое — на уровне демо; тонкости качества OCR на сложных сканах остаются за кадром.
Кому будет полезно
Чем выше оценка — тем больше пользы для профессии. Разверни — почему.
Для разработчиков RAG-систем и AI-агентов 4.8 /5
Прямое попадание: доклад показывает, что качество ретрива решается на парсинге источника, и даёт chunkless-паттерн плюс MCP для агентной обработки документов.
Для ML-инженеров и дата-инженеров 4.6 /5
Готовый локальный пайплайн для подготовки датасетов и корпусов под fine-tune с понятной экономикой (CPU против VLM) и экспортом в Pydantic/JSON.
Для инженеров по обработке документов в enterprise 4.4 /5
Кейс Red Hat с тысячами PDF продуктовой документации, извлечение таблиц, PII-модель и air-gapped-режим — ровно про их боль.
Для бэкенд-разработчиков 3.9 /5
docling serve превращает конвертацию в REST-микросервис в контейнере/Kubernetes — понятно, как встроить в существующую инфраструктуру.
Для CTO и техлидов 3.7 /5
Помогает оценить, где open-source-локальная обработка выгоднее проприетарных API и облака по стоимости, приватности и детерминизму.
Для технических писателей и специалистов по knowledge management 3.4 /5
Показывает, как оживить архивы документов и картинок через VLM-аннотацию, когда автора-эксперта уже нет в компании.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 Качество AI решается на парсинге, а не в промпте 2:46
Автор смещает фокус: не важно, frontier-модель у тебя или локальная, — если документ разобран криво, ответ будет неверным, и никакой промпт это не спасёт. Обработка данных, а не выбор модели, определяет корректность.
02 Ошибка парсинга размножается и цитируется как факт 3:05
Склейка двух слов из соседних колонок скана породила несуществующий термин, который попал в 20 научных статей и уже цитируется. Плохой парсинг — это не косметика, а источник галлюцинаций, живущих своей жизнью.
03 RAG может работать без векторной базы 14:08
Chunkless RAG переворачивает привычную схему: индексом становится markdown-структура документа, а агент в цикле сам выбирает нужную секцию. Ни embeddings, ни vector store, ни чанкера — меньше движущихся частей.
04 Отправлять PDF во frontier-модель — дорого и хрупко 4:59
При $30 за миллион токенов на тысячах документов счёт быстро выходит из-под контроля, а смена версии модели ломает стабильность структурированного вывода. Локальный детерминированный парсер оказывается практичнее.
05 Мощная обработка документов не требует GPU 8:20
Кейс Hugging Face показывает 50-кратную экономию на CPU против наивного VLM+OCR. Идея «для AI нужна видеокарта» здесь ломается: правильный пайплайн дешевле именно без ускорителей.
Ключевые цитаты
Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале
«Контекст — самый важный аспект создания AI-приложения или агента.»
«Огромное количество данных мы не можем использовать нормально просто потому, что они лежат в неструктурированных форматах.»
«Неструктурированные данные становятся новым слоем контекста для AI.»
«То, как вы обрабатываете данные, — ключевой фактор того, будет ответ верным или неверным для пользователя.»
«Двадцать научных статей теперь содержат бессмысленный термин, которого не существует, потому что AI неверно прочитал старую отсканированную статью.»
«Docling — это быстро, дёшево и, самое главное, локально.»
«На CPU это дало пятидесятикратную экономию по сравнению с наивным использованием VLM и OCR.»
«Индексом в итоге становится markdown-структура самого документа.»
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
1 Прогони свой худший PDF через Docling до выбора модели
15 минут увидишь, теряется ли структура ещё до того, как винить LLM
Прогони свой худший PDF через Docling до выбора модели
Прежде чем платить за дорогую модель, проверь, как вообще парсится твой сложный документ с таблицами и картинками. Часто проблема не в LLM, а в том, что на вход ей идёт каша.
Что делать
- 1 pip install docling.
- 2 Возьми самый неудобный реальный документ: скан, инвойс, отчёт с таблицами.
- 3 Сконвертируй в markdown и глазами сравни таблицы и заголовки с оригиналом.
2 Извлекай структуру, а не плоский текст
30 минут таблицы и поля становятся пригодны для точных вопросов и валидации
Извлекай структуру, а не плоский текст
Простой PDF-парсер выдаёт линейную кашу, где таблица нечитаема. Используй извлечение таблиц в DataFrame и структурированный вывод, чтобы вытащить конкретные поля (номер счёта, сумму), а не весь документ подряд.
Что делать
- 1 Прогони документ через DocumentConverter.
- 2 Вытащи таблицы через export в DataFrame.
- 3 Для инвойсов задай Pydantic-схему с нужными полями.
3 Считай стоимость парсинга на масштабе, а не на одном файле
20 минут поймёшь, где локальный CPU-пайплайн выгоднее облачной модели в разы
Считай стоимость парсинга на масштабе, а не на одном файле
На одном PDF frontier-модель кажется дешёвой. Умножь на тысячи документов и на выходные токены — и локальная обработка на CPU может выиграть десятки раз, как в кейсе FinePDFs.
4 Попробуй chunkless RAG до векторной базы
1 день меньше инфраструктуры и точнее ответы на структурированных документах
Попробуй chunkless RAG до векторной базы
Для документов с чёткой структурой не спеши строить embeddings и vector store. Дай агенту markdown-оглавление и позволь ему в цикле выбирать релевантные секции — часто хватает пары итераций.
Что делать
- 1 Сконвертируй документ в Docling-структуру.
- 2 Сформируй индекс из markdown-оглавления с краткими саммари секций.
- 3 Запусти агента в цикле на 3–5 итераций поиска нужной секции.
5 Аннотируй картинки и диаграммы через VLM
вечер изображения перестают быть чёрными дырами в RAG
Аннотируй картинки и диаграммы через VLM
Картинки и схемы в документах обычно теряются. Прогони их через локальную vision-модель (например, Granite через Ollama), чтобы получить текстовое описание, пригодное для поиска и ответов.
6 Разверни docling serve для потока документов
полдня конвертация становится масштабируемым сервисом, а не скриптом
Разверни docling serve для потока документов
Когда документов сотни тысяч, оберни Docling в REST-микросервис через docling serve и запусти в контейнере или Kubernetes, передавая опции (OCR, backend, аннотация картинок) в запросе.
7 Подключи Docling MCP к своему агенту
1 час агент обрабатывает документы сам, без знания всех аргументов CLI
Подключи Docling MCP к своему агенту
Добавь Docling MCP-сервер в конфиг Claude Code, Codex или Cursor. Тогда агент через conversion/generation/manipulation-инструменты сам конвертирует и собирает документы по запросу вроде «сделай саммари этого PDF».
Что делать
- 1 Подними Docling MCP-сервер через uvx.
- 2 Добавь MCP-сервер в config.yaml своего агента.
- 3 Проверь на команде «конвертируй документ и дай саммари».
8 Оставляй обработку локальной для чувствительных данных
10 минут приватные документы не уходят на чужой сервер
Оставляй обработку локальной для чувствительных данных
Если данные под NDA, комплаенсом или в air-gapped-контуре, проприетарные облачные парсеры не вариант. Локальный Docling закрывает эту нишу без отправки PDF наружу.
Сценарии применения
Как разные люди применяют это на практике
Я как Разработчик RAG-ассистента по документации
Проблема: бот уверенно врёт, потому что таблицы и заголовки из PDF пришли в виде каши
Хочу: получить чистую структуру документа, а не плоский текст
Поможет: извлечение таблиц и layout-разбор дают ретриву пригодный контекст, ошибки падают у источника
Я как ML-инженер, готовящий датасет
Проблема: нужен большой корпус из веб-PDF, но VLM+OCR в лоб слишком дорого
Хочу: дешёвый способ извлечь структуру из тысяч документов
Поможет: кейс FinePDFs показывает пайплайн на CPU с 50-кратной экономией
Я как Инженер в enterprise с тысячами продуктовых PDF
Проблема: знания заперты в документации, договорах и сканах
Хочу: превратить всё это в markdown/JSON под внутренний AI
Поможет: локальный пакетный пайплайн Docling, как у команды Red Hat
Я как Основатель стартапа с чувствительными данными
Проблема: нельзя отправлять договоры клиентов в чужое облако
Хочу: обрабатывать документы у себя, без внешнего сервиса
Поможет: open-source и air-gapped-режим закрывают приватность без API
Я как Дата-инженер, автоматизирующий инвойсы
Проблема: из счетов нужны конкретные поля, а не весь текст
Хочу: структурированный вывод по заданной схеме
Поможет: Pydantic-экспорт вытаскивает номер счёта и сумму без лишнего мусора
Я как Исследователь, пишущий с помощью AI
Проблема: боится, что модель исказит данные из отсканированной статьи
Хочу: убедиться, что текст извлечён без склеек и галлюцинаций
Поможет: пример с фейковым термином показывает, почему детерминированный парсинг критичен
Я как Бэкенд-инженер платформы
Проблема: конвертация документов живёт как хрупкий скрипт
Хочу: вынести её в масштабируемый сервис
Поможет: docling serve даёт REST-микросервис для контейнера или Kubernetes
Я как Разработчик автономного агента
Проблема: агенту нужно работать с документами, но CLI-аргументов слишком много
Хочу: дать агенту инструменты обработки документов из коробки
Поможет: Docling MCP-сервер подключается к Claude Code или Cursor парой строк конфига
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка Контекст решает всё, но данные неструктурированы 0:00
Большая часть корпоративных знаний лежит в PDF, сканах, таблицах и картинках, которые LLM напрямую не понимает.
-
Аргумент Способ обработки данных определяет корректность ответа 2:46
Не модель, а качество парсинга источника решает, будет ответ верным или галлюцинацией.
-
Пример Кривой парсинг породил фейковый термин в 20 статьях 3:05
Склейка колонок скана создала несуществующее слово, которое расползлось по научной литературе.
-
Аргумент Ни простой парсер, ни frontier-модель не подходят 4:01
Дешёвый парсер теряет структуру; frontier-модель точнее, но дорогая, недетерминированная и хрупкая при смене версий.
-
Аргумент Docling — локальная золотая середина 5:34
OCR + layout + VLM превращают документ в Pydantic-структуру с экспортом в markdown/JSON, локально и дёшево.
-
Пример 50-кратная экономия на CPU против VLM 8:20
Кейс Hugging Face FinePDFs: массовая обработка без GPU выходит в разы дешевле наивного VLM+OCR.
-
Аргумент Структура открывает chunkless RAG и агентов 14:08
Индекс — markdown-оглавление документа; агент сам находит секции, а serve и MCP выводят всё в продакшн и в агентные харнессы.
-
Вывод Локально, дёшево, open-source — фундамент для RAG и агентов 19:20
PDF → markdown/JSON без облака и GPU становится надёжной основой AI-приложений.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Подробный разбор
Главный тезис доклада простой и неудобный: сколько бы вы ни улучшали модель и промпт, качество AI-приложения обычно упирается в то, как разобран исходный документ. Автор — инженер Red Hat — показывает это на болезненном примере: неверное чтение отсканированной статьи склеило два слова из соседних колонок, породив несуществующий термин, который затем попал в двадцать научных работ и стал цитироваться. Плохой парсинг — это не косметика, а фабрика галлюцинаций.
Дальше он раскладывает три пути обработки. Простой PDF-парсер быстр и бесплатен, но выдаёт линейную кашу, где таблица нечитаема даже человеком. Frontier-модель точнее, но при $30 за миллион токенов и тысячах документов дорога, а смена версии ломает стабильность структурированного вывода. Золотая середина по версии автора — Docling: локальная библиотека и CLI (Linux Foundation), которая через OCR, анализ layout и vision-модели превращает документ в типизированную Pydantic-структуру с экспортом в markdown, JSON, HTML и DataFrame.
Практическая часть плотная: извлечение восьми таблиц из PDF в датафреймы, разбор картинок с подписями и текстовыми элементами, визуализация элементов по bounding-box, отдельная модель для вычистки персональных данных и VLM-аннотация изображений через локальный Granite и Ollama. Отдельно автор показывает chunkless RAG, где индексом служит markdown-оглавление документа, а агент в цикле сам находит нужную секцию — без чанкера, embeddings и векторной базы. Для продакшна есть docling serve (REST-микросервис) и MCP-сервер, который отдаёт агентам вроде Claude Code или Cursor инструменты обработки документов.
Стоит ли смотреть целиком
Да, если вы строите RAG, готовите датасеты или тащите корпоративные документы в AI и устали от того, что бот врёт на таблицах и сканах. Двадцать минут дают и понятную рамку («качество решается на парсинге»), и конкретный воспроизводимый инструмент с открытым workshop-репозиторием.
Держите в голове, что это доклад-витрина: альтернативы поданы как соломенные чучела, а chunkless RAG показан на удобных данных и умолчит про пределы контекста и стоимости на больших коллекциях. Но как отправная точка и как повод перестать винить модель за то, что виноват парсер, материал полезен.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 6
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. Где, по мнению автора, в первую очередь решается качество AI-приложения?
-
2. Как в докладе возник несуществующий научный термин в 20 статьях?
-
3. Что такое chunkless RAG в изложении автора?
-
4. Какую экономию дал Docling в кейсе Hugging Face FinePDFs?
-
5. Зачем нужен docling serve?
-
6. Что даёт Docling MCP-сервер?
Словарь терминов
Понять незнакомое простым языком
Показать 9 терминов Свернуть словарь
- Неструктурированные данные
- Информация без строгой схемы: PDF, сканы, презентации, картинки, письма. Противоположность аккуратным строкам и колонкам в базе данных.
- OCR
- Оптическое распознавание символов — превращение картинки с текстом (например, скана) в редактируемый текст.
- RAG
- Retrieval-Augmented Generation — подход, где модель перед ответом достаёт релевантные куски из твоих документов, чтобы отвечать по фактам, а не по памяти.
- Chunking (чанкинг)
- Нарезка документа на небольшие фрагменты, чтобы их удобно было искать и подавать модели.
- VLM (vision language model)
- Модель, которая понимает и текст, и изображения: может описать словами, что нарисовано на картинке или схеме.
- Pydantic
- Python-библиотека для описания структуры данных по схеме. Docling отдаёт документ как типизированный объект, из которого удобно доставать поля.
- MCP (Model Context Protocol)
- Стандарт, по которому AI-агент подключает внешние инструменты и сервисы, не зная деталей их запуска.
- Air-gapped
- Изолированный контур без доступа в интернет. В нём облачные сервисы недоступны, поэтому важна локальная обработка.
- Docling
- Open-source-инструмент (Linux Foundation) для локального превращения документов в markdown, JSON и типизированную структуру.
Критический взгляд
Объективно: с какими тезисами можно поспорить и что преувеличено
Доклад по сути — витрина одного инструмента от Red Hat
Альтернативы (Unstructured.io, LlamaParse, Marker, облачные Document AI) не сравниваются честно, а показываются как «простой парсер» или «дорогая модель». Реальный выбор богаче, чем «Docling против всего плохого».
Chunkless RAG красив на демо, но упрётся в контекст и стоимость
Прогонять всю markdown-структуру через LLM хорошо на одном документе с 418 секциями, но на тысячах документов это раздувает контекст и цену. Векторные базы существуют не просто так — автор об этом ограничении умалчивает.
50-кратная экономия — это один конкретный кейс, а не гарантия
Цифра из FinePDFs зависит от типа документов, железа и настроек. Подавать её как универсальное свойство Docling некорректно — на других данных выигрыш может быть скромнее.
Аргумент про хрупкость frontier-моделей бьёт и по Docling
Смена версий модели ломает стабильность вывода — верно, но модели OCR и layout в самом Docling тоже обновляются, а детерминизм OCR на сложных сканах не абсолютен. Локальность не равна безошибочности.
Качество показано на удобных примерах
Демо идёт на собственном research paper Docling и чистых таблицах. Рукописный текст, плохие сканы, многоязычные и повёрнутые страницы — самый больной класс — в докладе не проверяются.
Взгляни иначе
Новый угол, смежные области и потенциал на стыке — пища для размышлений
Парсинг документов — это новый ETL эпохи LLM
Раньше данные чистили и грузили в хранилище перед аналитикой; теперь тот же смысл переносится на подготовку неструктурированного корпуса для моделей. Docling и его аналоги — это ETL-слой, который в BI-мире был отдельной зрелой индустрией.
Спасение архивов и библиотек на стыке с историей
Тот же пайплайн, что готовит корпоративные PDF, применим к оцифровке исторических документов, газет и рукописей с сохранением структуры таблиц и подписей. Здесь AI-инженерия встречается с архивным делом и цифровыми гуманитарными науками.
Рост контекстных окон подтачивает часть RAG-индустрии
Если chunkless-подход работает, значит длинные контексты и умные агенты постепенно съедают нишу векторных баз и embedding-пайплайнов. Стоит спросить, во что вкладываться: в инфраструктуру ретрива или в качество исходной структуры.
Чистый структурированный корпус ценнее самой модели
Когда все имеют доступ к похожим open-weight-моделям, конкурентным преимуществом становится не модель, а качество и структура собственных данных. Инвестиция в парсинг — это инвестиция в актив, а не в расходник.
Локальная обработка как ответ комплаенсу, а не только кошельку
В юр-, мед- и госсекторе главный аргумент за Docling — не цена, а то, что документ физически не покидает контур. Локальность превращается из технической детали в юридическое требование.
Похожие разборы
Почему нейросети любят Markdown: как хранить документы, чтобы ИИ их понимал
Нейросеть никогда не видит ваш файл так, как вы: она читает голый текст со всей технической обёрткой, а каждый лишний символ съедает токены и место в разговоре. Markdown убирает обёртку и оказывается для ИИ родным языком, поэтому документы, заметки и даже схемы удобнее держать именно в нём.
Читать → РазборDomain-specific агенты: почему будущее за роем узких ИИ, а не за одним всемогущим
Компании пытаются интегрировать ИИ, навешивая на один большой агент всё больше MCP и skills — и упираются в раздувание контекста и хрупкость. Автор доказывает, что будущее за композицией: рой узких доменных агентов, каждый со своей моделью, инструментами и памятью, координируемых на обычном языке — это дешевле, безопаснее и масштабируется.
Читать → РазборМодель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов
При переходе от чатботов к автономным агентам узкое место смещается с интеллекта модели на надёжность инфраструктуры вокруг неё. Модель должна лишь предлагать действия, а проверять, одобрять и исполнять их обязана детерминированная платформа — и именно она, а не лучший промпт, становится конкурентным преимуществом.
Читать → РазборАгент со 100 инструментами — это ловушка: почему точность падает и как её вернуть роутингом
Если сваливать в промпт все определения инструментов сразу, агент тонет в контексте: на 741 инструменте точность выбора падает до 13,6%, а промпт раздувается до 127 000 токенов ещё до вопроса пользователя. Лечится это семантическим роутингом — ретривом 3–5 релевантных инструментов под конкретный запрос, который держит точность выше 83% и режет токены на инструменты почти на 99%.
Читать →