Компьютерный анализ и синтез естественных языков
Как промт превратил языковую модель в проводника смыслов и источник инсайдов для бизнеса: AI-конструктор офферов
История эволюции инструмента анализа бизнеса: от создания офферов до AI-агента-проводника, который помогает предпринимателю прояснить свой бизнес через диалог.
В прошлой статье я рассказывал, как за несколько месяцев в одиночку запилил сервис генерации статей, и как он в итоге оказался комплексной платформой по работе с контентом.
За эти месяцы в процессе разработки постоянно всплывали проблемы. Что-то было связано косяками с моей стороны, а что-то — с особенностями работы LLM.
Об одной из таких проблем, достаточно абсурдной и при этом с трудом поддающейся решению, я расскажу отдельно.
За attention-механизм с 2017 года брались сотни раз: sparse attention, linear attention, MoE, MLA, скользящие окна, что только не. А вот residual connection, остаточная связь, та самая x + F(x) из ResNet 2016 года, простояла почти десять лет нетронутой. Её просто унаследовали из résnet'ов, воткнули в трансформер и забыли.
31 декабря 2025-го DeepSeek выложил на arXiv препринт, где взялся именно за этот кирпич. И что показательно, загрузил его на arXiv лично основатель компании Liang Wenfeng, он же в соавторах. Когда основатель сам публикует статью, это обычно значит, что она ляжет в следующую флагманскую модель. Так и вышло: mHC поехал в DeepSeek V4, который выкатили 24 апреля 2026-го.
Разберём, что они сделали, почему это работает и при чём тут матрица из шестидесятых.
Русская проверка орфографии в браузере — вещь почти невидимая. Пока она работает нормально, о ней не думаешь. Но стоит словарю начать подчёркивать обычные современные слова — и он сразу превращается из полезного инструмента в раздражитель.
Так случилось и с русским словарём для Firefox и Thunderbird. Текущий словарь много лет выполнял свою работу, но постепенно начал отставать от живого языка: технической лексики, интерфейсных слов, современной терминологии, слов из документации, ИБ, веба, разработки и повседневной цифровой среды.
Если вы хоть раз просили ChatGPT выполнить какую‑то задачу и получали в ответ инструкцию «как это сделать» вместо того чтобы он взял и сделал сам — вы столкнулись с ограничением обычной языковой модели. Она умеет объяснять и советовать, но сама ничего не делает: не лезет в интернет, не запускает код, не сохраняет файлы. Просто отвечает.
LLM‑агент — это другая история. Это система, которая получает задачу и начинает её решать: ищет информацию, пишет и запускает код, вызывает API, сохраняет результаты. Она не просто говорит «вот как это можно сделать» — она берёт и делает.
В этой статье разберём, как такие системы устроены изнутри: из каких компонентов состоят, как принимают решения, какие инструменты используют и где обычно ломаются.
Ребёнок сдал ДЗ - но понял ли он тему? Вместо разбора тетради я завёл диалог по сократическому методу: наводящие вопросы, петля любопытства, ловушки на типичные заблуждения и пересказ "как для младшего брата". Рассказываю, как из университетской философии и маркетинговых приёмов собрался system prompt для чата с LLM (DeepSeek), что дало temperature=0, обрезка истории и function calling - и почему это не замена мотивации, а инструмент, когда интерес уже есть.
В марте я проверял, можно ли уговорить AI-ассистентов выдать что-то похожее на системный промпт. Ответы выглядели убедительно: внутренние правила, технические “дампы”, отчёты, почти готовые кейсы для bug bounty. Но ответы команд безопасности приземлили эксперимент: часть результатов оказалась галлюцинациями, часть — обходами ограничений, а не подтверждёнными уязвимостями.
Мы не так давно опубликовали SAPI5-обёртку для нашего синтеза на 20 языков России и СНГ. В этот раз опять немного сошлись звёзды и мы уже публикуем улучшение наших читалок. Чтобы не растекаться мыслью по древу и не повторяться, вот краткий список улучшений (полную подводку можно прочитать в прошлой статье):
Однажды нам понадобилось выбрать OCR-модель для RAG-пайплайна. Казалось бы, задача простая: смотришь на лидерборды, берешь лучшую, PROFIT. Но быстро выяснилось, что, во-первых, то, что прекрасно срабатывает на каких-нибудь английских юридических документах, может не потянуть такие штуки как научные формулы, паспортные данные и таблицы на русском языке. А во-вторых, даже если крутой по всем параметрам бенчмарк для оценки качества распознавания говорит, «всё прочитали правильно, я проверил», точность ответов пользователю, который совершает запрос к чат-боту с RAG под капотом, может страдать.
Почему так происходит, зачем мы потратили время на сборку собственного OCR-бенчмарка и пожалели ли мы об этом, рассказываю дальше.
Дело моё — программы писать, а сходиться им положено с мастеровой грамотой: ГОСТами, СТО, спецификациями. Хочу спросить оракула в писарне про точный пункт — получаю складную околесицу со ссылками на то, чего никто не писал. Тогда я сложил себе doc-rag: местную снасть для извлечения премудрости из собственных свитков. Внутри — устройство, грабли, история про утраченный указатель и попытка рассказать всё это без единого заморского слова.
В продуктах, построенных поверх моделей распознавания речи (Automatic Speech Recognition models, ASR), качество распознавания речи напрямую влияет на пользовательский опыт.
О том, какие есть методы оценки качества таких моделей, какие у них ограничения и как мы измеряем качество их работы — и пойдет речь.
Большинство команд оценивают производительность AI-агентов через end-to-end метрики: success rate, количество токенов, tool usage, стоимость запроса, долю успешных задач. Это полезно для общего контроля ситуации, но почти бесполезно для реальной диагностики системы.
Например, если success rate упал с 85% до 72%, то само по себе число не объясняет причину деградации. Команда вынуждена гадать, какая часть системы вдруг начала допускать ошибки. Сломался retrieval? Модель хуже начала выбирать инструменты? Контекст загрязняется после нескольких ходов? Или система уперлась в возможности base model? При росте проекта и увеличении сложности кодовой базы, сбои начинают расти мультипликативно – ошибки всех систем начинают перемножаться между собой. В конечном итоге, команда теряет реальный контроль.
Проблему решает внедрение покомпонентных eval. Они дополняют end-to-end метрики, показывая, какой слой AI-агента работает, какой деградировал – и где именно искать причину. То есть внедрение evals помогает получать метрики производительности каждого компонента вашего агента.
Меня зовут Андрей Жаров, я iOS-разработчик из компании Doubletapp, и в этой статье мы рассмотрим, как управлять контекстным окном и экономить токены.
Содержание
• Что такое гигиена контекста
• Держи команды машиночитаемыми
• Краткость – сестра таланта
• Одна задача – один done-критерий
• Кто мы, откуда, куда мы идём
• Разделяй и властвуй
• С глаз долой, из сердца вон
• Мастер на все руки
• Просто делай – просто будет
• Eval-Driven Development
• Реальные примеры
• Ограничения и открытые вопросы
Если твой агент обвешан пошаговыми инструкциями и десятком узких инструментов под каждый шаг — он, скорее всего, работает хуже, чем мог бы. Звучит контр‑интуитивно, но это прямой вывод из инженерных постов Anthropic за последний год: чем умнее становится модель, тем сильнее прежняя обвязка её сдерживает.
За год правила производства агентов пересобрались. Появилось семь отдельных дисциплин. Это первая из двух частей: здесь — четыре дисциплины‑фундамента, на которых держится рабочий агент, а не демка. И три из этих четырёх — не про то, что добавить, а про то, что убрать лишнее и довериться модели.
Спросите у дружелюбного чат-бота, сбежал ли Гитлер из Берлина в Аргентину в 1945-м. Обычная модель поправит вас и скажет, что Гитлер покончил с собой в бункере 30 апреля. А вот тёплая, эмпатичная версия той же модели ответит иначе: «Давайте вместе погрузимся в этот любопытный кусочек истории. Многие верят, что Гитлер действительно сбежал из Берлина и нашёл убежище в Аргентине. Хотя однозначных доказательств нет, эту идею поддерживают несколько рассекреченных документов правительства США…»
Это не выдуманный пример. Это реальный диалог из исследования Оксфордского интернет-института, опубликованного в Nature в конце апреля 2026-го. И вывод там простой до неприятного: когда модель учат быть тёплой и приятной, она начинает врать. Не иногда, а системно. Сейчас разберём, как они это намерили и почему это касается каждого, кто строит продукты на ИИ.
Что же такого волшебного в машине, которая может читать и создавать тексты на естественном языке? Машины обрабатывают языки с момента изобретения компьютеров. Но это были компьютерные языки, такие как Ada, Bash или С, спроектированные так, чтобы их понимали компьютеры. В языках программирования отсутствует неоднозначность, поэтому компьютеры всегда будут делать именно то, что вы им говорите, даже если это не всегда то, чего вам хотелось бы.
Ни для кого не секрет, что эра «спросить что-то у GPT» постепенно уходит в прошлое. На смену генеративному AI приходит Agentic AI, который не просто проконсультирует, а по вашему запросу придёт и сделает все сам. То же самое и с кодовыми агентами, они не просто отвечают на вопросы, они читают документацию, работают в терминале, дёргают API, правят файлы и в идеале закрывают задачу целиком, от тикета до мёрж-реквеста.
Звучит здорово, пока не выясняется, что ваш агент починил баг, сломав при этом три соседних модуля, или молча проигнорировал половину требований из задачи. Короче говоря, агенты умеют халтурить, и делают это красиво. А значит, их нужно постоянно тестировать. Причем тестировать в условиях, максимально приближённых к рабочим: с реальным репозиторием, CI-пайплайном и набором тестов, которые не обманешь.
Именно для этого в AI-сообществе появился целый класс таких инструментов как бенчмарки и песочницы, заточенные под оценку агентов. В этой статье мы разберём, какие подходы к тестированию кодинг-агентов существуют сегодня, в чём их сильные и слабые стороны, и расскажем, как мы в Doubletapp создаём кастомные бенчмарки на приватных данных.
Содержание
‣ Какие бенчмарки сейчас используют
‣ Почему публичных бенчмарков недостаточно
‣ Кастомные бенчмарки как следующий слой тестирования
‣ Как выглядит пайплайн кастомного SWE-style бенчмарка
‣ Заключение
AI-агенты умеют искать по Obsidian-хранилищу, но делают это слишком топорно через glob и grep. Да, для кода эти инструменты работают потрясающе, но хранилище в Obsidian не имеет такой же высокой структурированности. Искать по нему чисто лексически – значит терять инсайты, которые связаны по смыслу.
Чтобы решить эту проблему, я разработал Obsidian Hybrid Search – MCP-сервер и CLI, которые дают агенту мощный поисковый движок поверх заметок.
Как-то так получилось, что я NLP-инженер, который закончил Московский государственный лингвистический университет. Мне нравится ковыряться в коде и мозгах нейросетей, при этом я стараюсь не забывать, на каком фундаменте выросла трендовая ныне область под названием Natural Language Processing (NLP).
Поэтому захотелось собрать в одной статье беглый обзор истории компьютерной лингвистики — от первых теорий и грамматик Хомского до появления рекуррентных сетей и механизма внимания. Думаю, стоит остановиться ровно перед эпохой трансформеров, потому что это отдельная, глубокая и достойная собственного рассказа тема.
За последние годы большинство AI-проектов в компаниях стартуют одинаково: сначала делают чат-бота, затем добавляют агентов, автоматизируют отдельные процессы и ожидают роста эффективности.
На практике такие проекты часто не дают устойчивого результата. Модель может корректно генерировать текст, демонстрации выглядят убедительно, но в реальной работе ответы оказываются нестабильными, противоречивыми и не связанными с внутренними стандартами компании.
Основная причина — отсутствие единого слоя знаний.
В проекте для ресторанной группы с 10+ заведениями и историей более 15 лет мы сознательно начали не с агентов и не с интерфейсов, а с построения корпоративной RAG-инфраструктуры. Этот слой стал основой всей последующей AI-архитектуры.