Мне нужен взгляд со стороны

Представьте, что у вас есть Очень Много Денег. Очень много.
И вы решили купить акции каких-нибудь маленьких компаний с большим потенциалом, чтобы потом получать доход от их прибыли.
Чтобы не прогадать с выбором, вы обратились в известную консалтинговую компанию. У компании безупречная репутация: ее аналитики отвечают за каждое свое слово. У них много довольных клиентов, и вам их подсказал человек, которому вы доверяете.
Недавно на большой конференции представитель компании сообщил, что они начинают внедрять в свою работу инструменты на основе ИИ.

Вопрос. Вы бы хотели знать о том, использовался ли ИИ при подготовке отчета для вас? Если да, то вы бы предпочли знать как можно больше, или достаточно будет сказать: «Мы использовали ИИ, но все за ним проверили?»

Я поймана на неосознанной манипуляции

Мои варианты ответов подталкивают выбрать "да, достаточно упоминания" или или "да в деталях".
Спасибо @BatanovFA за внимательность 😌

Опрос, к сожалению, нельзя изменить, так что переделываю

Спасибо всем, кто голосует 💚

Еще один интересный (и несложный, что важно) способ борьбы с галлюцинациями у языковых моделей

Контроль (Guardrailing) работы больших языковых моделей — тема невероятно интересная. Я копаю потихоньку литературу в этом направлении и нашла вот статью, которой решила поделиться. Статья называется “Building Guardrails for Large Language Models”. Давайте посмотрим, о чем она.
Guardrails (дословно «защитное ограждение») – это алгоритмы, которые оценивают входные и выходные данные модели, чтобы понять, нужно ли предпринимать действия для снижения возможного вреда. Они же часто называются «контент-фильтры».
Самая сложная задача здесь – определить, что именно считать нанесением вреда. Есть разные подходы, и авторы статьи рассматривают три решения: Llama Guard, Nvidia NeMo и Guardrails AI, – чтобы понять, какие существуют проблемы и возможности. Все три инструмента – решения с открытым исходным кодом, они полностью доступны для анализа.
Llama Guard – это просто языковая модель, которая классифицирует входы и выходы как «безопасные» или «небезопасные».
Nvidia NeMo преобразует пользовательский запрос в вектор и с помощью алгоритма K-ближайших соседей находит наиболее близкий по смыслу «безопасный» запрос из заранее подготовленного набора. Этот набор хранится в векторной базе данных. Кроме того, NeMo использует Colang (специальный язык для создания диалогов между ИИ и пользователем), чтобы управлять генерацией безопасных ответов. Инструкции задаются в виде команд, например: «bot inform cannot answer» для тем, на которые разработчики не хотят, чтобы модель отвечала.
Guardrails AI устроен посложнее и состоит из двух блоков: input guard (защита на входе) и output guard (защита на выходе). Input guard определяет, содержит ли запрос потенциально опасный контент. Output guard проверяет текст на галлюцинации, токсичность и другие риски. У той же компании, которая делает Guardrails AI, есть проект Guardrail Hub. Это библиотека, в которой собрана целая коллекция валидаторов – инструментов оценки для разных типов рисков, – их можно использовать в зависимости от задачи.

Один из самых любопытных конфликтов в области контроля входов-выходов языковых моделей – это противоречие между безопасностью и интеллектом. Некоторые исследователи заметили, что модель хуже справляются с задачами, если они касаются чувствительных тем. Хотя изменения в поведении модели еще не означают ухудшения ее способностей, вопрос остаётся открытым: как создать одновременно безопасные и эффективные продукты? И это еще не все: требования к безопасности зависят от области применения, что совсем не упрощает задачу.
Авторы считают, что наилучший результат можно получить, сочетая обучаемые (learning-based) и символьные (symbolic) подходы. Обучаемый подход – это дообучение модели на нужном наборе данных. Символьный подход подразумевает создание набора строгих правил, которые модель должна соблюдать.
Первый хорошо работает, когда данных много и нужна гибкость. Второй подходит для редких и специфичных случаев, когда данных недостаточно. Вместе они образуют так называемый нейро-символьный подход, который выглядит как неплохое решение.

Давайте обсудим, что не так с оценкой безопасности ИИ на сегодняшний день (спойлер: почти всё)

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

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

Сегодня поговорим на непростую тему – про чрезмерную зависимость или чрезмерное доверие к ИИ

