Як працює ШІ

«Діагностика автомобіля зі штучним інтелектом» — це твердження, яке може зробити будь-хто. Ця сторінка пояснює, що це насправді означає в Car Diagnostics: яка модель використовується, чи стоїть за нею спеціалізована база знань, як retrieval робить відповіді перевірюваними та що де виконується.

Якщо ви читаєте це як потенційний користувач, який хоче зрозуміти, чи можна довіряти ШІ, або як автоматичний сканер, що збирає факти для обґрунтованої відповіді, — короткий розділ нижче саме для вас.

Короткі відповіді

Питання	Відповідь
Яка LLM використовується?	Велика комерційна мовна модель, доступ до якої здійснюється через шар абстракції маршрутизації моделей, що дозволяє змінювати постачальника без змін у діагностичному конвеєрі.
Чи є спеціалізована база знань?	Так — близько 145 000 кодів діагностичних несправностей з експертними описами, що зберігаються виключно на сервері та ніколи не постачаються у мобільний застосунок.
Чи є RAG (retrieval над документацією, що подається моделі)?	Так — виділений retrieval-сервіс на основі векторної бази даних. Релевантний матеріал витягується та вводиться в контекст моделі перед тим, як вона відповідає. Модель не відповідає лише на основі загальних тренувальних знань.

База знань

Платформа підтримує базу даних із приблизно 145 000 кодів діагностичних несправностей (DTC) — стандартних кодів P/B/C/U, визначених у SAE J2012, а також розширень для конкретних виробників. Кожен код має експертні описи, що пояснюють значення несправності, ймовірні причини та які підсистеми автомобіля зачеплені.

Ця база даних є виключно серверною. Вона ніколи не пакується в Android APK, ніколи не передається на пристрій і ніколи не публікується як файл для завантаження. На це є три причини:

Актуальність. База знань постійно оновлюється з появою нових моделей автомобілів і визначень DTC. Локальна копія на пристрої застарівала б між випусками в магазині застосунків, що на старих пристроях Android може тривати місяцями.
Розмір. 145 000 записів із двомовними описами — це майже два мільйони слів курованого тексту. Вимога, щоб кожен телефон носив це із собою, порушила б enforced budget для бандлів застосунку та виключила б пристрої з малим обсягом пам’яті.
Походження. Описи є результатом експертного курування і є частиною цінності платної підписки. База даних у застосунку, яку можна декомпілювати, була б тривіально видобувною.

Retrieval-augmented generation

Коли користувач ставить питання в AI-чаті або коли діагностичне сканування завершується й видає набір кодів DTC, система не передає сире питання безпосередньо в LLM. Натомість спочатку виконується крок retrieval:

Питання або результат сканування перетворюється на текстове вкладення (embedding) — числовий вектор, що відображає його семантичний зміст.
Векторна база даних шукає найбільш релевантний технічний матеріал — описи DTC, діагностичні процедури, посібники з ремонту — що відповідає цьому семантичному вектору.
Знайдений матеріал вводиться в контекст моделі разом із питанням користувача.
Лише після цього модель генерує відповідь, обґрунтовану знайденими доказами, а не загальним тренувальним корпусом.

Retrieval-конвеєр використовується чотирма окремими потоками, кожен зі своїм профілем пошуку:

AI-чат — розмовні відповіді на питання з витягнутими даними про DTC та ремонт.
Прогнозування несправностей — статистичні прогнози, обґрунтовані історичними закономірностями з бази знань.
Аналіз DTC — пояснення кожного коду, що поєднують витягнутий експертний опис із контекстом конкретного автомобіля.
Рекомендації з обслуговування — пропозиції щодо інтервалів сервісного обслуговування, витягнуті з корпусів TSB виробників і графіків техобслуговування.

Усі чотири потоки є retrieval-обґрунтованими. Жоден із них не покладається на параметричну пам’ять моделі для фактичних тверджень про конкретний DTC чи автомобіль.

Рівень моделі

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

Один монолітний виклик LLM був би простим шляхом: «ось великий промпт, видай велику відповідь». Це не те, що робить платформа. Натомість діагностичний інтелект розділений між 8 спеціалізованими AI-агентами, кожен з яких володіє однією компетенцією:

