Natural Language Processing *

Что же такого волшебного в машине, которая может читать и создавать тексты на естественном языке? Машины обрабатывают языки с момента изобретения компьютеров. Но это были компьютерные языки, такие как Ada, Bash или С, спроектированные так, чтобы их понимали компьютеры. В языках программирования отсутствует неоднозначность, поэтому компьютеры всегда будут делать именно то, что вы им говорите, даже если это не всегда то, чего вам хотелось бы.

Ни для кого не секрет, что эра «спросить что-то у GPT» постепенно уходит в прошлое. На смену генеративному AI приходит Agentic AI, который не просто проконсультирует, а по вашему запросу придёт и сделает все сам. То же самое и с кодовыми агентами, они не просто отвечают на вопросы,  они читают документацию, работают в терминале, дёргают API, правят файлы и в идеале закрывают задачу целиком, от тикета до мёрж-реквеста.

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

Именно для этого в AI-сообществе появился целый класс таких инструментов как бенчмарки и песочницы, заточенные под оценку агентов. В этой статье мы разберём, какие подходы к тестированию кодинг-агентов существуют сегодня, в чём их сильные и слабые стороны, и расскажем, как мы в Doubletapp создаём кастомные бенчмарки на приватных данных.

Содержание
‣ Какие бенчмарки сейчас используют
‣ Почему публичных бенчмарков недостаточно
‣ Кастомные бенчмарки как следующий слой тестирования
‣ Как выглядит пайплайн кастомного SWE-style бенчмарка
‣ Заключение

AI-агенты умеют искать по Obsidian-хранилищу, но делают это слишком топорно через glob и grep. Да, для кода эти инструменты работают потрясающе, но хранилище в Obsidian не имеет такой же высокой структурированности. Искать по нему чисто лексически – значит терять инсайты, которые связаны по смыслу.

Чтобы решить эту проблему, я разработал Obsidian Hybrid Search – MCP-сервер и CLI, которые дают агенту мощный поисковый движок поверх заметок.

GitHub + Obsidian Plugin

Как-то так получилось, что я NLP-инженер, который закончил Московский государственный лингвистический университет. Мне нравится ковыряться в коде и мозгах нейросетей, при этом я стараюсь не забывать, на каком фундаменте выросла трендовая ныне область под названием Natural Language Processing (NLP).

Поэтому захотелось собрать в одной статье беглый обзор истории компьютерной лингвистики — от первых теорий и грамматик Хомского до появления рекуррентных сетей и механизма внимания. Думаю, стоит остановиться ровно перед эпохой трансформеров, потому что это отдельная, глубокая и достойная собственного рассказа тема. 

За последние годы большинство AI-проектов в компаниях стартуют одинаково: сначала делают чат-бота, затем добавляют агентов, автоматизируют отдельные процессы и ожидают роста эффективности.

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

Основная причина — отсутствие единого слоя знаний.

В проекте для ресторанной группы с 10+ заведениями и историей более 15 лет мы сознательно начали не с агентов и не с интерфейсов, а с построения корпоративной RAG-инфраструктуры. Этот слой стал основой всей последующей AI-архитектуры.

В 2023 году мы рассказывали, как в Поиске по архивам появилось распознавание рукописных документов и почему сама по себе расшифровка архивного текста — нетривиальная задача. Старые почерки, сложная вёрстка, нестандартные формулировки и огромное разнообразие источников делают архивы трудным доменом даже для сильных OCR‑моделей. 

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

Теперь в Поиске по архивам работает новая модель распознавания документов. Она не только распознаёт текст архивного файла, но и структурирует информацию из него. Например, понимает роли и связи между разными людьми: «родившийся», «отец» и «мать» для рождения или «жених», «невеста», «свидетель» для брака. 

Меня зовут Даша Виноградова, я руковожу универсальными применениями компьютерного зрения в Яндексе. Вместе с Аней Сидоровой, главным разработчиком распознавания архивов, мы расскажем, как мы сделали шаг от распознавания текста к извлечению структуры и смысла из архивных документов: как мы перестраивали OCR‑пайплайн, почему нам не подошли универсальные VLM‑модели и как пытались разобраться, кто есть кто: отец, мать, жених или свидетель.

PM: Нам нужно актуализировать базу знаний для ИИ-ассистента,
там изменилась инструкция по смене пароля.
DevOps: Не проблема, сейчас запущу скрипт, через два часа всё обновится.
Предупреди Заказчика о недоступности сервиса.

Знакомая ситуация? Полная зачистка векторной базы и реиндексация всех имеющихся документов с остановкой сервиса - решение простое и надёжное, но «прощается» только на этапе прототипа.

В продакшене могут быть сотни тысяч документов, живые пользователи и SLA с требованием по доступности сервиса. Обновилась одна, пусть и очень важная инструкция, и сервис недоступен два часа. А если таких обновлений десятки в неделю? Давайте исправим это и напишем ETL-скрипт, который умеет добавлять, обновлять и удалять отдельные документы без остановки сервиса.