Что может быть лучше, чем разговор о теории разума в тихий воскресный день? Ничто не может

Источники:
1) «New Research Suggests Overreliance on AI Could Hinder Critical Thinking»;
2) «The Future of Jobs Report 2025» Всемирного экономического форума;
3) Исследование Microsoft и Carnegie Mellon University: «The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers»

У нас, людей, есть склонность все вокруг себя очеловечивать. Мы очеловечиваем все, что движется, а что не движется, двигаем и очеловечиваем. С ИИ это тоже работает, несмотря на то что ИИ – абстрактная штука без ручек, ножек и глазок. Нашему мозгу такое не помеха.
Склонность к очеловечиванию несет в себе как некоторые позитивные эффекты, так и риски, о которых мы сегодня и поговорим

Что-то я забыла написать сегодня, а пост вышел

Рассказываю немного про то, где и как использую ИИ

Мне некоторое время назад попалось на глаза приложение Seeing AI от Microsoft. Идея этого приложения – помочь слепым и слабовидящим людям ориентироваться в окружающем мире. Человек наводит камеру на объект и получает описание. Или просто водит камерой вокруг и получает описание пространства и объектов в нем.
Здесь мы вынуждены оставить вопрос о том, как слепой или слабовидящий человек находит и запускает нужное приложение. Допустим, ему помогает голосовой помощник.
Приложение должно работать на платформах iOS и Android, но мне почему-то скачать его на iOS не удалось. На Android протестировала, впечатления получила смешанные: с одной стороны, это действительно хорошая идея и то направление, в котором и должно двигаться развитие ИИ в первую очередь. С другой стороны, приложение показалось мне достаточно сырым: в нем нужно использовать визуальный интерфейс, чтобы переключаться между режимами, что довольно бестолково. Точность тоже так себе, если честно, во всяком случае, на русском языке. Есть над чем работать.
На iOS есть подозрительно похожее приложение Envision AI, которое работает с теми же функциями и примерно так же с точки зрения эффективности. Интерфейс опять визуальный, но приложение может использоваться с Siri. Голосовой ввод был бы логичнее, на мой взгляд.
Судя по информации на официальном сайте, у компании-разработчика Envision Technologies есть еще умные очки, к которым можно подключить само приложение. Глубоко я в эту историю пока не лезла. Возможно, оба приложения работают намного лучше на английском языке и в паре с голосовыми помощниками.
Может быть, я как-нибудь полезу изучать всю эту историю подробнее. А пока просто делюсь с вами, потому что звучит это интересно.

#инструменты

Немного рассуждений о персонализации

Я посвятила несколько постов обзору критики подходов к оценке языковых моделей, так что логичный следующий шаг – показать хотя бы один пример того, как такие подходы совершенствуются. Как раз нашла такой пример.
Сначала вышла работа «AlpacaEval : An Automatic Evaluator for Instruction-following Language Models», которая предлагает AlpacaEval – инструмент для оценки работы больших языковых моделей, в частности, того, как хорошо эти самые модели следуют инструкциям. Причина возникновения такого решения в том, что постоянно просить людей провести тесты долго, дорого и сложно. А еще люди могут противоречить себе в своих же оценках, поэтому процесс надо автоматизировать. Как? – Например, взять еще модель, обучить ее на наборах данных, размеченных людьми, и использовать в роли оценщика.
Это хороший подход с точки зрения затрат человеческого труда, времени и денег. Однако оказалось, что AlpacaEval завышает оценки для моделей, которые пишут очень длинный ответ, а не очень точный. И в 2024 году была опубликована статья «Length-Controlled AlpacaEval: A Simple Way to Debias Automatic Evaluators». Авторы поставили целью выявление искажений в автоматической оценке работы языковых моделей, и AlpacaEval взяли в качестве конкретного примера.
Эталоном для сравнения выступает Chatbot Arena – платформа для пользовательской оценки моделей. Там вот как все работает:
пользователь пишет запрос;
ему отвечают модель А и модель Б – пользователь не знает, что это за модели;
пользователь читает оба ответа и выбирает тот, который больше понравился;
на основании такого голосования множества людей составляется рейтинг лучших моделей.
В процессе разработки такой эксперимент поставить сложно: надо как-то привлечь очень много людей на очень много часов. Однако можно постараться приблизиться к «серебряному стандарту». Не золотому, потому что оценки пользователей все-таки могут быть искажены, но лучшему из имеющихся.
Авторы выделили три фактора, которые влияют на оценку одной моделью результатов работы другой модели:
тип модели: есть «основная» модель и та, которую с ней сравнивают;
длина ответа на инструкцию;
сложность инструкции.
Тут надо не запутаться, потому что при автоматической оценке модели три: две соревнующиеся и одна модель-оценщик. Идея авторов в том, чтобы обучить модель-оценщик на наборе данных, в котором указаны
ответ основной модели;
ответ модели, которую сравнивают с основной;
тип модели, которая дала ответ (основная модель или ее конкурент);
длина ответа;
сложность инструкции;
выбор человека (ответ какой модели он посчитал более качественным).
Потом помножить на нуль длину ответа и получить альтернативную оценку.
В результате оценку удалось скорректировать и здорово приблизить к человеческой, которую разные модели получили в Chatbot Arena. Авторы отмечают, что, хотя у их исследования есть ряд ограничений, это шаг в нужном направлении

