AI Symptom Checker для мобильного приложения: разработка под ключ

Ошибка в Symptom Checker может стоить жизни. Когда 30% существующих приложений для оценки симптомов дают неверные рекомендации по экстренным случаям, цена ошибки — человеческая жизнь. Избежать этого помогает детерминированный фильтр экстренных симптомов, который работает до любого AI-анализа. Ниже — архитектура, которую мы используем в коммерческих проектах, с соблюдением стандартов HIPAA и GDPR. Если вам нужно надежное медицинское приложение, свяжитесь с нами для консультации.

Почему детерминированный фильтр критичен?

AI-модели могут ошибаться, особенно на граничных случаях. Детерминированный фильтр — надежная гарантия: если пользователь вводит «боль в груди», приложение обязано показать кнопку вызова скорой, не дожидаясь ответа от LLM. Это не AI — это простое сравнение строк, которое работает быстро и точно. Мы используем список из 30+ фраз на нескольких языках, протестированных медицинскими экспертами.

Какие юридические и медицинские ограничения нужно учитывать?

Прежде чем писать код — базовые ограничения, которые диктуют архитектуру:

• Приложение не ставит диагнозы. Выводит «вероятные причины», «рекомендуется консультация врача»
• Симптомы высокого риска (боль в груди, затруднённое дыхание, признаки инсульта) — автоматический редирект на звонок 112, без AI-анализа
• Все данные о симптомах — медицинские данные, требуют шифрования уровня HealthKit / HIPAA
• Disclaimer должен быть виден до первого запроса, не мелким шрифтом

На iOS — HealthKit для хранения анамнеза с HKHealthStore authorization. На Android — Health Connect с HealthPermission.READ_STEPS и аналогичными разрешениями.

Детерминированная проверка критических симптомов

До любого LLM-вызова — жесткий фильтр по критическим симптомам:

struct CriticalSymptomChecker {
    // Симптомы, требующие немедленной скорой помощи
    static let emergencySymptoms = [
        "chest pain", "боль в груди",
        "difficulty breathing", "затруднение дыхания", "не могу дышать",
        "sudden severe headache", "внезапная сильная головная боль",
        "face drooping", "numbness arm", "speech difficulty",  // FAST-тест инсульта
        "loss of consciousness", "потеря сознания",
        "severe bleeding", "сильное кровотечение",
        "choking", "подавился"
    ]

    static func requiresEmergency(_ symptomText: String) -> Bool {
        let lowercased = symptomText.lowercased()
        return emergencySymptoms.contains { lowercased.contains($0) }
    }
}

// Проверяем ДО отправки в LLM
func processSymptoms(_ userInput: String) async {
    if CriticalSymptomChecker.requiresEmergency(userInput) {
        showEmergencyAlert()  // Кнопка 112, заблокировать продолжение
        return
    }
    await analyzeWithAI(userInput)
}

Это не AI — это детерминированная логика. Нельзя доверять LLM решение о вызове скорой помощи.

Структурированный сбор симптомов

Свободный ввод текста — не лучший UX для медицинского контекста. Пользователь в стрессе пишет неточно. Лучше — чат с уточняющими вопросами по протоколу OPQRST:

// Протокол сбора симптомов (адаптация OPQRST для мобильного)
enum SymptomQuestion: CaseIterable {
    case onset          // когда началось
    case provocation    // что усиливает/ослабляет
    case quality        // характер (острая, тупая, давящая)
    case radiation      // куда отдаёт
    case severity       // 1-10 шкала
    case time           // как давно, постоянно/периодически

    var prompt: String {
        switch self {
        case .onset: return "Когда появился симптом? (недавно, несколько часов, несколько дней)"
        case .severity: return "Оцените интенсивность по шкале от 1 до 10"
        // ...
        }
    }
}

AI генерирует следующий уточняющий вопрос на основе предыдущих ответов — адаптивный опрос, а не фиксированный список.

Промпт для анализа симптомов

