Многоязычный помощник для студентов, который отвечает только по проверенным данным

Студенты задают мелкие практические вопросы. Когда сдавать задание? Открыта ли библиотека в воскресенье? Где находится служба IT-поддержки? Кто отвечает за студенческие услуги? Ответы обычно существуют, но разбросаны по объявлениям, страницам LMS, расписаниям, письмам, групповым чатам и разным отделам. CampusAI — прототип, который упрощает такой поиск и при этом не превращается в чат-бота, уверенно выдумывающего ответы.

Что это такое

CampusAI — многоязычный ассистент поддержки студентов для вузов. Вместо того чтобы рыться в нескольких системах, студент пишет обычный вопрос, например «Когда сдавать задание по сетевой безопасности?». Приложение ищет по институциональной базе знаний, выбирает подходящую запись, отправляет в Google Gemini только её и получает понятный студенту ответ. Оно работает на английском, тамильском и сингальском, потому что ассистент не должен загонять всех студентов в один язык.

Настоящая проблема

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

Отсюда три принципа: сначала найти, потом сгенерировать и указать источник.

Как всё устроено

Архитектура намеренно простая. Вопрос проходит через интерфейс в поисковый движок, который обращается к базе знаний. До Gemini доходят только релевантные записи, а ответ возвращается на языке студента вместе с источником:

Student
   ↓
CampusAI UI
   ↓
Retrieval Engine
   ↓
Campus Knowledge Base
   ↓
Relevant Records
   ↓
Google Gemini
   ↓
Multilingual Answer + Source

Прототип написан на Python и Streamlit, использует Google Gemini через Google Gen AI SDK, хранит институциональные знания в JSON, опирается на собственный слой поиска и оценки релевантности, а изменения отслеживаются в Git и GitHub.

Как организованы знания

Вместо одного огромного файла данные разбиты по темам, по одному файлу на область:

data/
├── assignments.json
├── contacts.json
├── courses.json
├── general.json
├── library.json
├── policies.json
└── services.json

Одна запись о библиотеке выглядит так:

{
  "id": "LIB-001",
  "category": "library",
  "title": "Library Opening Hours",
  "content": "The campus library is open Monday to Friday from 8:00 AM to 6:00 PM. On Saturday it is open from 8:00 AM to 1:00 PM. The library is closed on Sunday.",
  "source": "Library Information Notice"
}

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

Поиск идёт раньше генерации

Первая версия отправляла в Gemini всю базу знаний с каждым вопросом. Это работало, но не масштабируется. Чем больше информации у учебного заведения, тем расточительнее отправлять всё подряд, а посторонний контент делает привязку к фактам менее точной.

Поэтому добавили слой поиска. Для вопроса вроде того, что про задание, ретривер проходит такие шаги:

1. Нормализует вопрос.
2. Убирает малозначимые слова.
3. Определяет вероятные категории.
4. Сравнивает значимые термины.
5. Оценивает записи-кандидаты.
6. Отсеивает слабые совпадения.
7. Возвращает только самые сильные.

Вот что получается для вопроса о задании:

Question:
When is my Network Security assignment due?

        ↓

Retriever

        ↓

ASSIGN-001
Network Infrastructure Security Assignment

Deadline:
30 September 2026

Submission:
LMS

Source:
Network Security Assignment Notice

Только после этого Gemini что-то видит. Его задача — понять формулировку студента и естественно изложить найденные факты, а не угадывать факты о кампусе самостоятельно.

Когда ничего не должно совпасть

Тестирование выявило полезный сбой. Кто-то спросил меню столовой на завтра, а в базе знаний о столовых нет ничего. Тем не менее ретривер возвращал посторонние записи, потому что частые слова вроде «what», «is» и «the» встречались в разных документах.

Исправление состояло из нескольких частей:

• Фильтровать стоп-слова.
• Требовать значимого пересечения токенов.
• Придать категориям больший вес.
• Поддержать совпадения по ключевым фразам из нескольких слов.
• Ввести минимальный порог релевантности.

После этого тот же вопрос обрабатывается правильно:

Question:
What is tomorrow's cafeteria menu?

Ретривер ничего не возвращает:

Records found: 0

Тогда ассистент говорит, что не может найти проверенную информацию, а не выдумывает меню. Этот отказ — одно из самых важных поведений во всём проекте.

Ответ пишет Gemini

