Комментарии 12
Самый большой косяк, это из джанговского синхронного view делать http запросы к API OpenAI.
От Егора (хабр не опубликовал его комментарий):
"Спасибо большое за замечание. Добавили задачу, она будет является приоритетной (https://github.com/soshace/fosterflow/issues/23). Есть ли у вас еще замечания или пожелания?"
Ну вот если дальше продолжить размышления на эту тему, варианты решения:
1. Запросы уносим в фон, минус - городить дополнительный огород для всей этой обработки, по мне так себе решение.
2. В django практический рабочий async, используем его, минус - DRF не умеет async, писать самостоятельно кучу всего на замену DRF, тоже не очень хорошее. Но возможно уже есть какие-то сторонние решения, я эту тему сильно не исследовал.
3. Отказаться от django в пользу асинхронных фреймворков, тот же FastAPI, минус - переход на другой ORM, отсутствие удобной админки. Но эти минусы не такие уже и критичные.
Тут еще помянули вебсокеты, но так и django с ними не очень (channels мне вообще не зашли, какой-то оверхед по сравнению с удобствами в асинхронных фреймворках)
Думаю, что воспользуемся вторым методом. У Django есть на это документация, и я предполагаю, что можно будет что-то придумать.
https://docs.djangoproject.com/en/4.2/topics/async/
Спасибо большое за замечание. Добавили задачу, она будет является приоритетной (https://github.com/soshace/fosterflow/issues/23). Есть ли у вас еще замечания или пожелания?
В вашей архитектуре есть проблема в том, что запрос к API OpenAI делается прямо в обработке HTTP-запроса от фронтэнда. И если OpenAI будет долго отвечать, то может как успеть оборваться соединение с фронтэндом, так и обработчик запроса может быть прибит по таймауту. По уму надо подключать например Celery, запрос OpenAI делать в отдельной асинхронной таске, а фронтэнду сразу же вернуть статус, что запрос отправлен. И дальше фронтэнд через какое-то время должен сделать еще запрос чтобы забрать ответ от OpenAI и вывести его клиенту. Либо можно пойти еще дальше и подключить вэбсокеты, тогда сервер сам отправит ответ от OpenAI на фронтэнд, когда он придет.
А зачем в модели разделены user_app_user и user_app_profile?
Я так понимаю, в базе получатся 2 раздельные таблицы со связью 1:1 ?
Здравствуйте, Никита. Спасибо большое за материал. У меня только остался вопрос к самой идее. Объясните, пожалуйста. Правильно ли я понял, что ваша модель чата - она работает по той же платной модели от open AI где взимается оплата за токены? И чтобы обучить чат понимать как работает, к примеру, моя компания, то так же каждый раз я должен отсылать ему раз запрос с информацией о моей компании, чтобы он понимал ее и на основе этой информации мог дать ответ? Или ваша модель позволят работать с информацией и не отсылать каждый раз подсказку чату? То есть можно ли научить чат и обяснить ему все необходимые нюансы и только отправлять / получать ответы без доп инструкции, или нужно каждый раз необходимую информацию посылать иначе он не будет знать нюансов и специфики в работе моей компании?
Здравствуйте, в текущей реализации сделан пока только интерфейс к платной GPT модели от Open AI, чат не делает ничего более того, что делает СhatGPT.
В следующей версии я планирую добавить альтернативные LLM модели. Возможно, сделаем пример взаимодействия с API стороннего сервиса через модель GPT (о чем написано в самом начале статьи).
То, что вы описываете. Я вижу два варианта:
1. Передавать весь контекст с каждым запросом. Для этого можно выбрать модель с большим контекстным окном и прописать, чтобы весь контекст прикрплялся к каждому сообщению автоматически.
2. Использовать модель обученную на ваших данных.
То, о чем вы пишете, это интересная задача, я подумаю над тем как её можно было бы удобнее реализовать в проекте.
Добавил в идеи: https://github.com/soshace/fosterflow/issues/24
Спасибо за статью. Интересный и творческий взгляд на использование ChatGPT.
Пишем свой Chat GPT