func buildSymptomAnalysisPrompt(
    symptoms: SymptomCollection,
    patientContext: PatientContext
) -> String {
    return """
    You are a medical triage assistant. Analyze symptoms and suggest possible conditions.

    IMPORTANT: Always recommend consulting a qualified doctor. Never provide a definitive diagnosis.
    If symptoms suggest any serious condition, clearly state urgency level.

    Patient context:
    - Age: \(patientContext.age)
    - Known conditions: \(patientContext.knownConditions.joined(separator: ", "))
    - Current medications: \(patientContext.medications.isEmpty ? "none" : patientContext.medications.joined(separator: ", "))

    Symptoms:
    - Main complaint: \(symptoms.mainComplaint)
    - Duration: \(symptoms.duration)
    - Severity (1-10): \(symptoms.severity)
    - Character: \(symptoms.quality)
    - Associated symptoms: \(symptoms.associated.joined(separator: ", "))

    Return JSON:
    {
      "urgency": "emergency|urgent|routine",
      "possible_conditions": [{"name": "", "likelihood": "high|medium|low", "brief_explanation": ""}],
      "recommended_action": "call_112|er_today|see_doctor_soon|see_doctor_routine|home_care",
      "home_care_advice": "",
      "red_flags": ["symptoms to watch for that require immediate care"],
      "disclaimer": "This is not a medical diagnosis..."
    }
    """
}

urgency: emergency в ответе LLM — дополнительный триггер для показа кнопки 112, даже если детерминированный фильтр его не поймал.

Отображение результатов

Медицинская информация требует особой подачи в UI:

@Composable
fun SymptomCheckResult(result: SymptomAnalysis) {
    Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {

        // Уровень срочности — первым, крупно
        UrgencyBanner(urgency = result.urgency)

        Spacer(Modifier.height(16.dp))

        // Рекомендованное действие — вторым
        RecommendedActionCard(action = result.recommendedAction)

        Spacer(Modifier.height(16.dp))

        // Возможные причины — с оговорками
        Text("Возможные причины", style = MaterialTheme.typography.titleMedium)
        Text(
            "Информация носит ознакомительный характер и не является диагнозом",
            style = MaterialTheme.typography.bodySmall,
            color = MaterialTheme.colorScheme.onSurfaceVariant
        )

        result.possibleConditions.forEach { condition ->
            ConditionCard(condition)
        }

        // Красные флаги — отдельным блоком
        if (result.redFlags.isNotEmpty()) {
            RedFlagsSection(flags = result.redFlags)
        }

        // Disclaimer — обязателен, но не мелким шрифтом
        DisclaimerCard(text = result.disclaimer)
    }
}

Интеграция с телемедициной

Если приложение связано с телемедицинским сервисом, кнопка «Проконсультироваться с врачом» появляется в результатах. Контекст из Symptom Checker (структурированные симптомы, анамнез) передаётся врачу автоматически — это экономит 10–15 минут опроса.

Что входит в разработку AI Symptom Checker под ключ

Сравнение подходов: детерминированный vs AI для экстренных симптомов

Ориентиры по срокам

Базовый Symptom Checker с чатом, детерминированным фильтром экстренных случаев и AI-анализом — 2–3 недели. Полная реализация с адаптивным опросом, HealthKit/Health Connect, профилем пациента, интеграцией телемедицины и соответствием требованиям GDPR/HIPAA — 2–3 месяца.

Наши инженеры имеют сертификаты iOS/Android и многолетний опыт в разработке медицинских приложений. Мы гарантируем соблюдение всех регуляторных требований и проведем аудит безопасности перед релизом. Получите консультацию по вашему проекту — свяжитесь с нами для оценки сроков и стоимости. Закажите разработку AI Symptom Checker под ключ — надежное медицинское решение с защитой данных.

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

Мы различаем два принципиально разных подхода: приложение с on-device AI и приложение, которое просто вызывает облачное API. Первое работает без интернета, не отправляет данные пользователя на сторонние серверы и отвечает за 50 миллисекунд. Второе зависит от задержки сети и тарифного плана. Выбор архитектуры — ключевой этап, который напрямую влияет на стоимость, приватность и пользовательский опыт. Наш опыт показывает: в 70% проектов on-device инференс оказывается дешевле в долгосрочной перспективе за счёт исключения серверных затрат.

Как выбрать между CoreML и TFLite для on-device инференса?

