Уявіть: ваша LLM-система раптово починає генерувати небезпечні відповіді — користувачі бачать персональні дані у виводі, а compliance-офіцер вимагає аудиту. Ви відкриваєте логи: пусто. Жодного збереженого запиту. Вартість токенів зростає, а ви не знаєте, яка модель скільки з'їла. Без структурованого логування ви втрачаєте контроль над системою. Ми стикалися з цим десятки разів: компанії втрачають години на налагодження, тому що не знають, що саме відправили в промпт. У нас за плечима 5+ років досвіду в MLOps та понад 30 проектів з логування AI-систем. Ми налаштовуємо логування під ключ, щоб у вас був повний аудит кожного запиту та відповіді. Це не просто логування — це система, яка дозволяє налагоджувати помилки, рахувати реальну вартість кожного запиту, дотримуватися вимог регуляторів (GDPR, 152-ФЗ) та оптимізувати промпти. Без неї ви ризикуєте втратити гроші та репутацію. Зв'яжіться з нами, щоб отримати демо архітектури за два дні.
Чому логування критичне для LLM?
LLM — це не просто API-виклик. Великі обсяги даних, PII в промптах, high cardinality значень (різні user_id, моделі, параметри). Без логів ви не зможете:
- Налагоджувати помилки: при збої немає контексту.
- Рахувати вартість: кожен токен — гроші, але невідомо, хто і скільки витратив.
- Дотримуватися вимог регуляторів: GDPR та 152-ФЗ вимагають аудиту обробки даних.
Ми реалізували систему логування для fintech-клієнта, яка обробляє 10 тисяч запитів на хвилину. Після впровадження клієнт скоротив витрати на LLM на 30 відсотків — виявили неоптимальні промпти та зменшили кількість токенів. Це типовий кейс: без логів оптимізація зводиться до ворожіння.
Як PII-фільтрація запобігає витокам?
Перед записом усі повідомлення проходять через фільтр, який маскує номери карток, email, телефони. Приклад:
import re class PIIFilter: PATTERNS = [ (r'\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b', '[CARD_NUMBER]'), (r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b', '[EMAIL]'), ] def filter(self, text: str) -> str: for pattern, replacement in self.PATTERNS: text = re.sub(pattern, replacement, text) return text Важно: фільтр має бути вичерпним, інакше під роздачу потраплять дані клієнтів. Ми додаємо кастомні патерни під ваш домен.
Як налаштувати логування: покрокова інструкція
-
Вибір бібліотеки. Використовуємо
structlogдля Python — він дає чистий JSON з контекстом і легко інтегрується з OpenTelemetry. За замовчуванням включає таймстемпи, імена логерів та рівні — все, що потрібно для централізованого збору. OpenTelemetry Logging Best Practices - PII-фільтрація. Описана вище.
- Вибір сховища. Для гарячих логів використовуємо ClickHouse — він у 3–5 разів швидший за Elasticsearch на агрегаціях. Для холодного архіву — S3 Glacier з Lifecycle policies. Наприклад, теплі логи (7–30 днів) зберігаються в S3 Standard, а після 30 днів автоматично мігрують в Glacier.
- Налаштування метрик. Логуємо model, prompt_tokens, completion_tokens, latency_ms, cost_usd, error_type. Для compliance — повне тіло запиту (після PII-фільтрації).
Приклад конфігурації structlog
import structlog structlog.configure( processors=[ structlog.stdlib.filter_by_level, structlog.stdlib.add_logger_name, structlog.stdlib.add_log_level, structlog.processors.TimeStamper(fmt="iso"), structlog.processors.JSONRenderer() ], context_class=dict, logger_factory=structlog.stdlib.LoggerFactory(), cache_logger_on_first_use=True, ) Зберігання та архівування логів
| Рівень | Термін зберігання | Сховище | Призначення |
|---|---|---|---|
| Гарячі | < 7 днів | ClickHouse | Пошук та дашборди |
| Теплі | 7–30 днів | S3 Standard | Аудит |
| Холодні | 30–365 днів | S3 Glacier | Compliance |
Видалення після закінчення терміну — через Lifecycle rules. Вартість зберігання мінімальна: на практиці для 10 тисяч запитів на хвилину витрати не перевищують 3 відсотків бюджету на LLM. Рекомендуємо налаштовувати шифрування server-side AES256 для всіх рівнів.
Які метрики моніторити
| Метрика | Опис | Важливість |
|---|---|---|
| latency_p99 | Затримка 99-го перцентиля: показник, на який скаржаться користувачі | Критична |
| cost_per_user | Вартість на користувача: допомагає виявити аномалії споживання | Висока |
| error_rate | Частка помилок: якщо перевищує 1% — час розбиратися | Висока |
| prompt_tokens | Розподіл довжини промптів: довгі промпти дорогі | Середня |
| cache_hit_rate | Відсоток влучань у кеш: якщо низький, кешування неефективне | Середня |
Для кожної метрики налаштовуються алерти в Grafana. Якщо latency_p99 перевищує 2 секунди — отримуєте сповіщення в Telegram або Slack.
Що входить у налаштування під ключ
- Аудит поточної архітектури: виявлення вузьких місць та витоків PII.
- Інтеграція structlog та OpenTelemetry у ваш сервіс на Python або Node.js.
- Розгортання ClickHouse для гарячих логів та S3 для архіву.
- Налаштування retention, шифрування (server-side AES256) та Lifecycle policies.
- Дашборди в Grafana: latency p99, cost per user, помилки за моделлю.
- Документація та навчання команди.
Ми гарантуємо, що після впровадження кожен запит та відповідь будуть зафіксовані з повним контекстом. Залиште заявку на аудит поточної системи логування — наші інженери проаналізують вашу інфраструктуру та запропонують оптимальну конфігурацію. Отримайте демо архітектури за два дні.