В нашей системе предусмотрена очередь запросов и понятие пиковых нагрузок — это нормальная ситуация, когда запросов значительно больше, чем одновременно можем обработать. При таких пиках они обрабатываются последовательно, с допустимой задержкой для пользователей. Всё оборудование — наше, что позволяет более гибко контролировать масштабируемость, инфраструктуру и доступность.
Знакомый никнейм, где-то я вас уже видел в комментариях к прошлым статьям! :)
Спасибо за приятные слова и за комментарий.
Планы по масштабированию действительно есть — мы уже ведём переговоры с другими университетами и готовы предложить систему тем, у кого схожие процессы и содержание. Архитектура проекта модульная и адаптивная: компоненты (ретривер, проверка контента, RAG-узлы, SQL-модуль и т.д.) работают независимо и взаимодействуют через чётко определённые интерфейсы. Это позволяет легко подключать новые источники данных, включая внутренние базы других вузов, и адаптировать SQL-модуль под различные структуры: изменение схем, новые запросы и источники — всё это можно внедрить без полной переработки системы.
Спасибо вам за похвалу и за комментарий, так же отвечу на ваши вопросы:
Мы используем гибридный подход: основная фильтрация — через простой словарь, а дополнительная проверка — через LLM внутри системного промпта. Модуль модерации интегрирован в общую схему через узел censorship_check — так мы блокируем нецензурку, токсичные или провокационные сообщения, включая попытки prompt-инъекций, ещё до формирования ответа и очистки истории.
О, это прекрасные новости, надеюсь, увидим вашу реализацию на Хабре :)
Спасибо большое за комментарий, отвечаю по пунктам:
Почему была выбрана эта коллекция эмбеддеров? Как часто ретривер находит подходящий результат? В проде остановились на выборе топ-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 по умолчанию склонна «додумывать» ответ. Мы решили это через отдельную ноду, которая занимается только обработкой случаев неопределённости. Там зашиты шаблонные ответы с перенаправлением: ссылки на документацию, контакты специалистов или заглушки с вариантами обращения к человеку. То есть модель не принимает решение «сама признаться, что не знает», а архитектурно заложен маршрут, куда попадает запрос, если вероятность корректного ответа низкая.
Для этого создали внутренний бенчмарк + очень удобно понимать как обновления влияют на общую погоду и по каждой группе вопросов в отдельности. По бенчмарку 99%. В него входят ключевые 94 вопроса. По логам анализ показал 91%
Только в нашем FAQ более 1.5 тысячи вопросов - представляем пользовательский путь поиска своего вопрос-ответа, если добавить все варианты вопросов по сравнению 100+ обр. програм по более чем 25 критериям (сколько же различных сочетаний) + добавить варианты вопросов из RAG-БД по более чем 15 документам
Снижение. На провокативных вопросах чаще включается ЦЕНЗОР у коммерческих моделей вероятно. Постараемся об этом подробнее написать с примерами в статьях сл года.
Хм... мы же не про должен, а про померить открыто фактологию. Разные ЦА (пользователи умных колонок, сервисов), особенно в школьном периоде, могут же понимать что ответы LLM не идеальны ;-) Вообще круто, если сами скачают фреймворк и проверят любимые модельки по нашему открытому набору данных или по своему (что скорее всего)
Ага, но пока не вышла вторая часть с подробным описанием как получилась таблица оценок, можно посмотреть лидерборд на huggingface (туда недавно добавили еще Claude-3.5 и GPT-4o)
напишите кому-нибудь лично из авторов
Добрый день! Благодарим за похвалу, вот писали про людей, которые работали над проектом:
Спасибо большое за комментарий!
В нашей системе предусмотрена очередь запросов и понятие пиковых нагрузок — это нормальная ситуация, когда запросов значительно больше, чем одновременно можем обработать. При таких пиках они обрабатываются последовательно, с допустимой задержкой для пользователей. Всё оборудование — наше, что позволяет более гибко контролировать масштабируемость, инфраструктуру и доступность.
Знакомый никнейм, где-то я вас уже видел в комментариях к прошлым статьям! :)
Спасибо за приятные слова и за комментарий.
Планы по масштабированию действительно есть — мы уже ведём переговоры с другими университетами и готовы предложить систему тем, у кого схожие процессы и содержание.
Архитектура проекта модульная и адаптивная: компоненты (ретривер, проверка контента, RAG-узлы, SQL-модуль и т.д.) работают независимо и взаимодействуют через чётко определённые интерфейсы. Это позволяет легко подключать новые источники данных, включая внутренние базы других вузов, и адаптировать SQL-модуль под различные структуры: изменение схем, новые запросы и источники — всё это можно внедрить без полной переработки системы.
Спасибо вам за похвалу и за комментарий, так же отвечу на ваши вопросы:
Мы используем гибридный подход: основная фильтрация — через простой словарь, а дополнительная проверка — через LLM внутри системного промпта. Модуль модерации интегрирован в общую схему через узел censorship_check — так мы блокируем нецензурку, токсичные или провокационные сообщения, включая попытки prompt-инъекций, ещё до формирования ответа и очистки истории.
О, это прекрасные новости, надеюсь, увидим вашу реализацию на Хабре :)
Спасибо большое за комментарий, отвечаю по пунктам:
Почему была выбрана эта коллекция эмбеддеров? Как часто ретривер находит подходящий результат?
В проде остановились на выборе топ-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 по умолчанию склонна «додумывать» ответ. Мы решили это через отдельную ноду, которая занимается только обработкой случаев неопределённости. Там зашиты шаблонные ответы с перенаправлением: ссылки на документацию, контакты специалистов или заглушки с вариантами обращения к человеку. То есть модель не принимает решение «сама признаться, что не знает», а архитектурно заложен маршрут, куда попадает запрос, если вероятность корректного ответа низкая.
В конце августа очень может быть =)
https://habrastorage.org/webt/c_/-b/yb/c_-bybh5l5vgssyc6lfhgzehwp4.jpeg
Для этого создали внутренний бенчмарк + очень удобно понимать как обновления влияют на общую погоду и по каждой группе вопросов в отдельности. По бенчмарку 99%. В него входят ключевые 94 вопроса. По логам анализ показал 91%
Только в нашем FAQ более 1.5 тысячи вопросов - представляем пользовательский путь поиска своего вопрос-ответа, если добавить все варианты вопросов по сравнению 100+ обр. програм по более чем 25 критериям (сколько же различных сочетаний) + добавить варианты вопросов из RAG-БД по более чем 15 документам
Спасибо! Сейчас готовим материал по еще одному бенчмарку TrustGen.
На наш взгляд, количество и качество междисциплинарных центров компетенций по ИИ должно увеличиваться! Спасибо!
Снижение. На провокативных вопросах чаще включается ЦЕНЗОР у коммерческих моделей вероятно. Постараемся об этом подробнее написать с примерами в статьях сл года.
Такой цели не ставили. Just Fact-checking.
Хм... мы же не про должен, а про померить открыто фактологию. Разные ЦА (пользователи умных колонок, сервисов), особенно в школьном периоде, могут же понимать что ответы LLM не идеальны ;-) Вообще круто, если сами скачают фреймворк и проверят любимые модельки по нашему открытому набору данных или по своему (что скорее всего)
Ага, но пока не вышла вторая часть с подробным описанием как получилась таблица оценок, можно посмотреть лидерборд на huggingface (туда недавно добавили еще Claude-3.5 и GPT-4o)