Про наши корпоративные AI-помощники я уже немного писал раньше — например, здесь. А сейчас хочу рассказать про одну конкретную архитектурную головоломку, с которой мы столкнулись в помощнике по обучению и развитию.
Он должен работать с довольно большим контекстом: понимать, какое обучение у человека назначено и пройдено, какие есть компетенции и разрывы, учитывать результаты 360, а если пишет руководитель — ещё и помогать ему разбираться в ситуации по команде.
И здесь появилась интересная для меня задача.
У нас не самая сильная модель. Самый очевидный вариант — просто взять модель умнее, но в корпоративной инфраструктуре всегда есть ограничения по доступности, скорости и другим параметрам.
А мне вообще нравится решать такие головоломки: если модель слабая, как задизайнить всё вокруг неё так, чтобы ей было как можно сложнее ошибиться? Чтобы даже если она где-то споткнулась или не до конца разобралась в данных, система всё равно достаточно надёжно вела её к нужному результату.
Мы постепенно пришли к архитектуре, которую внутри называем «экзоскелетом».
Вместо того чтобы отдавать модели большой массив данных и просить самой во всём разобраться, мы выносим часть работы наружу. Отдельные инструменты заранее собирают и фильтруют данные, определяют просрочки, разрывы по компетенциям и другие важные сигналы.
То есть модель получает уже не сотню строк, из которых ей самой надо понять, что важно, а подготовленный контекст: вот здесь проблема, здесь всё нормально, вот на это стоит обратить внимание.
Получается, что мы не пытаемся сделать саму модель умнее. Мы стараемся сделать умнее конструкцию вокруг неё и уменьшить количество мест, где она вообще может принять неправильное решение.
Для меня в этом сейчас и есть отдельный инженерный интерес AI-продуктов. Не только выбрать лучшую модель или написать хороший промпт, а понять ограничения модели и спроектировать систему так, чтобы она устойчиво работала вместе с ними.
@AlexGetsHrDone
Он должен работать с довольно большим контекстом: понимать, какое обучение у человека назначено и пройдено, какие есть компетенции и разрывы, учитывать результаты 360, а если пишет руководитель — ещё и помогать ему разбираться в ситуации по команде.
И здесь появилась интересная для меня задача.
У нас не самая сильная модель. Самый очевидный вариант — просто взять модель умнее, но в корпоративной инфраструктуре всегда есть ограничения по доступности, скорости и другим параметрам.
А мне вообще нравится решать такие головоломки: если модель слабая, как задизайнить всё вокруг неё так, чтобы ей было как можно сложнее ошибиться? Чтобы даже если она где-то споткнулась или не до конца разобралась в данных, система всё равно достаточно надёжно вела её к нужному результату.
Мы постепенно пришли к архитектуре, которую внутри называем «экзоскелетом».
Вместо того чтобы отдавать модели большой массив данных и просить самой во всём разобраться, мы выносим часть работы наружу. Отдельные инструменты заранее собирают и фильтруют данные, определяют просрочки, разрывы по компетенциям и другие важные сигналы.
То есть модель получает уже не сотню строк, из которых ей самой надо понять, что важно, а подготовленный контекст: вот здесь проблема, здесь всё нормально, вот на это стоит обратить внимание.
Получается, что мы не пытаемся сделать саму модель умнее. Мы стараемся сделать умнее конструкцию вокруг неё и уменьшить количество мест, где она вообще может принять неправильное решение.
Для меня в этом сейчас и есть отдельный инженерный интерес AI-продуктов. Не только выбрать лучшую модель или написать хороший промпт, а понять ограничения модели и спроектировать систему так, чтобы она устойчиво работала вместе с ними.
@AlexGetsHrDone