
Недавно мы провели обзор исследований, посвященных работе с большими языковыми моделями в ЦОД. Обсудили, почему происходят сбои при обучении моделей и применимость LLM в кибербезопасности.
Сегодня поговорим о том, какие задачи делегируют нейросетям ученые и разработчики. Также посмотрим на базовые проблемы, которые еще предстоит решить с точки зрения дальнейшего совершенствования систем ИИ на практике: от восприятия контекста до эффекта «нарастающих галлюцинаций».
LLM в науке
С развитием больших языковых моделей все чаще возникает вопрос: когда появится система ИИ, способная проводить полноценные научные исследования? Однозначно ответить на него сложно. Попытки реализовать подобные системы предпринимают.
Недавно японские ученые представили первую систему ИИ, способную, по их утверждениям, совершать научные открытия. Но о том, что стоит за громкими заявлениями на практике, говорить пока все-таки рано. Дата-сайентисты приводят железобетонный аргумент: классические нейросети едва ли способны сделать по-настоящему прорывное открытие, ориентируясь лишь на известную фактуру.
С другой стороны, объём информации, с которой приходится работать учёным на регулярной основе, огромен. И LLM уже помогают анализировать научную литературу. Большие языковые модели вроде Elicit, опирающейся на базу из 125 млн работ, способны разбирать структуру текста, отвечать на вопросы по содержанию статей, а также помогать с их рецензированием. И подобных систем множество: от OpenRead до Semantic Scholar.
Вместе с этим большие языковые модели способны помочь с анализом источников и их взаимосвязей. Примером подобного решения может быть модель Scite. Цель проекта — ускорить подготовку обзоров литературы. Scite умеет готовить краткие выжимки статей и анализировать ссылки в них. Модель способна оценить мнение автора анализируемой статьи о других ученых и публикациях. База данных Scite содержит более 800 млн классифицированных цитатных высказываний.

Ещё одно перспективное направление развития больших языковых моделей в научной сфере связано с контекестуализированным поиском профильной литературы и статей. Примером разработки в этой области может быть решение LitLLM, выложенное в открытый доступ на GitHub. Она помогает найти релевантные статьи на основе запроса пользователя. Работа системы напоминает классическую поисковую систему. Пользователь вводит запрос о том, публикации на какую тему (и о чем) ему нужны. Такой подход позволяет адаптировать поиск под уникальные потребности.
В целом LLM уже упрощают анализ и поиск научной литературы, но подобные технологии также не лишены недостатков. В частности, как отмечают специалисты, полностью полагаться на выводы LLM в научной работе и даже рецензировании статей пока не следует.
Системы ИИ пока не могут оценивать общий уровень исследований. Кроме того, могут допускать ошибки при анализе числовых данных, графиков или статистических выводов. Ещё одна проблема — устаревание моделей, которое не позволяет в полной мере учитывать новые достижения науки.
Работа с кодом
Для большинства разработчиков написание кода — не самая трудоемкая задача. Куда больше времени уходит на тестирование, поиск багов и составление документации.
Большие языковые модели способны упростить этот процесс. Например, они помогают быстрее разобраться в чужом коде. Так, в 2024 году специалисты из Университета Каргени — Меллона и Google провели эксперимент. Они предложили 32 программистам изучить и доработать незнакомый код. В одном случае участники использовали IDE с интеллектуальным помощником, а в другом — искали ответы в браузере. Результаты показали: при работе с системой ИИ программисты завершали больше задач.

Также появляются LLM, способные помогать с исправлением ошибок и актуализацией кода. Одно такое решение — Granite — представила компания IBM и передала его в open source.
Некоторые решения вообще подходят для проведения полноценных код-ревью. Так, в исследовании «AI-powered Code Review with LLMs: Early Results» представили интеллектуальную модель, которая анализирует код и дает рекомендации по его доработке. Её обучили на тысячах репозиториев, отчетах об ошибках и документации с лучшими практиками разработки. Модель протестировали в проекте VisionQuest, связанном с компьютерным зрением. LLM обнаружила устаревшие алгоритмы сегментации изображений и предложила заменить их на более эффективные, повысив производительность системы.
Инциденты, ошибки и проблемы
Большие языковые модели и системы ИИ используют в широком спектре приземленных задач в сфере программирования, науки, а также многих других. Это многообещающие результаты с учетом общего скепсиса к подобным инструментам. Однако перед разработчиками систем ИИ стоят несколько проблем, которые еще предстоит решить.

