Два примера того, как большие языковые модели LLM могут помочь расширить работу информационных архитекторов.
Автор: Хорхе Аранго
Информационный архитектор, консультант, автор и педагог. Последние 25 лет он использовал архитектурное мышление, чтобы внести ясность и согласованность в цифровые продукты и услуги. Хорхе также преподает в программе интерактивного дизайна для выпускников Калифорнийского колледжа искусств.
Проблема поддержания порядка в старых хранилищах
Поддержание порядка в больших хранилищах контента — это постоянная проблема. Постоянно появляются новые материалы, и таксономии со временем развиваются. У команд с ограниченными ресурсами редко есть возможность реорганизовать старый контент. В результате пользователи с трудом находят нужные им материалы, когда и где им это нужно.
Когда я говорю «большие репозитории контента», я имею в виду 2 типа систем.
- Первый тип предоставляет большой объем контента конечным пользователям. Примером может служить интернет-магазин с большим каталогом продукции.
- Второй тип используется внутренними командами для агрегации знаний. Типичным примером являются репозитории стенограмм интервью, используемые для исследований.
В обоих случаях людям нужно найти информацию. Но поиска недостаточно: пользователи также должны понимать, какая информация находится в системе. Для этого система должна выставлять таксономии — списки категорий — которые дают пользователям представление о том, что там находится.
Мы организуем контент в два этапа:
- Первый этап — это когда система только строится; это чистый лист. Во многих отношениях это более простой сценарий.
- Второй этап — когда система уже работает некоторое время. Уже есть набор элементов и категорий контента, но меняющиеся условия требуют, чтобы все развивалось.
Это подразумевает не только добавление и удаление контента, но и изменение таксономий и повторную маркировку контента для отражения новых категорий.
Например, рассмотрим, что происходит, когда компания выпускает новый продукт или выходит на новый рынок. Компания обновляет свои веб-сайты и поддерживает базы знаний. Они добавляют новый контент, который нужно пометить. Иногда они также создают новые термины таксономии, которые нужно применять к старому контенту.
Это негламурная работа, которую часто откладывают. Организации отдают приоритет созданию новых продуктов и функций, а не поддержанию старого контента в порядке — особенно сейчас, когда многие осознают высокую стоимость такой работы. Результатом становится контент, который не так удобен в использовании — или полезен — как мог бы быть.
Поручаем ИИ новую разметку контента
Это задача, которая хорошо подходит для ИИ. Большие языковые модели обладают мощными возможностями, которые могут помочь командам поддерживать организованный контент. Использование LLM для этого приводит к лучшему UX и освобождает команды для сосредоточения на более ценных усилиях.
Я экспериментировал с использованием LLM таким образом. Теперь я поделюсь с вами двумя вариантами использования для организации контента в масштабе с использованием ИИ:
- Первый вариант подразумевает повторную маркировку контента с помощью существующей таксономии.
- Второй вариант охватывает определение новой таксономии.
Вариант использования 1: Переклассификация контента
Давайте начнем с первого использования. Как я уже упоминал ранее, это влечет за собой переклассификацию контента с существующей таксономией. Это желательно, если изменился либо контент, либо таксономия. В качестве эксперимента я перемаркировал контент в своем блоге jarango.com. За последние два десятилетия я опубликовал там почти 1200 постов.
Как и во многих репозиториях с большим бэк-каталогом, старый контент не получал достаточной видимости. Я хотел реализовать функцию «см. также», чтобы каждый пост ссылался на связанные посты. Метод, который я использовал для выявления этих связей, включал поиск постов с как минимум двумя общими тегами метаданных.
Но у меня возникло несколько проблем:
- Это требовало, чтобы все посты имели минимум 3 тега. Я был дисциплинирован в отношении тегирования недавних постов, но старые посты часто имели только 1 или 2 тега, чего было недостаточно.
- Сама таксономия была устаревшей и непоследовательной. Она развивалась органически на протяжении 20 лет и включала термины, которые были более значимы для меня, чем для моих пользователей.
Итак, я начал с обновления таксономии. Это было достаточно просто. Сделав ее более понятной для моих пользователей, я также получил дополнительное преимущество, сделав ее более простой в использовании для LLM. Более сложной задачей было повторное назначение тегов, что потребовало бы повторного просмотра каждого поста по отдельности. Я подсчитал, что это займет от 10 до 12 часов утомительной работы.
Делать это вручную не стоило того. Поэтому вместо этого я создал небольшой скрипт Unix, который отправлял каждый пост в моем блоге в GPT-4 с запросом LLM назначить ему 3 тега из предопределенного списка.
Это сработало хорошо, с парой оговорок:
- Первая заключается в том, что хотя мой запрос настаивал на том, чтобы LLM придерживался моей таксономии, GPT-4 ввел свои собственные категории.
- Вторая заключается в том, что я ожидал чего-то подобного, потому что LLM галлюцинируют.
Поэтому вместо того, чтобы скрипт применял новые категории напрямую к файлам контента, я записал их в промежуточный CSV-файл. Там я мог просматривать и корректировать предлагаемые изменения перед добавлением метаданных в фактические файлы контента.
Этот слегка запутанный процесс позволил мне задействовать мощь LLM, при этом оставив мне последнее слово о том, как тегировать мой контент. Процесс занял примерно треть времени, которое бы заняло, если бы я делал это вручную. Но это включало в себя много обучения с моей стороны. Всякий раз, когда я буду повторять этот процесс в будущем, экономия времени будет еще больше.
Более подробную информацию об этом варианте использования, включая скрипты и подсказки, можно прочитать здесь.
Вариант использования 2: Разработка новых категорий
Давайте перейдем ко второму варианту использования, который охватывает использование ИИ для определения новых категорий контента в целом. Это полезно при работе с новой системой или когда контент изменился достаточно, чтобы заслужить новые таксономии.
Проблема здесь иная, чем в первом варианте использования. Вместо того, чтобы сосредоточиться на отдельных элементах контента, что легко могут сделать LLM, объектом интереса здесь является весь набор элементов контента как группа.
Во многих случаях этот набор контента будет достаточно большим, чтобы превзойти контекстное окно LLM. Вы можете думать об окне контекста как о памяти LLM; количестве вещей, с которыми он может работать в любой момент времени. Он измеряется в токенах, которые представляют собой крошечные фрагменты текста.
Различные языковые модели имеют различные контекстные окна. Контекстное окно GPT-4o составляет 128 000 токенов, что эквивалентно 350-500 страницам текста. Неплохо, но, опять же, может быть недостаточно для обработки всего репозитория. Кроме того, передача большего количества контента в LLM влечет за собой штраф в виде затрат и энергии.
Также существует риск анализа контента на неправильном уровне детализации. Если вы передадите весь корпус — весь контент — LLM за один раз и попросите его создать новые категории, он будет сбит с толку всеми этими подробностями. Поэтому вместо этого вы хотите разбить контент на более мелкие части, прежде чем просить LLM найти кластеры связанного контента.
Чтобы сделать это, я попробовал два подхода.
Первый вариант предполагает использование LLM для создания базы данных вложений: по сути, его просят найти статистические взаимосвязи между фрагментами контента из репозитория, а затем использовать эти вложения для поиска возможных кластеров связанного контента.
Я провел эксперимент, используя этот подход в своем подкасте. В конце 2023 года я выпустил эпизод «обзор года», в котором выделил несколько общих тем, которые возникли в интервью в течение года.
Это было возможно, потому что у меня были расшифровки для каждого эпизода. Каждая расшифровка интервью уже была разделена на главы, что указывало на смену темы в разговоре. Я разбил расшифровки интервью на отдельные файлы, по одному для каждой «главы», а затем использовал их для создания базы данных вложений. Затем я попросил GPT-4 предложить возможные кластеры глав.
Этот эксперимент был в некоторой степени успешным, хотя окончательные группировки потребовали много доработок. Тем не менее, это помогло мне определить темы для освещения и фрагменты разговоров для их иллюстрации.
Я делал этот процесс вручную в предыдущие годы, и использование LLM сэкономило мне около половины времени. В следующий раз, когда я это сделаю, я ожидаю, что буду еще быстрее. Тем не менее, я могу не сделать это так в следующий раз.
Это потому, что я сейчас изучаю другой подход, который я нахожу более успешным.
Вместо того, чтобы строить базу данных вложений и затем находить кластеры, я использую технику, называемую RAG, или генерация дополненного поиска.
Если немного упростить, RAG объединяет мощь LLM с поиском. Когда пользователь выдает запрос, ИИ просматривает репозиторий, чтобы вставить нужный контент в запрос. Это улучшает результаты, фокусируясь на конкретном контенте, о котором спрашивал пользователь, что сокращает галлюцинации.
Базовый RAG делает это с помощью обычного текста. Но вариант, который я исследую, который называется граф RAG, использует LLM для предварительного построения графа знаний корпуса. Затем он использует этот граф знаний для определения правильного контента для внедрения в подсказку.
https://commons.wikimedia.org/wiki/File:GraphRAG.svg
Поскольку граф знаний кодирует семантические связи между терминами, результаты более точны, чем при использовании простого RAG. Граф RAG также позволяет указать желаемый уровень детализации при взаимодействии с корпусом.
Например, я могу выдавать подсказки по конкретным элементам контента или «глобальные» подсказки на уровне всего корпуса, в зависимости от поставленной задачи.
В настоящее время я использую этот подход для реорганизации клиентского веб-сайта. Используя Graph RAG, я обобщил весь сайт, узнал о его содержании и даже попросил LLM помочь мне составить новые таксономии. В качестве бонуса я навсегда изгнал текст lorem ipsum из своих каркасов, поскольку теперь я могу легко генерировать реалистичный текст на основе самого содержимого веб-сайта.
Подробнее об этом варианте использования можно прочитать здесь.
Общие извлеченные уроки
То есть, LLM сделали мою работу быстрее и эффективнее. Но они также открыли мне новые способы работы с контентом в масштабе.
Эти системы обладают огромным потенциалом для организации больших репозиториев контента. Они уже сэкономили мне кучу времени и открывают другие возможности для улучшения и ускорения работы. LLM имеют очевидную ценность в этих вариантах использования.
Но заметьте, я не использую эти вещи для создания «живых» впечатлений на лету. В обоих случаях я использовал ИИ для дополнения своей работы в качестве информационного архитектора. Мои клиенты и я имеем окончательное решение о том, что пойдет в производство. Ключ в дополнении людей, а не в их замене.
Работа с ИИ требует иных рабочих процессов. Эти инструменты обладают потрясающими возможностями, но они не делают ничего из этого автоматически, несмотря на то, что маркетинговая шумиха заставляет вас верить. У LLM есть реальные ограничения, которые вы можете обнаружить, только фактически используя их.
Чтобы научиться дополнять свою работу с ИИ с помощью ИИ, нужно засучить рукава и использовать инструменты. К счастью, они легкодоступны. Также есть много способов узнать об этом.
Я создал страницу на своем сайте , которая объединяет ресурсы, связанные с ИИ. Там вы найдете более подробные описания и исходный код для большинства вариантов использования, которыми я поделился сегодня. Если вы экспериментируете с этим, пожалуйста, свяжитесь со мной. Мне бы очень хотелось узнать, как это у вас получается. Удачи!
Курирование и адаптация: Онтограф
