Чому не варто утримувати підключення до БД під час викликів LLM
Затримка (latency) ШІ — це не лише час, який модель витрачає на «роздуми». Вона також залежить від того, як ви керуєте підключеннями до бази даних.
Утримання підключення до БД під час очікування відповіді від LLM або embedding API може вичерпати ваш пул підключень. Повільні зовнішні виклики тримають сесії відкритими набагато довше, ніж це необхідно.
Я заглибився в репозиторій Honcho, щоб розібратися з їхнім рішенням. Вони замінили одну тривалу сесію на короткі сесії, призначені для конкретних завдань.
Старий підхід
- Відкрити сесію БД
- Прочитати налаштування користувача
- Викликати LLM (повільно)
- Викликати Embedding API (повільно)
- Зберегти результати
- Закрити сесію БД
Новий підхід
- Відкрити сесію БД для попередніх перевірок
- Зчитати необхідні значення у змінні
- Закрити сесію БД
- Викликати LLM та Embedding API (підключення до БД не утримується)
- Відкрити нову коротку сесію БД для збереження результатів
- Закрити сесію БД
Мета не в тому, щоб відмовитися від бази даних, а в тому, щоб відокремити цілісність транзакцій від очікування мережевих відповідей.
П'ять кроків для керування підключеннями
- Визначте межі цілісності.
- Зчитайте всі необхідні значення у змінні перед будь-яким зовнішнім викликом API.
- Закрийте область видимості бази даних (database scope).
- Виконайте повільні зовнішні завдання.
- Відкрийте нову коротку область запису для збереження кінцевих результатів.
Примітка: Якщо ви використовуєте pgvector, пошук виконується всередині бази даних, тому під час цієї операції необхідно тримати сесію відкритою.
Скорочення часу життя сесії покращує масштабованість, але стежте за помилками detached-object у вашому ORM і переконайтеся, що дані залишаються цілісними в знімках (snapshots) транзакцій.
Джерело: https://dev.to/junhyun-dev/neurin-llm-hocul-jung-db-connectioneul-jabji-anhneun-iyu-3abg
Додаткова спільнота для навчання: https://t.me/GyaanSetuAi