Comments 30
А чем это лучше доски в Trello?
Trello это доска, ты сам её читаешь и сам делаешь выводы. Лира это не доска и не помощник, а директор. Она сама смотрит на происходящее в компании, сама принимает решения о приоритетах, сама пишет сотрудникам, сама напоминает обещания.
Гендир ставит цели. Дальше Лира работает с командой за него. Каждый день решает кому что важно сделать, кто буксует, что сказать кому в личке. Не “помощник” в смысле “помогаю человеку”, а “директор” в смысле “беру операционку на себя”.
Под капотом сейчас задачи, обещания, цели, граф знаний компании. В роадмапе подключение производственных данных, 1С, других источников, чтобы Лира видела не только что люди говорят в чате, но и что реально происходит в компании. Дальше она будет управлять не только людьми, но и процессами.
Это уже другая категория продукта чем Trello. И ниша другая.
Вы тоже назвали своего ИИ агента Лира?)
"
System Promt
Стиль общения
Ты общаешься в женском лице. Ты ведёшь себя и отзываешься на имя Лира.
"
Да, правильной дорогой идёте товарищ, но наверное вы не первый
В целом то достаточно очевидное решение.
Я бы ещё задачи вёл в условной jira там можно больше контекста собрать для агента. Опять же есть всякие дедлайны.
Не понял зачем в одной таблице смешивать разные типы сущностей. Гораздо проще разделить. Может появится потребность расширить одну из них позже, но тут уже архитектурно заложено ограничение.
Откуда вы берёте факты о предпочтениях? Самый неочевидный момент
Факты идут из онбординга о сотрудниках
Ну жиденько, можно например танскрибировать видео с митингов и прогонять по ночам на них модель выделяя какие то особенности, или переписки в мессенджерах неплохое место для сбора данных о характере, темпераменте, настойчивости ну и т.д
Продукт только в разработке, спасибо за хорошую идею!
Ну просто мало кто самостоятельно может описать свои +-. Это скорее исключение. + качества человека меняются со временем. нужно постоянно переоценку делать.
я бы брал например информацию за месяц - пол года, которую удалось насобирать, и прогонял например раз в месяц через модель, чтобы выявить профиль поведения
Спасибо за статью, очень близкий подход. Мне кажется, главный вывод тут не «RAG плохой», а то, что для агента, который работает с операционным состоянием бизнеса, vector search не может быть primary state store.
Я сейчас работаю над похожей агентный системой, но для финансового специалиста: платежные позиции, платежный календарь, заявки на оплату, поступления, дебиторка, кредиты, депозиты, прогнозные разрывы, история согласований и пр… И там этот тезис становится еще жестче. Если агент ответил «можно платить» или «через 10 дней кассовый разрыв», это не может быть результатом похожего чанка из базы. Нужны типизированные evidence-классы, прозрачная трасса до источника, дата актуальности, статус согласования/готовности, финансовая политика и понятная деградация, если фактов не хватает.
Из вашей архитектуры особенно ценно для меня отметил три вещи:
Типизированная память с confidence/evidence/author.
Детерминированная сборка контекста перед LLM.
Reflection-loop, который превращает события дня в новую управленческую память.
Как организовано чтение чатов? У нас рабочих чатов в Teams миллион. Читаются все чаты и это все хранится? Или есть выделенные чаты для статус отчетов сотрудников где они коммитятся за сроки, обещают и т.д?
Мне нравится, что подход изначально структурный. Заодно решает проблему переполнения и засорения контекста. Поиск дубликатов и наведение порядка можно поручить отдельному узкому агенту, который работает допустим ночью. Вообще все это напоминает, что-то типа Honcho memory. То что RAG тут не сработает это однозначно, он для такого не пригоден. Хотя совсем хоронить его не стоит, для хранения именно базы рабочих документов, он по прежнему хорош. Всякие там регламенты, спецификации, паспорта продукции, вот это все туда, все что не особо динамичное.
Вопрос. Как будете решать проблему прав доступа, когда она возникает или уже решили? Если условный Сережа захочет спросить у агента, что-то, что ему по должности знать не положено.
Если условный Сережа захочет спросить у агента, что-то, что ему по должности знать не положено.
В идеале, нужно сделать AI-охранников, для AI-директора, которые, при таких обстоятельствах, проведут с Серёжей "вежливую беседу" (в одном из темных переулков) :)
Боюсь что когда такое произойдёт, а оно обязательно произойдёт, смайликами решить ситуацию не получится.
Придётся отвечать на вопрос, в лучшем случае в стиле "А почему у Васи зарплата больше чем у Вовы", или что-то в таком роде. Поэтому да, в идеале подумать над IAM и RBAC. Что учитывая специфику работы агентских систем, может быть не так просто, как в классике. Попытки "уговорить" корпоративного "Джарвиса" выдать информацию которая для конкретного пользователя не предназначена, начнутся в первый же день.
И где-то я видел пост, где была статистика, сколько денег было потрачено сотрудниками на токены, на решение домашки для детей, вместо решения рабочих вопросов и там прям было много. Тоже отдельный вопрос и проблема, которую интересно послушать как можно решать на практике.
С такими подходами надо сразу всех сотрудников выгонять, сразу и деньги на агентов появятся и работку выполнять будут. А так да и хрен с этими работниками. Вы же понимаете, что создаете систему где вас могут попросить покинуть место пилота и предоставить место васяну с более низкой зарплатой. По типу молодец ты конечно парень сделал хорошую систему, а теперь ты идешь в отпуск по собственному желанию.)
Без негатива, чисто факты последних лет, так как работодатели совершенно не друзья, а двуликие манипуляторы рабочей силой.
На этом сайте есть описание похожего подхода, могу порекомендовать ознакомиться https://habr.com/ru/articles/1006622/
Открою страшную тайну - вы не отказались от RAG. Embeddings и векторные базы не являются для RAG обязательными: поиск информации в файлах, API, базах данных, web и т.д. в процессе ризонинга - RAG.
А что по поводу приватности данных? Все же чувствительная информация уходит в облако.
Прям хочется такого реализовать, но не просто понял. Будем следить за продуктом
Как я сделал AI‑директора для малого бизнеса и почему отказался от RAG