IskayPet управляет более чем 330 зоомагазинами и ветеринарными клиниками в Испании, Португалии и Франции под брендами Kiwoko, Tiendanimal, Kivet, Clinicanimal и Animalis. В компании свыше 4500 сотрудников и 7 млн клиентов. Для них команда собрала корпоративного ассистента на Amazon Bedrock Managed Knowledge Bases: он отвечает на рабочие вопросы по розничным операциям, ветеринарии, онбордингу и закупкам на четырёх языках (испанский, португальский, французский, английский) в трёх странах.
Главное в этом кейсе то, чего в нём нет. Нет собственной векторной базы данных, нет embedding-пайплайна, нет очереди ingestion-задач, которые надо чинить ночью. Amazon Bedrock берёт на себя приём данных, мультимодальный парсинг, хранение векторов, генерацию эмбеддингов и извлечение, а компания платит за хранение и извлечение данных. Всю систему, от фронтенда для магазинов до архитектуры AWS и развёртывания, команда построила с помощью Kiro и Claude Haiku 4.5, как указано в описании кейса в блоге AWS.
Заявленные результаты: время поиска ответа сократилось с 3-5 минут до примерно 7 секунд, ожидаемая нагрузка около 100 тыс. запросов в месяц, в продакшене решение работает около двух месяцев. Это цифры из публикации AWS, независимого аудита за ними нет. Ниже разобрано, что именно они измеряют, где границы managed-подхода и какие настройки реально влияют на счёт.
Что именно построила IskayPet и почему это не обычный RAG
Классический корпоративный RAG это связка «коннектор к источнику, чанкер, модель эмбеддингов, векторная БД, реранкер, промпт». Каждый элемент нужно развернуть, обновлять и мониторить, а при смене модели эмбеддингов переиндексировать корпус. В кейсе IskayPet все эти компоненты отданы сервису, а команда оставила себе выбор источников, настройку retrieval, промпт и оценку качества.
Исходная боль: сотни документов SharePoint на четырёх языках
Офисные сотрудники искали ответы на операционные вопросы вручную, по сотням документов SharePoint: процедуры, политики, контракты, материалы онбординга. Ответ на банальный вопрос вроде порядка возврата товара, ветеринарного протокола или шага онбординга приходилось собирать из разных файлов, причём часть из них оказывалась устаревшей. Копились и ошибки: сотрудник находил похожий по названию документ и действовал по правилам другой страны или другого бренда.
Не хватало не LLM как таковой, а нормального retrieval поверх уже существующего корпоративного контента. Документы лежали на своих местах, права были настроены, языки согласованы, но между вопросом и нужным абзацем не было ничего, кроме поиска по названиям файлов.
Почему выбрали managed, а не self-hosted RAG
К системе предъявили несколько требований сразу:
- маршрутизировать вопрос в нужную область знаний (подразделение, страну) без перекрёстного загрязнения;
- добавлять новые области и страны без переархитектуры;
- цитировать источники, чтобы сотрудник мог проверить ответ;
- работать без собственной RAG-инфраструктуры на стороне команды.
Managed Knowledge Bases закрыл инфраструктурную часть, а модель оплаты в кейсе описана просто: платят за хранение и извлечение данных. Из этого не следует, что managed дешевле self-hosted в общем случае. При маленьком корпусе и низкой нагрузке собственный индекс на одной ноде может обойтись дешевле, а при высокой нагрузке счёт определяется входными токенами генерации. Сравнивать варианты стоит на своих объёмах и своём корпусе.
Архитектура решения: SharePoint, гибридный поиск и изоляция баз знаний
Поток данных в описанной схеме выглядит так: документы остаются в SharePoint, нативный коннектор индексирует их с расширенным разбором, поиск идёт в гибридном режиме с переранжированием, права проверяются на уровне документа, а ответ генерируется с цитатами. Каждый ассистент получает отдельную базу знаний.
Нативный коннектор SharePoint: переиспользование без миграции
Существующие репозитории SharePoint подключаются напрямую, без дорогостоящей миграции на другой источник. Для компании это экономит отдельный проект: знания остаются там, где сотрудники привыкли их вести, а ассистент читает их оттуда. Расширенная индексация включает контент из изображений, то есть сканы и картинки внутри документов тоже попадают в индекс. Насколько хорошо работает такой мультимодальный парсинг на конкретных корпусах, кейс не показывает, поэтому качество OCR стоит проверять на своих PDF и сканах до запуска.
Гибридный поиск с reranking: зачем нужны оба механизма
Лексический поиск находит точные совпадения: номера процедур, названия брендов, артикулы, аббревиатуры внутренних систем. Векторный поиск ловит смысловые совпадения и перефразировки, в том числе на другом языке: сотрудник спрашивает по-французски, а релевантный документ написан по-испански. По отдельности оба механизма дают провалы. Чистая лексика не находит переформулировок, чистая семантика теряет артикулы и коды.
Reranking добавляет третий шаг: модель переранжирования получает список кандидатов и переупорядочивает его по релевантности к вопросу. Именно поэтому извлекать пассажей больше, чем помещается в промпт, имеет смысл. Точную модель эмбеддингов, размер чанков и модель реранкера публичный разбор не раскрывает. Если вам нужны эти параметры, их придётся подбирать на своём корпусе.
Документ-уровневый контроль доступа на основе прав SharePoint
Права наследуются от существующих разрешений SharePoint и проверяются на уровне документа, а не строятся заново в отдельной модели. Это снимает целый класс задач: не нужно дублировать структуру групп, синхронизировать её и объяснять аудиторам, почему база знаний знает про права больше, чем сам источник.
Ограничение у подхода организационное. Схема работает, пока права в SharePoint поддерживаются в актуальном состоянии. Если конфиденциальный документ лежит в открытой для всех библиотеке, ассистент честно выдаст его сотруднику: он наследует вашу ошибку, а не исправляет её.
Отдельная база знаний под каждого ассистента
Страны и подразделения изолированы разными базами знаний. Вопрос про ветеринарные протоколы во Франции не тянет португальские розничные документы, а вопрос про закупки не смешивается с материалами онбординга. Побочный эффект приятный: маршрутизация становится явной. Часть маршрута задаёт интерфейс или обёртка агента, а не размытый фильтр по метаданным в одном общем индексе.
Масштабирование на новую страну сводится к подключению ещё одной базы и её наполнению, а не к переделке пайплайна. Если запросы становятся сложными и одного прохода поиска не хватает, следующим шагом обычно становится многошаговое извлечение с планировщиком, как в агентном поиске AgenticRetrieveStream для Bedrock Managed Knowledge Bases.
Настройки retrieval и генерации: где реально экономятся деньги
В разборе кейса указаны два параметра, которые сильнее всего влияют на счёт: количество извлекаемых пассажей и количество пассажей, попадающих в промпт. Дальше имеет значение промпт, потому что именно он задаёт поведение модели при нехватке данных.
25 пассажей на входе, 15 в промпте: как это работает
Сервис достаёт 25 пассажей, реранкер их переупорядочивает, в промпт уходят 15 лучших. Логика простая: извлечение и переранжирование стоят дешевле, чем генерация, поэтому выгодно дать реранкеру широкий список кандидатов и только потом урезать контекст. Input-токены оплачиваются на каждом запросе, и лишние 10 пассажей в промпте умножаются на 100 тыс. запросов в месяц.
Цифры 25 и 15 это отправная точка, а не универсальная рекомендация. На коротких FAQ-документах хватает меньшего числа пассажей, на длинных регламентах с перекрёстными ссылками урезание до 15 может отрезать нужный фрагмент. Проверять стоит по двум метрикам одновременно: доля ответов с корректной цитатой и средняя стоимость запроса.
Промпт с обязательным цитированием и отказом отвечать
Промпт требует двух вещей: ссылаться на источники и не отвечать, если данных в контексте нет. Второе важнее первого. Корпоративный ассистент, который уверенно выдумывает пункт политики возврата, обходится дороже, чем ассистент, который пишет «в предоставленных документах ответа нет». Сотрудник во втором случае идёт к коллеге и получает верный ответ, в первом действует по выдуманному регламенту.
Цитаты решают другую задачу: они делают ответ проверяемым. Сотрудник видит, из какого документа взята формулировка, и может открыть его сам. Это же снижает нагрузку на поддержку ассистента, потому что спорные случаи разбираются по ссылке, а не по пересказу.
Как оценивать качество RAG без собственного eval-пайплайна
В кейсе используется нативная оценка качества на основе пользовательских оценок: сотрудники ставят оценки ответам в интерфейсе, и этот сигнал показывает, как ассистент ведёт себя на реальных вопросах. Ценность в том, что вопросы настоящие: их формулируют люди, которые не знают, как устроен поиск, и потому пишут так, как написали бы коллеге.
Пользовательские оценки как источник сигнала
У такой обратной связи есть понятные границы. Люди охотнее оценивают неудачные ответы, чем удачные, поэтому распределение смещено. Эталона «правильного ответа» нет, значит нельзя посчитать точность в процентах. Оценки годятся для мониторинга тренда, поиска проблемных областей знаний и приоритизации доработок корпуса.
Для сравнения версий промпта или смены модели нужен офлайн-набор с эталонными ответами и метриками вроде доли корректных цитат и доли отказов на вопросах, где ответ в корпусе есть. Как собрать такой набор и не утонуть в галлюцинациях, разобрано в материале о метриках качества RAG.
Заявленные результаты: что стоит за цифрами
Три числа из публикации кейса стоит читать буквально.
- 3-5 минут против ~7 секунд. Речь о времени получения ответа: раньше сотрудник тратил 3-5 минут на ручной поиск по SharePoint, теперь получает ответ ассистента примерно за 7 секунд. Полное время решения рабочей задачи эти 7 секунд не покрывают: прочитать ответ, проверить цитату и применить правило всё равно придётся.
- ~100 тыс. запросов в месяц. Это ожидаемая нагрузка, а не подтверждённый факт из продакшена. Планирование бюджета на такой оценке делать рискованно, считать стоит по факту первых месяцев.
- Около двух месяцев в продакшене. Срок небольшой. Он говорит, что система работает и ею пользуются, но не показывает поведение на сезонных пиках и после существенного расширения корпуса.
Кейс опубликован в блоге AWS, то есть вендором, который заинтересован в успешности сервиса. Независимых замеров задержки, точности ответов и стоимости запроса в открытых источниках нет.
Кому подходит managed RAG, а кому нет
Проверить решение на соответствие можно по короткому списку criteria.
Подходит, если:
- знания уже живут в SharePoint и переезд на другой источник это отдельный дорогой проект;
- работа идёт в нескольких странах и на нескольких языках, а документы дублируются с локальными отличиями;
- права доступа настроены в источнике и поддерживаются в актуальном состоянии;
- нужен запуск за недели, а команды на поддержку векторной БД и ingestion-пайплайнов нет;
- инфраструктура уже в AWS.
Не подходит, если:
- есть требование держать данные и модели полностью в своём контуре;
- нужен нестандартный retrieval: свои чанкеры, специфический реранкер, обход иерархии документов или сложная логика слияния результатов;
- корпус и нагрузка таковы, что input-токены становятся основной строкой счёта;
- компания не работает в AWS и не готова входить в экосистему ради одного ассистента;
- запросы аналитические, а не фактологические: тут классический RAG по пассажам упирается в потолок, и подходы вроде сжатия базы знаний под аналитические задачи решают другую проблему.
Ограничение первое: стоимость input-токенов
Платят за хранение и извлечение, но генерация упирается во входные токены, а их объём задаёт число пассажей в промпте. При 100 тыс. запросов в месяц и длинных фрагментах счёт растёт линейно вместе с нагрузкой. Рычаги три: сокращать число пассажей в промпте, укорачивать сами пассажи при индексации и кэшировать ответы на повторяющиеся вопросы. Первый рычаг рискует качеством, второй требует аккуратного чанкинга, третий не работает на длинном хвосте уникальных вопросов.
Конкретных цифр за 1000 токенов и месячных счетов кейс не приводит, так что экономику придётся считать по своему прайсу и своему среднему числу запросов.
Ограничение второе: зависимость от экосистемы AWS
Решение стоит на Managed Knowledge Bases, нативном коннекторе SharePoint и архитектуре AWS. Перенос на другую платформу означает пересборку ingestion и retrieval, а не смену эндпоинта. Для компании, которая уже живёт в AWS, это небольшой дополнительный риск. Для остальных это отдельный аргумент, который стоит взвесить до пилота, особенно если корпоративные стандарты разрешают работать с несколькими облаками.
Что забрать из кейса, если вы строите корпоративного ассистента
Пять выводов, которые переносятся на любую платформу.
- Начинайте с существующего хранилища знаний. Миграция контента это отдельный проект с отдельным бюджетом и сопротивлением владельцев документов. Коннектор к тому, что уже есть, экономит месяцы.
- Изолируйте базы знаний по странам и подразделениям. Несколько баз с явной маршрутизацией предсказуемее одного общего индекса с фильтрами по метаданным: фильтр легко забыть, а базу спутать нельзя.
- Наследуйте права доступа от источника. Своя модель прав устаревает быстрее, чем права в SharePoint, и создаёт ложное чувство контроля.
- Разделяйте число извлекаемых пассажей и число пассажей в промпте. Широкое извлечение плюс reranking плюс узкий контекст в промпте дают лучшее соотношение качества и стоимости, чем одинаковые числа на обоих шагах.
- Требуйте цитат и отказов. Промпт с обязательной ссылкой на источник и запретом отвечать без данных меняет поведение ассистента сильнее, чем замена модели.
Что кейс не раскрывает: схему чанкинга, модель эмбеддингов, модель реранкера, состав модели доступа и точные расценки. Эти параметры придётся подбирать самому. Managed RAG снимает инфраструктурную работу, но не снимает ответственность за качество корпуса, промпта и набора проверочных вопросов.