Я намагався додати AI-чат до свого додатка і вперся в стіну
Я намагався додати AI-чат-асистента до свого інструменту управління проєктами. Я хотів, щоб користувачі могли ставити запитання про прострочені завдання або нотатки з нарад. Це здавалося простим. Я думав, що просто викличу API і на цьому все. Я помилявся.
Після 15 повідомлень AI став повільним і незв'язним. API почав видавати помилки, тому що розмова стала занадто довгою. Я використовував GPT-4 з лімітом у 8k токенів. Кожне повідомлення містило довгі описи та нотатки. Історія зростала занадто швидко.
Я спробував три різні способи вирішення:
- Обрізання історії: я залишав лише кілька останніх повідомлень. Це допомогло зі швидкістю, але AI забував усе інше.
- Сумаризація: я просив AI підсумовувати чат кожні 5 повідомлень. Це допомогло з пам'яттю, але збільшило мої витрати та затримку.
- Оцінка релевантності: я намагався залишати лише найбільш релевантні повідомлення. Це потребувало векторного сховища та додавало занадто багато складності.
Я зрозумів, що мені потрібна краща стратегія. Я зупинився на двох методах: стрімінгу та фіксованому вікні контексту.
Стрімінг робить додаток швидким на відчуття. Користувачі бачать, як текст з'являється миттєво, замість того, щоб чекати на повну відповідь. Я використовував Server-Sent Events, щоб надсилати фрагменти тексту по мірі їх надходження.
Я також розділив свій контекст на три частини:
- System prompt: фіксований набір інструкцій.
- Dynamic context: нещодавні оновлення проєкту та стани завдань.
- Conversation history: ковзне вікно останніх повідомлень.
Я не надсилаю всю історію щоразу. Я надсилаю лише стільки, скільки потрібно для відповіді на поточне запитання. Це зменшило розмір мого payload на 40%. Це заощадило мені гроші та підвищило швидкість.
Якщо ви розробляєте AI-функції, пам'ятайте: Стрімінг дає вам швидкість. Хороша стратегія контексту дає вам інтелект.
Як ви керуєте пам'яттю розмови у своїх додатках? Ви використовуєте ковзні вікна чи сумаризацію?