Адаптивний навчальний агент у LangGraph: стан учня, маршрутизація, людський огляд

Моделі мови можуть з великою вільністю пояснювати майже будь-яку тему, але вільність мовлення — це не показник засвоєння знань. Студент може прочитати добре сформульований опис технології генерації з підтримкою пошуку даних, кивати на знак згоди, проте все одно не вміти відрізнити пошук інформації від її доробки чи виявити посилання, яке не підтверджується жодними даними. Те, чого бракує, — це не генерація тексту. Це керування навчанням: збір доказів того, що людина зрозуміла матеріал, вибір відповідних заходів та перевірка їхньої ефективності.

Це креслення дизайну адаптивного навчального агента, створеного на основі LangGraph — системи зі станом, яка відстежує навчальні цілі, відповіді учнів, хибні уявлення, докази оцінювання та наступні кроки. Він поєднує сучасну інженерію агентів із старішими освітніми підходами, а саме формативним оцінюванням та навчанням через оволодіння знаннями. Мета не в тому, щоб замінити викладача автоматизацією, а в тому, щоб зробити цикл формативної роботи — діагностику, пояснення, практику, оцінювання, адаптацію та просування — чітким, перевірюваним та піддаємим тестуванню. Увага: це технічний дизайн, а не доказ того, що певний агент покращує результати. Для реального впровадження потрібен належний дизайн дослідження, перевірка доступності, заходи захисту приватності та керування з боку викладачів.

Генерація відповідей проти адаптації до учня

Чат-бот, який спочатку надає відповідь, отримує запит та повертає результат. Це може бути зручно, але ніщо не гарантує йому того, чи зрозумів учень матеріал, чи залишився якийсь помилок, чи що слід робити далі. Це може здаватися педагогічним підходом, проте насправді це просто розкішна функція автодоповнення.

Адаптивний викладач працює в іншій одиниці — епізоді навчання. Епізод починається з конкретної, вимірюваної мети, збирає дані з відповідей учня, інтерпретує їх за певними критеріями, обирає відповідну навчальну дію та фіксує все, що сталося, що означає, що стан має зберігатися протягом усіх цих кроків.

Цей дизайн віддзеркалює основну ідею формативної оцінки, де навчання та оцінювання взаємодіють, а докази розуміння визначають наступний вибір у навчанні. Він також віддзеркалює підхід до оволодіння знаннями, який передбачає надання коригувальних завдань та додаткового часу перед тим, як учень переходить до матеріалу, що ґрунтується на попередніх темах. Ці ідеї існують уже десятиліттями раніше за генеративний ШІ. Новизна полягає у можливості реалізувати їхні цикли зворотного зв’язку у видимому програмному забезпеченні, замість того щоб ховати їх у одному величезному запиті.

Чому граф кращий за ланцюжок запитів

У основі лежить спрямований граф G = (V, E). Вузли — це обмежені навчальні дії, ребра — переходи, дозволені між ними, а умовні ребра містять освітні рішення: просуватися далі, коли рівень оволодіння достатньо високий, виправляти помилки після виявлення певного хибного уявлення чи передавати завдання, коли ситуація невизначена або має високу значимість.

LangGraph підходить, оскільки він структурує додаток навколо спільного стану, вузлів, які його читають та оновлюють, та чітких переходів. Це набагато краще підходить для робочих процесів навчання, ніж єдина нечітка інструкція, яка мала б виступати у ролі корисного наставника, і це дозволяє ставити системі конкретні запитання. Які докази призвели до корекції? Яка версія критеріїв була застосована? Чи потрапила ризикована заявка до людського рецензента? Чи агент залишився у безкінечному циклі? Стан учня знаходиться в центрі, і вузли повинні свідомо його оновлювати, а не розглядати попередні розмови як неструктурований набір даних.

Мінімальний стан учня

Зберігайте лише те, що вимагає поточна мета та правила її досягнення. Стан не повинен перетворюватися на нечіткий набір особистих даних. Шість полів охоплюють основні елементи:

• learning_goal — спостережувана мета епізоду, наприклад, розрізнення RAG та фін-тюнінгу.
• learner_answer — докази, надані учнем, наприклад письмове пояснення чи аналіз коду.
• misconceptions — конкретні виявлені помилки, такі як припущення про автоматичну перевірку посилань.
• rubric_score — прозорий показник оцінки, наприклад 0,65 за шкалою, заснованою на критеріях.
• attempts — захід проти безкінечних спроб без результату, наприклад дві спроби виконати одну й ту саму задачу.
• next_action забезпечує прозорість рішення щодо подальших дій (виправлення чи просування), а needs_human_review — це прапорець безпеки та невизначеності, який активується у неоднозначних чи делікатних випадках.

У наведеному нижче прикладі використовується детерміністичне маршрутизування, щоб педагогічні рішення залишалися зрозумілими. У реальних умовах модель може допомогти сформулювати зворотний зв’язок або вказати можливі хибні уявлення учнів, проте критерії переходів мають залишатися незалежно перевірюваними.

from typing import Literal
from typing_extensions import TypedDict

class TutorState(TypedDict):
    learning_goal: str
    learner_answer: str
    misconceptions: list[str]
    rubric_score: float
    attempts: int
    needs_human_review: bool
    next_action: str
def choose_next_action(state: TutorState) -> Literal[
    "advance", "remediate", "human_review"
]:
    """Route using visible, reviewable instructional policy."""
    if state["needs_human_review"]:
        return "human_review"
    if state["rubric_score"] >= 0.80 and not state["misconceptions"]:
        return "advance"
    return "remediate"

Поріг не є універсальним і має обиратися та перевірятися для кожної конкретної мети. Важливо, щоб правило було оголошене, мало версію та дозволяло до себе підходити за допомогою тестів. Система не називає учня слабким; вона лише фіксує, що наявні докази ще не відповідають визначеному критерію.

Інструктивна схема

Ось компактна структура LangGraph, у якій діагностика, пояснення, практика, оцінювання, корекція, просування та людський огляд представлені як окремі вузли. Кожен вузол у продакшн-системі буде ґрунтуватися на перевіреному контенті, шкалі оцінювання та моделі чи сервісі пошуку, наданих ззовні, а не на жорстко закодованій відповіді.

from langgraph.graph import END, START, StateGraph

def diagnose(state: TutorState) -> dict:
    # Replace with a rubric-guided classifier or instructor-approved LLM call.
    answer = state["learner_answer"].lower()
    misconception = "citations are automatically verified" in answer
    return {
        "misconceptions": (
            ["Confuses generated citations with source verification"]
            if misconception else []
        )
    }
def explain(state: TutorState) -> dict:
    # In production: retrieve approved sources, then generate grounded feedback.
    return {"next_action": "practice"}
def practice(state: TutorState) -> dict:
    # In production: generate a new, equivalent item—not the same question again.
    return {"attempts": state["attempts"] + 1}
def evaluate(state: TutorState) -> dict:
    # Placeholder for a criterion-referenced evaluator with stored evidence.
    return {"next_action": choose_next_action(state)}
def route_after_evaluation(state: TutorState) -> str:
    return choose_next_action(state)
builder = StateGraph(TutorState)
builder.add_node("diagnose", diagnose)
builder.add_node("explain", explain)
builder.add_node("practice", practice)
builder.add_node("evaluate", evaluate)
builder.add_node("remediate", explain)
builder.add_node("advance", lambda state: {"next_action": "complete"})
builder.add_node("human_review", lambda state: {"next_action": "review"})builder.add_edge(START, "diagnose")
builder.add_edge("diagnose", "explain")
builder.add_edge("explain", "practice")
builder.add_edge("practice", "evaluate")
builder.add_conditional_edges(
    "evaluate",
    route_after_evaluation,
    {
        "advance": "advance",
        "remediate": "remediate",
        "human_review": "human_review",
    },
)
builder.add_edge("remediate", "practice")
builder.add_edge("advance", END)
builder.add_edge("human_review", END)tutor_graph = builder.compile()

Дві функції реалізовані навмисно. Цикл надсилає рекомендації щодо виправлення на нову можливість практики, а не просто довше пояснення. Умова зупинки припиняє автоматизований процес у разі, якщо щось виходить за межі правил, та направляє справу до інструктора або іншого авторизованого переглядача.

Де місце RAG