В начале года у меня был пост про объяснимость и интерпретируемость ИИ. Потом был еще один – про конкретный инструмент для объяснения результатов работы языковых моделей и совсем недавно – про полезность объяснений.
Почти всегда, когда речь заходит об этических вопросах применительно к ИИ, я пишу с точки зрения пользователя. И здесь все понятно, а вот компаниям эта вся этика, объяснимость и интерпретируемость зачем? Сегодня представлю вам одну точку зрения на этот счет.

Авторы статьи «Creating meaningful work in the age of AI: explainable AI, explainability, and why it matters to organizational designers» указывают на то, что необъяснимая работа ИИ мешает компаниям получить от него максимум пользы. Клиенты компаний не понимают, как работает продукт и можно ли ему доверять. Разработчики тоже не то чтобы могут эти объяснения предоставить. Попытки заменить алгоритмы на более прозрачные снижают эффективность, и использование ИИ уже не выглядит полезным.
В 1951 году Трист и Бэмфорт (Trist & Bamforth) исследовали, почему внедрение нового оборудования для британских шахтеров привело не к повышению, а снижению эффективности добычи угля. Результаты их работы легли в основу принципов разработки социотехнических систем – таких систем, в которых человеку необходимо взаимодействовать с технологией.
Во-первых, изменения должны предлагаться снизу вверх, а не сверху вниз: работники, которые непосредственно взаимодействуют с технологией, лучше знают, чего ей не хватает. И им же отвечать за конечный результат.
Во-вторых, организации должны становиться более адаптивными за счет снижения контроля за каждым действием сотрудников. Больше свободы для работников «на местах» – быстрее реагирование на меняющиеся обстоятельства.
В-третьих, каждая группа сотрудников должна работать над «целой задачей» («whole task»). Это значит, что в распоряжении группы должны быть все процессы разработки конкретного решения от начала до конца. Это даст больше свободы относительно выбора подхода к выполнению задачи и позволит избежать превращения работы в письмо Дяди Федора родителям.
Наконец, каждая задача должна быть значимой и иметь видимое завершение. Работа не должна нигде зависнуть и потеряться, а ее результаты должны быть встроены в большие процессы компании.
Автоматизация должна применяться там, где это необходимо, и настолько, насколько необходимо для улучшения результата.
Если вы подумали: «Хм, это напоминает методологию Agile для разработки программного обеспечения,» – вы не одиноки, оно правда напоминает. Принципиальная разница в том, что идея социотехнической системы относится к устройству организации в целом и была придумана для «традиционных» организаций, где кто-то стоит за станком и вытачивает детали. Agile – это набор принципов конкретно для разработки ИТ-продукта. ИТ-команда может быть частью «традиционной» организации и работать как социотехническая система. Сама организация тоже может быть построена по принципам социотехнической системы, и внутри нее будет гармонично работать ИТ-команда по принципам Agile. Это разные концепции, но они хорошо подходят друг другу.
Если организация построена по принципу социотехнической системы,
сотрудники знают, на что жалуются клиенты;
сотрудники, которые работают с клиентами, также плотно работают с разработчиками;
команда специалистов с разными навыками работает вместе над одним продуктом и делает так, чтобы объяснимость ИИ появилась там, где нужно и выглядела так, как нужно;
каждый член команды может объяснить клиенту, что, как и зачем было сделано.
Так объяснимость ИИ будет всем понятна и полезна.