Представьте внутреннего AI-агента, который помогает компании искать общие документы и управлять ими. Он работает. До тех пор, пока 12–15% запросов не начинают падать. Агент возвращает не тот документ, редактирует не тот файл, молча падает или уверенно ссылается на файл, которого не существует. Поиск по фото отказывает с той же частотой. Ошибки размазаны равномерно по пользователям, фичам и запросам.

Первое инстинктивное действие — поменять модель. Opus 4.5, GPT 5.5 или что там сейчас в топе лидерборда. Меняете. Счет за инференс растет в 4–5 раз, а общая доля ошибок снижается с 12% до 9%. Пользователи пишут о тех же проблемах. Бюджет следующего квартала сгорает за пару недель ради улучшения в 3 процентных пункта — и вы по-прежнему не понимаете, что именно было не так в системе и как улучшать ее дальше.

Эта статья — о том, почему смена модели обычно разочаровывает и куда стоит смотреть в первую очередь. Большинство сбоев AI-систем живет в слое обвязки — orchestration, retrieval, tool definitions, retries, context management, — а не в самой модели. Дальше — метод, как отличить проблемы обвязки от проблем модели, кейс, в котором одно исправление в обвязке подняло completion rate с 26% до 88% без смены модели, и чек-лист, который помогает находить такие сбои в вашей собственной системе. Если вы никогда не делали подобной диагностики — ожидайте найти хотя бы один пункт, который стоит починить.

Представьте себе типичное совещание. Кто-то из руководства возвращается с конференции, садится напротив и говорит: «У них там бот по внутренней документации, надо себе такой же. До конца квартала».

Через четыре месяца у тебя есть Pinecone, OpenAI API, две недели работы над парсингом PDF и чат-бот, который на демо отвечает на пять подобранных вопросов идеально. А на шестой, который задаст любой нормальный сотрудник, отвечает уверенным бредом.

Дальше про то, что именно между этими двумя состояниями происходит. Но без «правильной архитектуры RAG», потому что такой не существует.

При разработке ИИ-агента для базы знаний, мне казалось, что задача почти типовая: складываем информацию в Qdrant, находим информацию через векторный поиск и поиск в интернете и формируем красивый ответ через LLM. На деле ИИ-агент начал уверенно галлюцинировать, приносить не только нерелевантные ответы, но и тупить с короткими пользовательскими запросами. И самое неприятное, при всем при этом метрика «похожести» similarity выглядела достаточно высокой, что сильно вводило в заблуждение.

После серии экспериментов и улучшений пришло понимание, что промышленный ИИ-агент — это не столько про LLM, сколько про качество извлечения информации и гибкую оркестрацию компонентов ИИ-агента. Что в итоге полностью поменяло архитектуру моей системы.

В статье расскажу, как я пришла от «просто добавь LLM» к промышленному графовому ИИ-агенту на LangGraph + Qdrant.

Обычно внедрение AI в компаниях происходит по такому сценарию: собрали одного ассистента, показали руководству, получили аплодисменты. Потом второго, третьего — и через полгода получается зоопарк с разными ключами, моделями и неконтролируемым бюджетом.

Вместо набора разрозненных ассистентов мы сразу пошли в платформу. В статье рассказываем, из чего она состоит, как эволюционировало наше железо, зачем понадобилось два слоя наблюдаемости и почему маркетплейсный RAG ломается на PDF-файлах. С графиками, схемой архитектуры и выводами, которые сами хотели бы прочитать год назад.

Всё началось с наивной мысли: зачем платить за API или тащить 7B-модель, если мне нужна маленькая модель для простых разговоров на одном языке? Логика казалась железной — большие модели умеют всё и на всех языках сразу, но это же избыточно. 0.7B, заточенная под один язык и один стиль общения, должна справляться не хуже.

Спойлер: это было наивно. Но путь оказался ценнее результата.

«make no mistakes» и «write if you need more context» – фразы, которые я до сих пор могу напечатать на клавиатуре с завязанными глазами, потому что они способны помочь выжать из ChatGPT рабочий код, а если Deep Thinking подключить, то вообще сказка, разве нет?

Меня зовут Андрей Жаров, iOS-разработчик из Doubletapp. За последние несколько месяцев я прошёл путь от чата до агентского флоу. Данный опыт применим практически к любому направлению разработки, тут не будет iOS-специфичного материала. Я не буду рассказывать, как вкатиться в AI с полного нуля или как завайбкодить приложение, а предлагаю разобраться, в чём разница между вайбкодингом и инженерным подходом. Давайте вспомним сначала, как индустрия шла от написания кода в ChatGPT к локальным агентам, потом рассмотрим, с какими проблемами столкнулась, и поймём, почему в какой-то момент мы все дружно перестали писать код и стали писать промпты.

Содержание

• «write if you need more context»
• Агентская эйфория
• Context Engineering
• Оркестрация
• Как я перестал бояться и полюбил prompt-injection
• Prompt as Tooling
• Meta-prompting
• Заключение

Деплоите LLM? Значит, обвешиваете её гардами. Сначала safety, потом PII, потом prompt injection, потом toxic BERT - и в один прекрасный день обнаруживаете, что у вас 5 классификаторов на каждой ноде и 20 forward-ов на один пользовательский запрос.