Для предметів, які потребують великої кількості контенту, вузол пояснень не повинен спиратися лише на внутрішні знання моделі. Він має черпати інформацію з схвалених, версіонованих навчальних матеріалів, передавати відповідні уривки моделі та вимагати посилань, які може перевірити учень. Саме це є справжньою функцією RAG тут: закріплення пояснень у ретельно підібраній базі знань.

Це не робить агента правильним за замовчуванням. Вам все одно потрібні правила вибору джерел, перевірка посилань, захист від вставки запитів та тести на непідтримувані твердження. Корисним правилом безпеки є змушувати агента казати, що доказів недостатньо, коли якість отриманої інформації погана, замість того, щоб заповнювати прогалини впевненою історією.

Оцінка на першому місці

Наявність графа не робить адаптивного агента надійним. Надійністю забезпечує вимірюваний інструктивний та безпековий рівень поведінки. Необхідно оцінити чотири рівні: навчання (чи покращилось розуміння, що оцінюється за допомогою перевірок концепцій до/після чи завдань на перенесення знань), педагогіка (чи була інтервенція відповідною, що оцінюється за експертним аналізом зворотного зв’язку та маршрутизації), система (чи дотримувався граф правил, що оцінюється за точністю маршруту, частотою циклів та затримкою) та безпека (чи працював він безпечно, що оцінюється за можливістю ескалації, тестами на конфіденційність та вставку даних).

Перш ніж оптимізувати інтерфейс, підготуйте невеликий набір тестових випадків із правильними поясненнями, типовими хибними уявленнями, неоднозначними відповідями, суперечливими інструкціями та випадками, що вимагають людського перегляду. Наведений нижче тест не визначає ефективність навчання, але виявляє базову проблему — маршрутизацію, яка суперечить заявленій політиці.

import pytest

@pytest.mark.parametrize(
    "state, expected",
    [
        ({
            "learning_goal": "Differentiate RAG and fine-tuning",
            "learner_answer": "A correct distinction",
            "misconceptions": [],
            "rubric_score": 0.92,
            "attempts": 1,
            "needs_human_review": False,
            "next_action": "",
        }, "advance"),
        ({
            "learning_goal": "Differentiate RAG and fine-tuning",
            "learner_answer": "Citations are automatically verified",
            "misconceptions": ["Citation-verification error"],
            "rubric_score": 0.45,
            "attempts": 1,
            "needs_human_review": False,
            "next_action": "",
        }, "remediate"),
    ],
)
def test_routing_policy(state, expected):
    assert choose_next_action(state) == expected

Тут агентський ШІ починає нагадувати дисципліновану інженерію програмного забезпечення. Твердження, фікси, версії коду, журнали трасування та записи рішень — це не бюрократичні додатки. Вони перетворюють вражаючу демонстрацію на систему з можливістю відповідальності.

Контроль як функція

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

Вбудуйте людський нагляд у граф як умови передачі обов’язків: оцінювач не впевнений, спроби продовжують зазнавати невдач, може постати питання про академічну чесність, наявність доступності є перешкодою, запит стосується питань безпеки, або учень безумовно потребує оцінки більше, ніж інший генерований абзац. Запишіть це у специфікацію перед тим, як викликати будь-яку модель. Справжнє питання полягає у тому, які рішення щодо навчання можна делегувати, які потребують перегляду та які докази підтримують кожен перехід, а не у тому, чи може агент навчати. Завдяки такому підходу освітяни зберігають контроль над проектуванням навчання, а інженери отримують вимоги, які можна перевірити.

Куди рухатися далі

Користь полягає у тому, що навчання розглядається як контрольований цикл зворотного зв’язку: починаємо з цілі, робимо висновок щодо стану учня на основі отриманих даних, обираємо відповідну дію, перевіряємо результат та вживаємо належних заходів. Твердження про трансформацію освіти слід відкласти. Спочатку створіть невелику прозору систему навколо однієї навчальної цілі, протестуйте її алгоритми, дослідіть, як вона впливає на розуміння, та вдосконалюйте її за участю викладачів та учнів. Це вищі вимоги, ніж просто здаватися корисним чат-ботом, і саме їх має досягати освітня ШІ.