Comments 20
Если так хочется сократить расходы на службу поддержки, можно было просто разместить на сайте F.A.Q. и объявить, что у вас нет службы поддержки (R.T.F.M.)
Только в нашем FAQ более 1.5 тысячи вопросов - представляем пользовательский путь поиска своего вопрос-ответа, если добавить все варианты вопросов по сравнению 100+ обр. програм по более чем 25 критериям (сколько же различных сочетаний) + добавить варианты вопросов из RAG-БД по более чем 15 документам
Спасибо за описание кейса. Если не секрет, каков процент правильных ответов LLM?
Вопросы вида поступил или нет - 50% =)
https://habrastorage.org/webt/c_/-b/yb/c_-bybh5l5vgssyc6lfhgzehwp4.jpeg
Для этого создали внутренний бенчмарк + очень удобно понимать как обновления влияют на общую погоду и по каждой группе вопросов в отдельности. По бенчмарку 99%. В него входят ключевые 94 вопроса. По логам анализ показал 91%
Хороший разумный кейс применения.
Вопрос первый , вы одним промтом покрываете все, или у вас именно агент который диалог ведет и уточняет что-то?
Вопрос второй, так ли просто заставить LLM признать что она не знает чего-то и перенаправить к живому специалисту? По моему опыту, это прям не самая простая задача. Она иногда лучше выдумает, чем примет решение что не знает.
Спасибо большое за комментарий!
Про промпты и архитектуру.
Мы не ограничивались одним универсальным промптом. Для каждой ноды в пайплайне настроены отдельные системные промпты, которые выполняют свою роль: где-то уточняют ввод, где-то форматируют данные, где-то проверяют корректность ответа. В статье мы не стали детализировать всю схему, чтобы не перегружать текст, но на практике это именно набор специализированных узлов, а не «один промпт на всё».
Про «признать, что не знает».
Да, согласен — это действительно непростая задача. LLM по умолчанию склонна «додумывать» ответ. Мы решили это через отдельную ноду, которая занимается только обработкой случаев неопределённости. Там зашиты шаблонные ответы с перенаправлением: ссылки на документацию, контакты специалистов или заглушки с вариантами обращения к человеку. То есть модель не принимает решение «сама признаться, что не знает», а архитектурно заложен маршрут, куда попадает запрос, если вероятность корректного ответа низкая.
Я студент и пока только учусь, но занимаюсь реализацией схожей системы для своего ВУЗа, соответственно у меня возникло несколько вопросов:
Почему была выбрана данная коллекция эмбеддеров? Как часто и точно ретривер находит подходящий результат?
Почему использовалась именно БД Milvus? Чем не подошёл Postgres с векторным хранилищем или же популярные ChromaDB и Faiss?
Рассматривалась ли LLM поменьше? Было ли в планах заняться дообучением модели и при этом нарастить уже существую реализацию для более точной работы сервиса? Или же это лишнее/не эффективно?
Как вы пытались бороться с галлюцинациями помимо систменого промпта?
О, это прекрасные новости, надеюсь, увидим вашу реализацию на Хабре :)
Спасибо большое за комментарий, отвечаю по пунктам:
Почему была выбрана эта коллекция эмбеддеров? Как часто ретривер находит подходящий результат?
В проде остановились на выборе топ-5 ближайших чанков. Пробовали разные варианты (например, 3 и 10), но при 3 чанках часть полезного контекста терялась, а при 10 качество ухудшалось за счёт лишнего «шума». Формат из 5 чанков оказался оптимальным — он покрывал большинство кейсов без усложнения логики.
Почему Milvus, а не Postgres/Chroma/FAISS?
Выбрали Milvus по прагматичной причине — нужно было быстро и надёжно развернуть векторное хранилище, которое умеет шардировать, реплицировать и имеет готовые ANN-индексы для миллионов векторов. Для небольших коллекций pgvector/Postgres или Chroma отлично подходят, но при высоких объёмах и пиковой нагрузке удобнее использовать специализированную систему вроде Milvus.
Рассматривалась ли LLM поменьше и планировалось ли дообучение?
Файнтюн мы не делали — использовали готовые модели и сравнивали их между собой. Тестировали, например: qwen2.5-72b, ruadapt_qwen2.5_32b:Q4_K_M, RuadaptQwen2.5-32B-Pro-Beta, YandexGPT-5-Lite-8B-instruct, T-pro-it-2.0-AWQ, Qwen3-32B-AWQ. Но либо качество ответов оказывалось хуже, либо время отклика не укладывалось в требования, поэтому оставили текущую реализацию без дообучения.
Как боролись с галлюцинациями помимо системного промпта?
По сути, дополнительных сложных схем мы формально не вводили — основная защита была простая: если уверенность низкая, запрос уходит в ноду-заглушку с ссылками/контактами сотрудника. То есть сейчас — system prompt + fallback-node; в будущем можно добавить reranker, confidence-gating и явную атрибуцию источников для уменьшения галлюцинаций, но сейчас у нас именно минималистичная схема.
Спасибо за интересную статью, и сразу вопрос: Почему нецензурщина проверяется через общий промпт? То есть если человек напишет оскорбление или провокацию, то они останутся внутри истории общения? Не лучше ли выделить отдельный модуль проверки сообщений на корректность? Туда же можно добавить проверку на промпт-инъекции
Спасибо вам за похвалу и за комментарий, так же отвечу на ваши вопросы:
Мы используем гибридный подход: основная фильтрация — через простой словарь, а дополнительная проверка — через LLM внутри системного промпта. Модуль модерации интегрирован в общую схему через узел censorship_check — так мы блокируем нецензурку, токсичные или провокационные сообщения, включая попытки prompt-инъекций, ещё до формирования ответа и очистки истории.
Отличный пример продакшен-кейса. Есть ли планы масштабировать решение и предлагать его другим вузам, или архитектура слишком завязана на внутренние базы РАНХиГС?
Знакомый никнейм, где-то я вас уже видел в комментариях к прошлым статьям! :)
Спасибо за приятные слова и за комментарий.
Планы по масштабированию действительно есть — мы уже ведём переговоры с другими университетами и готовы предложить систему тем, у кого схожие процессы и содержание.
Архитектура проекта модульная и адаптивная: компоненты (ретривер, проверка контента, RAG-узлы, SQL-модуль и т.д.) работают независимо и взаимодействуют через чётко определённые интерфейсы. Это позволяет легко подключать новые источники данных, включая внутренние базы других вузов, и адаптировать SQL-модуль под различные структуры: изменение схем, новые запросы и источники — всё это можно внедрить без полной переработки системы.
Спасибо за статью.
Модель генерации — Qwen3-32B-AWQ, запущенная через движок vLLM на GPU-сервере с NVIDIA A6000. Такой стек даёт стабильную скорость и возможность обслуживать несколько одновременных обращений.
Вам хватает что можно - "обслуживать несколько одновременных обращений" ? Это типовая нагрузка у вас, нет такого что приходят 10-100 человек и бот не сможет вытянуть?
Так же интересно, оборудование вы арендуете?
Спасибо большое за комментарий!
В нашей системе предусмотрена очередь запросов и понятие пиковых нагрузок — это нормальная ситуация, когда запросов значительно больше, чем одновременно можем обработать. При таких пиках они обрабатываются последовательно, с допустимой задержкой для пользователей. Всё оборудование — наше, что позволяет более гибко контролировать масштабируемость, инфраструктуру и доступность.
Отличная статься, с очень актуальным опытом!
Нейропомощник "Академий" был создан командой разработки "Исследовательского центра искусственного интеллекта" в РАНХиГС.
У вас получается целый отдел под ИИ, специалисты которого только на нем специализируются? Сколько человек если не секрет, и сколько понадобилось для создания подобной системы? (Ключевые роли)
Добрый день! Благодарим за похвалу, вот писали про людей, которые работали над проектом:
Над статьей работали Боловцов Сергей, Четвергов Андрей, Кащенко Екатерина, Сиворакша Тимофей, Шарафетдинов Ринат, Голосов Павелтакже принимали активное участие Полукошко Марина, Уколов Степан, Оружейникова Наталия, Ершов Даниил
Как мы научили LLM отвечать на вопросы абитуриентов в крупнейшем вузе страны