ADR-0003: AI-персоналізація — grounded generation з fact-merge boundary

Статус: accepted · 2026-06-06 · власник @Vladbandurin

Контекст

Ядро системи — AI-персоналізація на доменних даних (які Offer = ЗВО+спеціальність моніторить контакт, NMT-профіль, дедлайни зі Strapi). Рівень персоналізації — L2 (AI per-segment copy) + L3 (per-contact для high-value тригерів).

Проблема: це EdTech, що радить реальним абітурієнтам. Невірний факт (помилковий дедлайн, прохідний бал, ціна) дезінформує користувача і вбиває довіру до бренду. LLM статистично схильні вигадувати числа й дати.

Рішення

Межа між тим, що генерує модель, і тим, що підставляється детерміновано:

• AI генерує лише обгортку: тон, кут під lifecycle stage × intent, релевантне обрамлення, формулювання CTA.
• Усі hard-факти — детерміновані merge-поля, отримані в момент рендеру з abitly (offers контакта, NMT-профіль, статус) і Strapi (дедлайни, дні відкритих дверей, прохідні бали, ціни). Модель отримує їх як structured input і інструктована використовувати лише їх.
• Fact-merge boundary + валідатор: post-generation guard повертає на регенерацію будь-яку копію, що вводить число, дату чи назву ЗВО/спеціальності, якої немає у вхідному structured input. Факт ніколи не «пишеться» моделлю — лише підставляється у слот.
• L3 high-value тригери використовують попередньо схвалені шаблони з grounded-слотами, не вільну генерацію на льоту.

Наслідки

• (+) Неможливо відправити галюцинований дедлайн/бал — бренд-безпека для EdTech.
• (+) Дешевше й передбачуваніше за вільний RAG; простіше QA й людська ревізія ([D8 — approval queue]).
• (−) Менша «креативність» у фактичній частині — свідомий компроміс заради безпеки.
• (−) Треба підтримувати контракт structured-input (які факти доступні моделі) + валідатор.
• Анти-патерн, якого уникаємо: дати моделі вільний доступ до БД/RAG і дозволити формулювати факти самій — повертає ризик галюцинацій. Саме це майбутній інженер може наївно «покращити»; цей ADR — стоп-сигнал.