Найденные записи отправляются в Gemini вместе со строгими инструкциями. Модель не должна выдумывать сроки сдачи, расписания, преподавателей, аудитории, стоимость обучения, правила, контакты или объявления. Если совпадение есть, модель превращает его в понятное предложение. На вопрос о задании ответ называет срок 30 сентября 2026 года и говорит сдать работу через LMS, а затем добавляет источник — объявление о задании. Указание источника показывает студенту, откуда взялся ответ.

Три языка, одна база знаний

Студент может спросить про библиотеку на английском, тамильском или сингальском. Найденная запись остаётся в одном структурированном формате, а Gemini отвечает на том языке, которым воспользовался студент. Это гораздо гибче, чем держать отдельного чат-бота для каждого языка.

Разбор примера

Допустим, в записи о библиотеке указаны такие часы работы:

Library hours

Monday–Friday:
8:00 AM – 6:00 PMSaturday:
8:00 AM – 1:00 PMSunday:
Closed

Студент спрашивает, открыта ли библиотека в воскресенье. Ретривер находит запись о библиотеке, и Gemini отвечает, что в воскресенье она закрыта, ссылаясь на информационное объявление библиотеки. Студенту не нужно знать, лежит ли ответ в JSON-файле, расписании, объявлении или базе данных. Он просто спрашивает.

Ответственное поведение заложено изначально

CampusAI пока прототип, но безопасное поведение — часть дизайна, а не поздняя надстройка. Он соблюдает пять мер защиты:

1. Факты о кампусе должны браться из найденных записей, и Gemini запрещено использовать для них общие знания.
2. Минимальный порог релевантности отклоняет совпадения с низкой уверенностью.
3. Если подходящего нет, студенту сообщают, что проверенную информацию найти не удалось.
4. Каждая запись хранит институциональный источник, использованный для ответа.
5. В демо нет чувствительных данных: ни студенческих ID, ни оценок, ни медицинских сведений, ни паролей, ни финансовой информации, ни личных записей.

Перед тем как касаться персональных данных студентов, в продакшене понадобятся аутентификация и контроль доступа.

Интерфейс

Фронтенд сделан на Streamlit и должен казаться знакомым всем, кто пользовался современными диалоговыми ИИ-продуктами. В нём есть область диалога, боковая панель, подсказки вопросов, сведения о языке, кнопка нового чата, постоянное поле ввода и читаемые ответы. Визуальный дизайн намеренно простой. Важна не анимация. Важно, сможет ли студент спросить, где получить IT-поддержку, и быстро получить правильный ответ.

Как проводилось тестирование

Проверяли несколько видов вопросов. Известная информация:

What are the library opening hours?

Задания:

When is my Network Security assignment due?

Услуги кампуса:

Where can I get IT support?

Тамильский: вопрос на смеси языков о том, когда сдавать задание:

Network Security assignment எப்போது submit செய்ய வேண்டும்?

Сингальский: вопрос о том, где находится стойка IT-поддержки:

IT support එක කොහෙද තියෙන්නේ?

И информация, которой не существует:

What is tomorrow's cafeteria menu?

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

Выводы

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

Самое большое улучшение дало не переписывание промпта. Его дал слой поиска, который решает, что Gemini разрешено увидеть до того, как модель что-либо сгенерирует. Поведение стало предсказуемее, а у системы появилась гораздо более ясная структура.

Что может быть дальше

Проект — это MVP, и несколько направлений выглядят перспективно:

• Семантический поиск. Сейчас используются определение категорий и оценка релевантности. Для больших наборов данных можно перейти на эмбеддинги и векторный поиск.
• Загрузка документов. Администраторы могли бы загружать проверенные файлы — PDF-объявления, положения, справочники, расписания и памятки для студентов, — а приложение индексировало бы их само.
• Интеграция с LMS. Реальная утверждённая информация могла бы поступать прямо из LMS, а не из демонстрационных JSON-файлов.
• Аутентификация студентов. Вошедшие в систему студенты видели бы информацию по своей программе или курсу при надлежащем контроле доступа.
• Аналитика для администрации. Учебные заведения могли бы узнавать, какие вопросы задают чаще всего и какую информацию студентам труднее найти.
• Развёртывание в облаке. Текущая версия работает локально, но может стать масштабируемым веб-сервисом в Google Cloud.

Идея в одной строке

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

Спрашивайте естественно. Ищите аккуратно. Генерируйте из проверенной информации.