Багатомовний помічник для студентів, який відповідає лише за перевіреними даними

Студенти ставлять дрібні практичні запитання. Коли здавати завдання? Чи працює бібліотека в неділю? Де служба 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 дає розуміння мови й багатомовну генерацію. У поєднанні з пошуком, структурованими даними, зазначенням джерел і готовністю відмовити він стає чимось кращим за простого чат-бота.

Питайте природно. Шукайте ретельно. Генеруйте з перевіреної інформації.