Коли ШІ — не найкраще рішення: чому я обрав хеш-таблиці для автоматичного перемикання розкладок

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт!

Я розробляю невеликий macOS-застосунок, який автоматично перемикає розкладку клавіатури під час набору тексту, щоб користувачу не доводилося постійно робити це вручну.

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

Коли я починав цей проєкт, моя перша думка була очевидною.

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

Але після кількох експериментів я повністю відмовився від цієї ідеї.

Причин було кілька.

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

По-друге, я не хотів залежати від інтернет-з’єднання, зовнішніх API чи сторонніх сервісів.

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

Тому замість AI я побудував систему навколо великих словників і хеш-мап.

Насправді застосунку не потрібно «розуміти» мову так, як це робить LLM.

Йому потрібно відповісти лише на одне запитання:

Чи відповідають останні введені символи поточній розкладці клавіатури, чи користувач, імовірно, вже пише іншою мовою?

Наприклад, якщо користувач пише:

Я працюю на MacBook Pro вже кілька років.

Він не повинен натискати комбінацію клавіш лише для того, щоб написати MacBook Pro, а потім перемикатися назад.

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

Застосунок аналізує введений текст у реальному часі, перевіряє можливі варіанти в інших розкладках і визначає, чи настав момент автоматично змінити мову.

Для цього не потрібна генеративна модель.

Пошук у хеш-мапі виконується в середньому за O(1), тому перевірка відбувається практично миттєво. Один і той самий ввід завжди дає однаковий результат.

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

Цей підхід має кілька практичних переваг:

• жодних мережевих запитів;
• жодних витрат на AI-інференс;
• робота повністю офлайн;
• мінімальна затримка;
• детермінована поведінка;
• простіше тестування та налагодження.

Звісно, словників недостатньо.

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

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

Але навіть ця логіка залишається локальною, швидкою та повністю детермінованою.

Цей проєкт ще раз нагадав мені просту річ.

AI — надзвичайно потужний інструмент, але не кожна задача потребує AI.

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

У моєму випадку саме так і сталося.

Мені цікаво почути думку спільноти.

Чи траплялися вам задачі, де AI здавався очевидним вибором, але простіший алгоритм у підсумку виявився кращим?

P.S. Я не українець, тому писав цей допис англійською, а потім використав AI для перекладу та редагування української версії. Якщо помітите неточності або неприродні формулювання — буду вдячний за виправлення.

P.P.S. Якщо комусь цікаво побачити реалізацію на практиці — застосунок називається Unfumble: unfumble.app. Буду радий будь-якому фідбеку.