CoreML — нативный фреймворк Apple для запуска ML-моделей на устройстве. Поддерживает Neural Engine (начиная с A11 Bionic), GPU и CPU как fallback. Модели конвертируются в формат .mlmodel через coremltools из PyTorch, ONNX или TensorFlow. Конвертация — не всегда тривиальна: кастомные слои требуют реализации MLCustomLayer, а квантизация до INT8 иногда заметно роняет точность на специфических данных. Мы гарантируем, что итоговая модель проходит валидацию на реальных данных до и после конвертации.

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На Android использует NNAPI (Neural Networks API) для хардварного ускорения — с Android 10 NNAPI стабильнее, до этого лучше явно использовать GPU delegate через GpuDelegate. Типичная ошибка: модель обучена на нормализованных данных в диапазоне [0,1], а в приложении на вход подаётся [0,255] — инференс работает, но с бессмысленными результатами без ошибки. Мы включаем модуль автоматической валидации входных данных в SDK.

Для задач классификации изображений, детекции объектов и сегментации доступны готовые оптимизированные модели. YOLOv8 в CoreML формате запускает детекцию кадра 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite с GPU delegate — около 8 мс на Pixel 7 при классификации.

Что делать, если нужна генерация текста на устройстве?

Запуск небольших языковых моделей на устройстве стал реальностью в последние несколько лет. Apple Intelligence использует собственные модели через Private Cloud Compute, но для сторонних разработчиков доступны другие пути.

llama.cpp с Metal backend на iOS — работающий подход для phi-3-mini (3.8B параметров, 4-bit квантизация, ~2.3 ГБ). Инференс: 15–25 токенов/секунду на iPhone 15 Pro. Для интеграции в Swift используем Swift Package llama.swift или обёртку через C-интерфейс llama.h. Бинарник к приложению не прикладываем — модель скачивается при первом запуске и хранится в Application Support. Наши сертифицированные разработчики настраивают инкрементальную загрузку, чтобы не блокировать первый запуск.

На Android аналог — Google AI Edge (бывший MediaPipe LLM Inference API) с поддержкой Gemma-2B. Работает через GPU delegate, на Tensor G3 чипе Pixel 8 Pro — около 20 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция OpenAI API и других облачных моделей

Для сценариев, где cloud inference допустим, интеграция OpenAI, Anthropic или Google Gemini — это HTTP клиент + streaming SSE. В Swift удобно через AsyncThrowingStream для стриминговых ответов. В Kotlin — через Flow.

Критически важно: API-ключи никогда не хранятся в бандле приложения. Даже обфусцированный ключ извлекается из IPA за 10 минут через strings или frida. Правильная архитектура: мобильное приложение → собственный backend → OpenAI API. Backend контролирует rate limiting, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

• Обученная и квантизированная модель под целевое устройство (документация по метрикам)
• SDK для интеграции (Swift/Kotlin/Flutter) с примерами вызова
• Тесты производительности на 3–5 реальных устройствах
• Инструкция по обновлению модели OTA
• Поддержка при прохождении модерации App Store / Google Play (проверка соответствия Guidelines 4.2, 5.1)
• 2 недели технической поддержки после релиза

Типичный пайплайн проекта

1. Анализ задачи — замеряем latency, privacy, size, поддерживаемые устройства.
2. Прототипирование модели — в Python, оценка accuracy на целевых данных.
3. Конвертация и квантизация — под CoreML/TFLite с валидацией.
4. Интеграция в приложение — модель оборачивается в сервисный слой (легко подменять CoreML → TFLite → облако).
5. Тестирование — на реальных девайсах, замер FPS, RAM, батареи.
6. Деплой — через TestFlight / Firebase App Distribution, мониторинг метрик.

Сроки: интеграция готовой CoreML/TFLite модели — 1–2 недели, разработка кастомной модели с мобильной оптимизацией — от 6 недель, on-device LLM чат с персонализацией — 4–8 недель.

Почему мы беремся за сложные кейсы?

10+ лет опыта в мобильной разработке, 50+ внедрённых AI/ML решений, гарантия совместимости с актуальными версиями iOS и Android. Все проекты проходят code review и нагрузочное тестирование. В стоимость уже входит подготовка документации для модерации и обучение вашей команды.

Свяжитесь с нами — мы поможем выбрать архитектуру и внедрить ML в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).