Natural Language Processing *

Если вы строили RAG в 2023, ваш стек выглядел плюс-минус одинаково. BERT-семейство (BGE, e5) для семантики, BM25 для буквальных совпадений, cross-encoder для реранкинга, какой-нибудь Qdrant сверху. Этим жили два года, и многие до сих пор так живут.

Но если посмотреть, кто реально гоняется в продакшене у команд, которые ушли вперёд, ландшафт другой. Энкодеров там почти нет. Эмбеддит файнтюненная LLM. Реранкер — тоже LLM. Инференс на SGLang, а не на ONNX. И вся обвязка перестроилась под это.

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

Автоматическая генерация структурированных академических конспектов из аудиозаписей лекций по точным и естественным наукам затруднена для локальных малых языковых моделей (small language models, SLM). Транскрипт лекции продолжительностью ≈1,5 ч составляет около 15–20 тыс. токенов и формально умещается в контекстное окно современных локальных SLM, однако при обработке такого контекста single-call SLM систематически деградируют: теряют фрагменты из середины последовательности, не удерживают структуру и галлюцинируют термины и формулы. Это проявление эффекта Lost in the Middle: точность извлечения информации описывает U-образную кривую — высока на краях контекста и падает в середине; в наших условиях используются SLM, поведение которых так же описано в статье, и оно характеризуется выраженным забыванием не только из середины, но также и из начала контекста. Более того, на бюджете 8 ГБ VRAM single-call длинного транскрипта практически неприменим*, что делает декомпозицию не оптимизацией, а необходимым условием работоспособности.

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

Эта статья про то, как измерять. Точнее, про то, как тестировать и мониторить адаптивные LLM-системы в продакшене и до него, чтобы убедиться: ассистент ведёт себя так, как задумано.

Привет, Хабр! На связи команда Optimal Cognitive Core (OCC) из AIRI. Развитие языковых моделей в последние годы определяется масштабом: каждое новое поколение вмещает в веса всё больше знаний о мире. Но огромная доля практических задач выигрывает тогда, когда модель демонстрирует не свою энциклопедичность, а способность рассуждать и анализировать предоставленный контекст. Из этого наблюдения и выросло OCC — наше семейство компактных языковых моделей (SLM), которые имеют сильные когнитивные способности, не обладая при этом большим багажом «вызубренной» информации.

В этой статье расскажем о первой модели нашего семейства, OCC‑RAG, которая оптимизирована под задачу контекстного Q&A. Мы выложили два чекпойнта, OCC‑RAG-0.6B и OCC‑RAG-1.7B (плюс ONNX‑ и GGUF‑сборки). При размере 0.6 и 1.7 млрд. параметров, соответственно, они отвечают на равных или лучше моделей общего назначения, которые в 2–6 раз больше, а по верности контексту показывают лучший результат среди моделей до 32B. Внутри — как устроена модель, как мы её обучили и что в итоге получилось.

Зачем и для кого статья?

- Для тех кто хочет сделать своего ИИ бота

- Кто интересуется LLM и в частности RAG

Уверен, на Хабре найдётся немало статей, посвященных оценке качества RAG систем. Тема по-прежнему остаётся актуальной, потому что даже готовые библиотеки вроде RAGAS не очень-то работают из коробки и требуют навыков программирования и некоторой квалификации. При этом сам процесс оценки - повторение достаточно простых операций и мне всегда хотелось переложить его на AI-ассистента.

Повод попробовать появился неожиданно: свободное время и курс по Claude Code на Stepik. Для финала как раз нужен был проект, посвященный автоматизации реальной рутинной задачи, желательно без кода (курс про вайб-воркинг, для непрограммистов). Конечно, я сразу вспомнил про задачу оценки качества. Дальше - честная история со всеми проблемами. Забегая вперёд, скажу, что совсем без программирования не вышло. Но, может, это профессиональная деформация.

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

Наш сервис связал в отчёте повышенные лейкоциты с препаратом, который пользователь начал принимать уже после самих анализов. Другому предложил пересдать семь маркеров, сданных два дня назад. Этим вторым был мой папа. Третьему порекомендовал КТ пазух, не зная, что тот неделю назад уже был у ЛОРа с готовым заключением. В отчёте четвёртого всплыл «железодефицит» - там, где про железо не было ни одной цифры.

Привет! Это Роботы.
Недавно мы выпустили статью на arXiv, где представили архитектурный подход DCD (Domain–Collection–Document) для структурирования пространства знаний и обработки запросов в RAG-системах. Мы провели подробные эксперименты, оценили работу подхода на собственном бенчмарке и показали, как он влияет на качество поиска и генерации в сравнении с другими подобными методами. А теперь хотим здесь рассказать о ключевых идеях, лежащих в основе DCD Design.

ПростоГраф — мой глубокий форк LightRAG под реальные нужды: self‑hosted graph‑RAG для отделов с ролями, физическим разграничением доступа к документам, промптами под каждый отдел. Готовый инструмент. Бери — пользуйся. Более подробно что это, зачем это, как это, в статье...