GLiNER Guard - возможность схлопнуть этот стек в единый schema-driven энкодер. И да, его можно тоже промптить: через zero-shot + description.

Мы построили мультиагентную RAG-систему на open-source моделях, прошли путь от наивного RAG до ReAct-агента с собственным бенчмарком — и готовы рассказать, где набили шишки. Внутри: две итерации архитектуры, честное сравнение через RAGAS-метрики и ответ на вопрос, почему «просто взять фреймворк» не работает. Будет полезно всем, кто строит RAG для корпоративных знаний или только собирается.

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

Современные фреймворки обещают построить такой граф автоматически, в пару команд. Но между "запуском из коробки" и рабочей аналитической системой на практике лежит немалая дистанция.

Это первая часть практического эксперимента с LightRAG, одним из самых известных графовых фреймворков. На небольшом корпусе из Гражданского кодекса РФ и судебной практики разбираем, как фреймворк устроен, как его быстро развернуть, и почему граф из "коробки", без оптимизации и тонкой настройки, при всей внешней убедительности, еще не готов к полноценной работе в юридическом домене.

Прошло несколько лет с тех пор, как нейросетевые модели стали применимы в генерации текста. Сегодня языковые модели уверенно решают задачи написания кода, поддержки диалогов и планирования маршрутов. Тем не менее, до сих пор не сложилось универсального подхода для валидации LLM перед их внедрением в цифровые продукты.

Но у нас есть решение! В этой статье я расскажу, как мы в Sber AI обучили специализированного LLM-судью (LLM-as-a-Judge) Pollux для оценки русскоязычных LLM. Мы выложили его в открытый доступ и вы можете встроить его в свой продукт уже сегодня.

Есть компании, которые верят в то, что уж лучше много джунов за копейки, чем несколько сеньоров за дорого.

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

1. В компании Х у нас было 4 человека, которые ещё до эпохи ChatGPT с нуля за несколько месяцев собрали полноценный AI-стек:
— fine-tune собственных LLM на своих датасетах
— свой TTS/STT на своих датасетах
— генерацию лиц и deepfake
— MLOps-инфраструктуру и пайплайны

Каждое направление делал один сильный senior. ML команда из 4х человек, которая деливерит не прототипчики с AI, а такой уровень, где люди не верили, что говорят с моделью — думали, что это живой человек.

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

2. Теперь компания Y: AI-продукт уровня "обёртка над ChatGPT" команда из 15 человек уровня джун-миддл запускала около года. Потом ещё полгода доводила до нормального качества.

Сравним экономику:

Вариант 1:
4 senior’а х $8k х 4 месяца
≈ $128k до запуска

Вариант 2:
15 человек x $3k x 15 месяцев
≈ $675k до конкурентного качества продукта

Разница бюджета в 5 раз, разница в скорости запуска в 4 раза в пользу сеньёров.

Маленькая сильная команда:
— вышла на рынок быстрее
— строила собственные технологии
— накапливала engineering leverage
— могла быстро pivot’иться при необходимости

Большая команда в итоге строила то, что через год стало очень просто повторить, а значит — высокая конкуренция, демпинг по цене и слабая дифференциация продукта.

Какие выводы:

1. Лично я верю в сеньёров и быстрые запуски. Причём раньше 1 сильный инженер мог заменить 2–3 средних, а сейчас с помощью ИИ вполне может дать ещё больший эффект.

2. Больше людей не значит быстрее. Скорее наоборот: выше уровень сотрудников — выше скорость принятия решений и разработки — выше ROI — больше пространства для инноваций и поиска точек роста бизнеса.

Вероятно, это не универсальная истина и могут быть разные конфигурации бизнеса, культуры компании и целей, но на моём опыте вывод довольно однозначный.

Если не согласны — с удовольствием подискутирую.

Привет, Хабр! Меня зовут Антон и я занимаюсь задачами NLP в компании Ростелеком Информационные технологии.

Если вам приходилось разбирать большие массивы текстов: отзывов, обращений в поддержку или комментариев, то вы знаете, насколько это трудоемкий процесс.

В статье я покажу, как автоматизировать этот процесс с помощью пайплайна BERTopic: от эмбеддингов и кластеризации до интерпретации тем. Особое внимание уделим тому, как встроить локальную LLM в пайплайн и получить человекочитаемые названия тем.

У меня был очень долгий диалог с Claude Opus, в ходе которого я, помимо основных изысканий и проработки своих материалов занимался совместной рефлексией о промпт-инжиниринге и том, как следует или можно бы подходить в работе с LLM.

В результате нашего диалога Opus выписал(а) 6 своих «инсайтов», из которых я отбраковал 2 за повторение уже известного или мало-полезного, а оставшиеся 4 попали в эту статью.

Статья написана Opus-ом от первого лица как обращение к читателю. Он(она) описывает, что в ходе нашей беседы пересмотрел(а), и попытался(ась) донести эти мысли и эти эмоции до Вас, до читателей.

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

Кожанный со-автор - Real_Egor =)