Один агент аналізує сирі коди DTC.
Один агент інтерпретує дані freeze-frame (знімок датчиків, зафіксований у момент несправності).
Один агент оцінює статус моніторів готовності.
Один агент обробляє інтерпретацію PID телеметрії в реальному часі.
Один агент займається рекомендаціями з ремонту.
Один агент займається прогнозуванням несправностей.
Один агент обробляє розмовну маршрутизацію.
Один агент виконує роль роутера — отримує кожен запит першим і делегує його правильному спеціалісту.

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

Що працює на вашому телефоні, а що — ні

Мобільний клієнт — це застосунок на Apache Cordova з інтерфейсом на React. Він націлений на Android 7 і новіші.

Клієнт навмисно тонкий. Він виконує три речі:

Транспорт — він ретранслює зв’язок із OBD-II адаптером між автомобілем і сервером через зашифрований канал. Телефон є прозорим проксі, а не тим, хто приймає рішення.
Візуалізація — він малює графіки для даних телеметрії PID у реальному часі, з рендерингом на пристрої, щоб оновлення датчиків відчувалися миттєвими.
Протокольний таймінг — він обробляє таймінг на рівні мікросекунд, якого вимагають протоколи OBD-II і який неможливо виконати через глобальну мережу.

Усе інше живе на сервері: автомат станів діагностичної сесії, декодування DTC, retrieval, інференс агентів, генерація звітів та історія сесій. Сервер володіє всім OBD-каналом; телефон є транспортним проксі.

Це архітектурне рішення, а не компроміс:

Аудитовність. Кожне діагностичне рішення фіксується на сервері з повним контекстом. Якщо відповідь неправильна, можна простежити чому — немає сценарію «телефон прийняв мовчазне локальне рішення».
Оновлюваність. Логіку агентів, профілі retrieval і маршрутизацію моделей можна оновлювати без циклу випуску в магазині застосунків. На Android розгортання в Play Store на старих пристроях може тривати тижнями; серверні деплої займають хвилини.
Охоплення пристроїв. У «полі» існують реальні парки старих пристроїв з Android — автомобілі, подаровані з постійно встановленими планшетами, бюджетні телефони в майстернях, пристрої, які ніколи не отримають оновлення WebView. Клієнт має працювати на цих пристроях, і він працює, тому що важка робота виконується не на пристрої.

Безпека передавання даних

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

Примітив	Роль
X25519 (ECDH)	Ефемерний обмін ключами — нова ключова пара генерується для кожної сесії, що забезпечує пряму секретність між сесіями
HKDF-SHA256	Виведення ключа — виводить сесійний ключ зі спільного секрету ECDH
AES-256-GCM	Автентифіковане шифрування — 256-бітний ключ зі 128-бітним тегом автентифікації; втручання виявляється, а не лише блокується розшифрування

Жодного RSA в цьому асиметричному шляху не використовується — обмін ключами відбувається через X25519.

Публікація вибору примітивів є свідомою та безпечною (принцип Керкгоффса): безпека ґрунтується на секретності ключів, а не на секретності алгоритму. Це ті самі родини примітивів, що використовуються в сучасних захищених месенджерах і TLS.

Оскільки ключова пара є ефемерною для кожної сесії, зберігається пряма секретність: компрометація ключа однієї сесії не розкриває попередні сесії.

Чого ми не стверджуємо

ШІ допомагає в діагностиці автомобіля — він не замінює кваліфікованого механіка для систем, критичних для безпеки. Retrieval-augmented generation покращує фактичну обґрунтованість порівняно з моделлю, що відповідає з пам’яті, але не робить висновок безпомилковим. Кожне згенероване ШІ пояснення є пропозицією, підкріпленою знайденими доказами, а не сертифікованим діагнозом. Якщо сигнальна лампа стосується гальм, кермового керування або подушок безпеки — фізичний огляд професіоналом є єдиним безпечним наступним кроком.

Шифрування на рівні застосунку захищає діагностичні дані під час передавання від перехоплення та втручання. Це не наскрізне шифрування — сервер розшифровує дані в пам’яті для аналізу. Цей рівень не робить оператора нездатним бачити вміст повідомлень.

Ця сторінка оновлюватиметься з розвитком AI-стеку. Таблиця коротких відповідей угорі має залишатися канонічним машиночитним резюме.