Недавно позвали меня на аудит одного MedTech-продукта. Позиционировали его громко: «ИИ-платформа нового поколения для практикующих специалистов». Собственники с горящими глазами рассказывали, что под капотом у них взрослая open-source модель на 32 миллиарда параметров. Бизнес-план обещал миллионные B2B-контракты от фармгигантов.
ДИСКЛЕЙМЕР | Детали изменены, кейс собирательный. Все совпадения с реальными проектами — случайны.
Я получил гостевой доступ, заварил чай, включил режим технического скептика. Сделал два тривиальных клика. И знаете что? Болид оказался ржавой «копейкой» с прикрученным спойлером. Вместо прорывного ИИ — плохо собранный индексный поисковик уровня начала 2010-х.
Сразу оговорюсь: размер модели здесь ни при чём. 32B — это про генерацию. Проблема была в retrieval-слое, который до этой генерации просто не доносил ничего осмысленного. Модель есть, а кормить её нечем.
1. RAG-контур: модель есть, а контекста нет
Прикрутили они RAG (Retrieval-Augmented Generation). База знаний — сканы академических учебников, сотни PDF. Вроде всё по учебнику. Но вместо того, чтобы использовать модель для синтеза ответа поверх найденного контекста, систему зажали жёсткими промптами в стиле «отвечай строго по тексту предоставленного PDF».
Понимаю, MedTech — это комплаенс, безопасность, никаких галлюцинаций. Сам работал в фарме, знаю, как это бывает. Проблема не в самом ограничении. Проблема в том, что это ограничение не подкреплено нормальной поисковой архитектурой: гибридным поиском, реранкингом, расширением запроса, работой с метаданными.
В итоге на любом сложном профессиональном запросе (первый по GINA, ну а второй по кофейным клизмам 🙂 ) — на стыке альтернативной медицины или нестандартного кейса — модель не получает релевантный контекст. Не потому что «не думает», а потому что retrieval не находит ничего за пределами точных совпадений. На выходе — беспомощное «В предоставленном контексте информация отсутствует». Для практикующего врача ценность такого интерфейса стремится к нулю. Это не ИИ, это Ctrl+F с LLM-обёрткой.
2. UI/UX: костыли, вываленные на пользователя
Первое, что бросилось в глаза в интерфейсе — ручные конфигураторы поиска. Выпадающие списки конкретных книг. Чекбоксы для переключения между «Текстовым» и «Смысловым» режимами. В 2026 году. Серьёзно?
Зачем они там? Причина банальна: полноценный семантический эмбеддинг-поиск по всей библиотеке одновременно вызывает лавинообразный рост задержек — ответ уходит за несколько секунд — и сжигает серверные бюджеты. Вместо оптимизации highload-архитектуры команда просто переложила задачу по ограничению контекста на конечного пользователя. Врач вынужден вручную разгружать слабые процессоры. Это как заставить водителя выходить и толкать машину, потому что движок не тянет.
Продукт должен сам решать, что искать, как ранжировать, что кэшировать. Иначе пользователь становится оператором костылей, а не получателем ценности.
3. B2B-монетизация: compliance против спонсорского слоя
Самый жёсткий баг лежал в плоскости P&L. Платформа пилилась под бюджеты фармы. Но фарма готова платить только за нативную, комплаентную интеграцию своих брендов в структуру назначений врача.
Текущий жёсткий RAG-контур оперирует исключительно абстрактными МНН из зашитых методичек. Динамически интегрировать спонсорский слой в такую архитектуру — не получается. Модель начнёт галлюцинировать и нарушит базовые промпты. Без сквозного рекламного API продукт остаётся чистым затратным R&D-проектом без понятных шансов на окупаемость.
Что можно было сделать иначе
-
Гибридный поиск: BM25 + векторные эмбеддинги, а не только точное совпадение по буквам.
-
Реранкинг: cross-encoder или LLM-реранкер для пересортировки top-k результатов.
-
Понимание запроса: расширение формулировки, синонимы, связка МНН и торговых названий, разговорные варианты.
-
Фильтрация по метаданным: специальность, уровень доказательности, тип источника.
-
Кэширование частых запросов и эмбеддингов.
-
Квантизация, батчинг, стриминг, асинхронная генерация — чтобы задержки и стоимость инференса не улетали в космос.
-
Офлайн-оценка качества: эталонный набор запросов, точность и полнота поиска, достоверность ответа относительно источников, задержка отклика, стоимость инференса
-
MVP на меньшей модели, замер качества, и только потом масштабирование
Мораль для бизнеса
Если вы нанимаете на позицию ИТ-лидеров линейных исполнителей, которые умеют только двигать карточки в Jira и запускать готовые библиотеки по гайдам из YouTube, — вы получите дорогую индексную машину, которая начнёт разваливаться при первых же сотнях реальных пользовательских запросов.
Крупной языковой модели мало скормить ваши терабайты данных. Продукту нужен архитектор и Product Owner со стратегическим видением. Который понимает и хардкорную оптимизацию серверных мощностей, и циничную B2B-психологию монетизации, и ограничения комплаенса.
Иначе ваш ИИ так и останется кнопочным телефоном со встроенным Т9. Сколько бы миллиардов параметров в него ни залили.