Одним из ключевых препятствий остаются галлюцинации — ситуации, когда модель генерирует правдоподобные, но ложные ответы. Проблема становится острее, когда ответы интеллектуальной системы необходимо использовать в цепочке запросов. Ошибка, допущенная на раннем этапе, многократно повторяется. В результате возникает серия некорректных выводов с «эффектом снежного кома» с точки зрения искажений.
Исследователи считают, что в таких ситуациях возможно применить технику «цепочки размышлений», при которой модель пошагово расписывает логику генерации своего ответа. Сперва LLM генерирует базовый ответ на запрос пользователя, а затем формирует вопросы для верификации фактов и отвечает на них независимо друг от друга.
В этом отношении у разработчиков систем ИИ еще остается простор для увеличения вовлечённости дата-сайентиста или профильных экспертов в процесс обучения специализированных моделей — например, на этапе разметки и аннотации данных. Именно на этих шагах можно выявить и устранить ошибки, улучшить качество данных и задать основу для более точной работы модели. Дополнительные возможности для совершенствования систем ИИ открываются на этапе разработки бенчмарков. Один из самых простых методов — сбор проверенных человеком (human-verified) примеров в формате «вопрос-ответ» для последующего тестирования фактических знаний LLM.
Есть ещё одна проблема, с которой сталкиваются разработчики ИИ, — сложность работы с контекстом. Например, если попросить языковую модель рассказать про «лучший вьетнамский ресторан», ответ будет непредсказуем. Нейронка может предложить рестораны вьетнамской кухни в совершенно любой стране или вовсе начать рассказывать о ресторанах в самом Вьетнаме.
Согласно работе под названием SituatedQA, значительная часть запросов по поиску информации имеют контекстно-зависимые ответы — например, для датасета Natural Questions доля составляет 16,5%. Эта цифра значительно возрастает для узкоспециализированных нейросетей. Предоставление контекста системе ИИ — задача совсем нетривиальная. Базовым подходом к её решению является Retrieval-Augmented Generation (RAG), когда контекстуальные данные дробятся на фрагменты и сохраняются в векторную БД, к которым модель обращается по мере необходимости. Такой подход позволяет улучшить качество обработки запросов, требующих контекстуальной информации, и минимизировать вероятность ошибок.
Другая проблема связана с мультимодальностью — необходимостью объединять информацию, поступающую из разных источников в рамках единой системы ИИ. Эта задача в том числе важна с точки зрения работы с контекстом, например, в медицине. Так, при анализе данных о пациенте модель должна учитывать жалобы больного, результаты обследования, заметки врача. И все они могут быть представлены в разных форматах: в виде бумажных записей, сканов, снимков и графиков. Классические языковые модели не всегда справляются с такими задачами. Поэтому всё больше исследователей изучают вопросы, связанные с переходом от классических LLM к мультимодальным — MLLM.
Мультимодальные модели способны анализировать изображения, видео и аудиозаписи, дополняя текстовую информацию контекстуальными данными. Однако разработка MLLM сопровождается рядом сложных вопросов, один из ключевых — выбор подхода к размерности моделей. Среди исследователей идет дискуссия: какой подход является более эффективным — разработка «больших и универсальных» моделей или «малых и специализированных». С одной стороны, универсальные системы обещают охватить широкий спектр реальных задач. С другой стороны, всё больше данных указывает на то, что компактные модели лучше адаптируются к особенностям конкретных задач и требуют меньше ресурсов для обучения. Поэтому ключевая задача будущих исследований — найти баланс между универсальностью и специализацией.
DigitalDoomsday
По ходу статьи вы рассуждаете о необходимости объединять разнообразные форматы данных (текст, снимки, графики) в рамках единой мультимодальной модели и указываете на дискуссию между подходами “большие универсальные” vs. “компактные специализированные” системы. Как именно вы оцениваете эффективность этих подходов при работе с мультимодальным контекстом?
Например, на практике не станет ли Retrieval-Augmented Generation (RAG) с многомерными векторными БД слишком ресурсоёмким для “больших” MLLM, а попытка сократить модель до “малой” существенно ударит по качеству анализа сложных типов данных (вроде медицинских снимков и текстовых записей врача)?
Расскажите пожалуйста о критериях выбора оптимального размера и архитектуры MLLM, если набор мультимодальной информации очень велик и разнороден.