Я разрабатываю ИИ-планировщик, которому можно писать обычным языком: «перенеси встречу с Сергеем», «каждую первую субботу проверяй остатки корма» или «нет, не событие, а дело». Код в основном создаётся агентом, а мои усилия уходят на описание предметной области, пользовательских сценариев и проверок.

Это не туториал по созданию готового SaaS и не подробный разбор агентской разработки. Статья — промежуточный отчёт о проекте: какую предметную модель я выбрал, как проверяю ответы моделей, почему разделил LLM и детерминированные операции и с какими проблемами столкнулся после первого деплоя.

В статье я показываю архитектурные решения и текущие результаты, включая те части, которые ещё не работают идеально.

Яндекс использовал Алису для получения номеров победителей вместо привычного рандомайзера. Мне стало интересно, насколько числа случайны — и я провёл небольшой эксперимент. А так же попросил DeepSeek, Гигачат, Gemini решить ту же задачу.

Строю приложение для подсчёта калорий по фото. Пользователь снимает тарелку, модель определяет блюдо, считает КБЖУ. Идея не новая, но мне важно, чтобы это работало именно на русской еде — борщи, гречки, котлеты по-домашнему.

В какой-то момент стало некомфортно: я не знал, насколько модель вообще точна. «Кажется, работает нормально» — плохой ответ, если хочешь что-то улучшать. Решил померять нормально.

Расскажу, что и как мерил, что получил — и про неожиданный вывод в конце, ради которого, честно говоря, и стоило это всё делать.

Спойлер: распознавание оказалось готовым к проду (93.9%), а вот confidence от модели — почти константой, на которой нельзя строить логику. И главная ошибка в калориях пряталась совсем не там, где я её искал.

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

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

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

Градиентные атаки на LLM разнообразны: GCG добавляет абракадабру, AutoDAN добавляет связный текст - но обе они бьют в одно и то же уязвимое место: обе уводят модель с единственного «направления отказа», и одна такая добавленная строка вскрывает любой запрос даже на моделях, которых не видела. Годами учим модели отказывать на вредные запросы, а вся их стойкость висит на одном векторе. Большой иллюстрированный разбор: как несхожие атаки сошлись к одной мысли - refusal direction - и куда уходит фронтир.

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

В этой статье (ее первой части) разберём среду изолированного исполнения кода: песочницу (sandbox).

Представим ситуацию: пользователь загружает Excel-файл, просит проанализировать таблицу, найти аномалии и на основе анализа создать PowerPoint-презентацию. В чистом виде LLM не умеет читать файлы, строить графики и создавать презентации. Однако может написать код, который всё это сделает.

И тут появляется вопрос: где этот код запускать?

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

В этой статье разберём:
- основные риски исполнения кода в неизолированной среде;
- что такое песочница и её ограничения;
- какие бывают подходы к реализации песочницы;
- вариант логики работы агента с песочницей.

Привет, я Вит Глинка, backend программист в компании Deeplace, в которой среди прочего активно работают в области winetech. Хочу презентовать нашу последнюю фичу в этой области — raFTI.v5.3 — систему полнотекстового поиска.

Привет! Меня зовут Дарья Воронкина. Я строила и руководила командой DataHub в медтех-компании OneCell (цифровая патология — ИИ ищет опухоли и метастазы на гистологических стеклах), а сейчас консультирую компании по переходу в AI-native режим.

Расскажу, как примерно за месяц я перевела свою команду с ручных промптов на систему агентов, которая ведет операционку сама. Получилось быстро во многом потому, что за плечами годы ML-инженерии и роль лида — я уже привыкла мыслить системами, данными и процессами, оставалось переложить это на агентов. Дальше — что получилось, что сломалось и какие выводы я унесла. Будет полезно тем, кто уже собирает агентов и хочет довести их до прода.

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

Первую часть статьи вы можете прочитать тут - От Naive RAG до ReAct-агента: как мы строили корпоративного AI-помощника на open-source моделях (часть 1)

Мы в targetai специализируемся на создании ИИ-ассистентов для клиентского сервиса. И голосовые агенты для нас — один из ключевых сценариев. В какой-то момент мы с командой пришли к пониманию, что зависимость от вендорских TTS-сервисов — это риск. Пришлось договариваться, что вообще можно считать «хорошим голосом» для ИИ-агента. Эта статься посвящена формированию критериев отбора TTS-движка. Сравнение моделей я тут затрону вскользь, пока можно ориентироваться на данные, которые наш маркетинг опубличил во время релиза нашего движка targetspeak. И, кстати, есть хороший обзор open source TTS-решений с точки зрения метрик у коллег из Raft.

О том, почему вводный курс Python для гуманитариев лучше начинать не с калькуляторов и абстрактных циклов, а с текста, частотности и осмысленных исследовательских задач.

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