Презентация OpenSearch от AWS в преддверии OpenSearchCon | VentureBeat

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

Июльское исследование VentureBeat, посвященное контекстным слоям, показало, что 68% респондентов сталкивались с ошибками агентов, связанными с контекстом, и только у 32% управляемые контекстные слои работали в продакшене (в опросе участвовал 101 респондент). Этот разрыв определяет главную проблему для OpenSearch: сделать информацию доступной для поиска — это лишь часть задачи по обеспечению ее надежности.

Тиа Уайт (Tia White), генеральный менеджер направления OpenSearch в AWS, является одной из главных докладчиков на конференции OpenSearchCon North America, которая пройдет с 22 по 24 сентября в Сан-Хосе. На ней также выступят Атри Шарма (Atri Sharma) и Абхишек Сингх (Abhishek Singh) из Apple; Пушкала Паттабхираман (Pushkala Pattabhiraman) из IBM; Сократис Пападопулос (Sokratis Papadopoulos) из CERN; Минмин Чен (Mingmin Chen) из Uber; и исполнительный директор OpenSearch Software Foundation Бьянка Льюис (Bianca Lewis).

Я тоже там буду. Если вы планируете посетить конференцию и решаете вопросы, связанные с поиском информации, памятью агентов или экономикой производственного ИИ, <почему бы нам не связаться? Буду рад пообщаться.

Мой недавний разговор с Уайт служит отличной отправной точкой. Она рассказала о стратегии AWS, которая объединяет несколько методов поиска, решает проблему непредсказуемой нагрузки, создаваемой агентами, и расширяет роль поисковой инфраструктуры в управлении контекстом.

Поиск становится более масштабным решением на уровне инфраструктуры

Amazon OpenSearch Service объединяет возможности, которые компании часто оценивают по отдельности: полнотекстовый поиск, векторный поиск, гибридный поиск и операционную аналитику. 

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

В нашей беседе Уайт подчеркнула возможность для клиентов распространить существующее развертывание OpenSearch на рабочие нагрузки ИИ. Для организаций, которые уже используют этот сервис, это может избавить от необходимости внедрять еще одну базу данных, настраивать новую безопасность и создавать дополнительные рабочие процессы.

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

Разница между проектом с открытым исходным кодом и управляемым сервисом AWS также имеет значение. В 2024 году проект OpenSearch перешел под эгиду OpenSearch Software Foundation при поддержке Linux Foundation. Amazon OpenSearch Service — это управляемое предложение AWS, созданное на базе этой технологии; его коммерческую дорожную карту следует оценивать отдельно от управления и развития сообщества проекта.

Агенты меняют экономику поиска

Потребность агента в поиске может существенно меняться в рамках даже одного рабочего процесса. Он может выполнить поиск, изучить результаты, переформулировать вопрос и выполнить поиск снова. Для множества агентов такая схема усложняет планирование емкости ресурсов.

Сервис AWS OpenSearch Serverless, который стал общедоступен в мае, призван решить эту проблему. Он разделяет вычислительные мощности и хранилище и, по заявлению AWS, выделяет ресурсы за считанные секунды с масштабированием, которое до 20 раз быстрее по сравнению с предыдущей версией. AWS также заявляет об экономии до 60% по сравнению с выделением кластеров OpenSearch под пиковые нагрузки. Однако это заявления вендора, привязанные к конкретным условиям сравнения, а не гарантия для любого развертывания.

Практическая выгода заключается в сокращении объема простаивающих мощностей, которые команде приходится поддерживать для обработки всплесков нагрузки. Масштабирование до нуля также требует внимательного подхода: документация AWS описывает это для подходящих коллекций нового поколения в группах коллекций. Командам следует проверить свои настройки и оценить поведение системы в соответствии с требованиями приложения к времени отклика. Документация AWS по масштабированию до нуля объясняет эти условия.

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

Те же агенты порождают расходы на наблюдаемость

Агенты используют контекст, одновременно генерируя логи, трассировки и записи об активности инструментов. Это создает еще одну инфраструктурную проблему: необходимость сохранять достаточно данных, чтобы понять, что пошло не так при сбое агента.

Оптимизированный аналитический движок логов от AWS объединяет колонночную аналитику с полнотекстовым поиском. Колонночная обработка поддерживает агрегацию и анализ трендов; полнотекстовый поиск помогает исследователям локализовать конкретную ошибку или событие. AWS заявляет об улучшении соотношения цены и производительности до четырех раз и двукратном росте скорости аналитических запросов для оптимизированного движка.

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

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

Корпоративным архитекторам следует оценивать операционные преимущества консолидации, сохраняя при этом гибкость выбора конфигурации под нужды каждого конкретного приложения. 

Память агента и институциональная память — это не одно и то же

Уайт назвала память, планирование запросов, рассуждения и оценку теми областями, где поисковая инфраструктура может принести наибольшую пользу.

Память уже выходит за рамки простого позиционирования. В OpenSearch 3.5 появилась постоянная память диалогов агентов, а в марте AWS объявила о поддержке этой версии в Amazon OpenSearch Service. Эта функция сохраняет контекст беседы и логику работы с инструментами при различных взаимодействиях.

Более масштабная задача для предприятия — решить, что должно стать долговечной памятью агента, а что — институциональной памятью, составляющей ключевую интеллектуальную собственность.

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

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

На конференции OpenSearchCon я буду искать примеры внедрения, которые показывают, как практиники справляются с этими проблемами, наряду с их результатами по релевантности и производительности.

Как проверить это на собственном стеке технологий

Оценивать решение следует с одного репрезентативного рабочего процесса.

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

Эти результаты определят, упростит ли расширение OpenSearch архитектуру и улучшит ли конечные результаты.

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