Розробка AI-детектора депресії за текстом і мовленням

Детекція депресії AI: де втрачається точність

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

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

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

Окремо кожна ознака слабка й не відрізняється від утоми, тому модальності обробляють роздільно, а рішення об’єднують на останньому кроці, не змішуючи сирі сигнали.

Друге джерело помилок — розрізнені висновки фахівців: різні шкали, вільна форма запису, відсутність підпорогових випадків у розмітці.

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

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

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

Вимірюваний ефект: швидкість, охоплення, стабільність

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

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

Охоплення зростає з вибіркових 10–15% до всіх вхідних — текстових повідомлень і записів мовлення, включно з розшифруванням і ознаками голосу: темп, тривалість пауз, рівність інтонації.

Єдині критерії оцінки дають другий ефект. Розмітка ведеться за валідованою шкалою PHQ-9, правила зведено в один документ, спірні випадки описані прикладами.

Повторна розмітка однієї й тієї самої підбірки двома фахівцями збігається у 85–90% випадків, а розходження розбираються й переходять у правила.

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

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

Режими роботи детекції: пакетний і потоковий

Детекція спирається на той самий набір ознак — лексику, темп і паузи мовлення, зміну тональності впродовж розмови. Різниця між режимами не в моделі, а в тому, коли потрібен результат: розібрати накопичений матеріал чи підказати просто в момент діалогу. Тому режими не виключають один одного й часто вмикаються разом.

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

Плата за це — вузьке вікно огляду: рідкісні зміни стану й повільні зсуви за тривалий час потоковий режим може не вловити.

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

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

Як проходить впровадження: етапи інженерної роботи

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

1. Аудит даних і сценарію. Дивимося, які записи є — інтерв’ю, щоденникові тексти, дзвінки, — де зсув вибірки й які мітки реально отримати. На виході протокол розмітки та вимоги до якості запису.
2. Розмітка корпусу записів. Клінічні шкали переводимо в рівневі мітки; кожен фрагмент розмічають щонайменше двоє, розходження розбирає третій. Рахуємо узгодженість — за низької правимо інструкцію, а не усереднюємо спірні випадки.
3. Відкладена вибірка. Ділимо за людьми, а не за записами: інакше голос пацієнта потрапляє і в навчання, і в перевірку, а метрика на прийманні завищується. Відкладена частина не відкривається до фінальної перевірки.
4. Навчання й відбір ознак. Текст: тематика, синтаксис, заперечення. Мовлення: темп, паузи, інтонація. Залишаємо те, що справді додає роздільної здатності.
5. Калібрування порогів спрацювання. Ціна пропуску й хибного спрацювання різна, тому поріг добираємо під сценарій — скринінг чи моніторинг, — фіксуючи чутливість і специфічність та поведінку на пограничних випадках.
6. Приймання результату. Перевірка на відкладеній вибірці, розбір помилок за підгрупами, тест на шум і обрізані фрагменти. Метрики фіксуються письмово до доопрацювань.
7. Передача в експлуатацію. Схема підключення до каналу, журналювання рішень, правило ескалації фахівцю та регламент переперевірки на нових даних.

Точки контролю — після розмітки, відкладеної вибірки й приймання: якщо якість міток або розділення вибірок не підтверджується, робота зупиняється до усунення причин, а не маскується донавчанням.

Артефакти проєкту: моделі, правила розмітки, регламенти

Проєкт у галузі детекції депресії AI закінчується не демонстрацією, а комплектом, який живе всередині контуру замовника.

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

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

Кейс: як скоротили пропуски в первинній оцінці

Напрям — первинна оцінка звернень у сервісі психологічної допомоги: кілька сотень анкет і текстових повідомлень на тиждень, відбір вручну за скаргою та за шкалою PHQ-9.

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

Щоб метрики були чесними, замір робили на розміченій вибірці минулих звернень: два фахівці незалежно розмічали випадки, спірні знімав третій. До і після рахували на тих самих даних, без вибірки «зручних» прикладів.

Метрики до і після

Що дало результат

Працює каскад із двох етапів. Модель оцінює текст і мовлення — лексичні маркери, темп, паузи, зміни просодії — і видає оцінку ризику; рішення залишається за фахівцем, система не ставить діагноз, а визначає пріоритет черги.

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

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

Той самий контур ми переносимо на суміжні напрями — там достатньо замінити розмітку й перекалібрувати пороги.

Чим відрізняється аналіз тексту від аналізу мовлення

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

Розходження між ними саме собою інформативне: бадьорі формулювання за сповільненого рівного голосу — типова картина маскування.

аналіз тексту звернення працює з лексикою та структурою: частка заперечень і узагальнень, слова із семантикою безнадії, збіднення словника, зсув «я» в бік безособових конструкцій, розпад зв’язності між абзацами.

Ознаки стійкі до шуму, але залежать від мови, діалекту й від того, наскільки людина готова писати розлого.

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

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

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

спільна оцінка сигналів — єдина оцінка за двома наборами ознак, відкалібрована на валідованій шкалі PHQ-9: слабкий сигнал не тягне результат за собою, сильний його компенсує.

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

Сумніви щодо даних, приватності та впровадження

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

У нас мало записів — модель навчиться?

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

Чи зможе лікар зрозуміти, чому такий висновок?

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

Можна розгорнути на нашій інфраструктурі?

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

Що доведеться узгоджувати з юристами?

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

Обговоримо ваше завдання й повернемося з планом

Щоб повернутися з оцінкою завдання та складом робіт, нам потрібен зріз вашого процесу: які дані вже є, у якому вони вигляді й хто ухвалює рішення за результатами моделі.

Розбираємо це на першій розмові — без загальних питань, за конкретними пунктами, від яких залежить архітектура й термін пілоту.

• Модальності та джерела: працюємо тільки з текстом (звернення, листування, розшифрування) чи додаємо мовлення — тоді потрібні записи й розмітка подачі, темпу, пауз; окремо обговорюємо, що робити з шумом, діалектами й змішаним мовленням.
• Корпус і розмітка: скільки розмічених прикладів є зараз, хто розмічав — клініцист чи асесор, чи прив’язані мітки до валідованих шкал. Від цього залежить, стартуємо ми з донавчання чи з нуля.
• Критерії приймання: цільова повнота виявлення за заданої точності, окремо — частка пропущених тяжких станів, поріг спрацювання й формат відповіді моделі: бал, категорія чи прапорець для фахівця.
• Приватність і контур: де зберігаються дані, чи допустима зовнішня обробка, чи потрібен закритий контур на ваших серверах, як обмежується доступ до чутливих записів і скільки вони живуть.
• Точки інтеграції: звідки надходить потік, у якому вигляді потрібен результат, хто з фахівців його бачить і як повертається зворотний зв’язок для донавчання.
• Пілотний запуск: яку ділянку й обсяг даних беремо, на якому періоді перевіряємо, хто розбирає спірні випадки й як рахуємо розходження моделі з оцінкою людини.
• План впровадження: етапи від прототипу до робочого контуру, контроль дрейфу на нових даних, регламент перенавчання й перегляду порогів.

Модель тут — інструмент підтримки рішення, а не заміна фахівця: фінальну інтерпретацію залишаємо за людиною. Опишіть завдання у вільній формі — повернемося з оцінкою термінів, складом робіт і планом пілоту.