Natural Language Processing *

Обычно внедрение 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 =)

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

У заказчика была именно такая проблема: сеть ресторанов по России, у каждого заведения отдельная концепция и свой стиль общения с гостями. Большая часть ресурсов уходила на ежедневную текстовую работу: описания ресторанов, переводы на разные языки, пресс-релизы, рассылки, описания блюд, мероприятий, посты для социальных сетей и тексты в Tone of Voice каждого бренда.

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

Четыре года я была волонтером в приюте. Самое тяжелое — видеть «вернувшихся» животных. Ещё вчера у них был дом, а сегодня снова клетка. В России 3,6 млн бездомных животных и треть россиян готовы взять питомца — но до реального пристройства доходят единицы. Проблема не в отсутствии желающих, а в механизме подбора.

В этой статье рассказываем, как мы пытаемся это исправить с помощью NLP.

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

Недоверие бизнеса к агентным решениям растёт пропорционально их распространению. И это недоверие небезосновательно: агент — это не просто чат-бот с улучшенным промптом. Это система с доступом к инструментам, внешним сервисам и корпоративным данным. Ошибка модели в изолированном чате — это неловкость. Ошибка агента с доступом к почте и документам — это потенциальная утечка данных, репутационный или финансовый инцидент.

Эта статья адресована бэкенд-разработчикам, которые уже выкатили агента в прод или готовятся это сделать. Она является практическим продолжением нашего предыдущего материала о Red Teaming LLM: там мы разобрали концептуальную базу и объяснили, почему языковые модели требуют отдельного подхода к тестированию безопасности. Здесь — конкретный кейс из реальной практики Doubletapp и пошаговый инструмент, который можно поднять и запустить на своём агенте уже сегодня.

Содержание
- Чем Red Teaming агента отличается от Red Teaming LLM
- Cookbook: базовый Red Teaming с Promptfoo
- Ссылки

Стартап Anthropic со дня основания позиционировал себя как разработчика “Объяснимого ИИ”. В мае 2026, они опубликовали метод, который переводит активации модели в связный человеческий текст: Natural Language Autoencoders

Жемал Хамидун · Head of AI Alpina Digital, CPO AlpinaGPT

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

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

Числовая оценка идеальна для закрытых задач. Аморфная нужна для открытых. AI за пятнадцать лет переехал из первого класса во второй — а инструмент оценки остался прежним.

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

Почему бенчмарки в AI сломались, и что с этим делать в следующий понедельник.

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

В этой статье я разберу другой подход: попробовать оценивать неопределённость не только по выходу модели, а по внутренней согласованности активной цепи трансформера. Речь пойдёт о метрике EICS — Effective Information Consistency Score. Идея в том, чтобы за один прямой проход получить численную оценку того, насколько найденная трансформерная цепь ведёт себя согласованно и насколько её макроуровневое описание действительно несёт интегрированную информацию.

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