‹

Дорожная карта: Ollama ↔ PostgreSQL

Как подключить локальную Ollama к базе PostgreSQL так, чтобы ответы строились на фактах из задач/проектов.
Глоссарий терминов
Короткие определения, чтобы команда говорила на одном языке.
Views (витрины)
Упрощённые представления в PostgreSQL, где поля и связи сделаны удобными для аналитики и для LLM.
Curated data
Подготовленные данные: нормализованные статусы/даты/связи, без лишних и опасных полей.
Tools
Набор разрешённых функций/эндпоинтов, которые ходят в БД и возвращают JSON (вместо того, чтобы модель писала SQL сама).
Allowlist
Белый список разрешённых операций и параметров. Всё остальное запрещено.
RAG
Подстановка в контекст правил/терминов/регламентов из базы знаний. Оперативные цифры берутся из БД через tools.
RBAC
Права доступа: модель видит только те проекты/задачи, которые разрешены пользователю по сессии.
Eval (golden set)
Набор тестовых вопросов и эталонных ответов/агрегатов для контроля качества и регрессии.
SLA/Latency
Целевые показатели времени ответа и доступности (например, 95-й перцентиль времени ответа).
Шаг 0
Слой данных для LLM (витрины/views)
2–5 дней
Что сделать
  • Сделать набор curated views (упрощённые представления) вместо сырых таблиц.
  • Стабилизировать статусы/даты/связи (Task ↔ Project ↔ Assignee).
  • Добавить словарь данных: описание полей и смысл KPI/метрик.
Результат
  • Views для аналитики (например: v_tasks, v_projects, v_overdue_tasks, v_status_daily).
  • Чёткие правила трактовки статусов и расчёта метрик.
Инструменты
  • PostgreSQL
  • Views / materialized views
  • Prisma schema (как источник структуры)
Безопасность
  • Read-only роль для чтения витрин
  • Логи/аудит запросов (по возможности)
Шаг 1
Инструменты (tools) вместо “модель пишет SQL”
3–7 дней
Что сделать
  • Реализовать allowlist функций: projectProgress, overdueTasks, tasksByStatus, assigneeLoad и т.д.
  • Каждой функции — строгую валидацию параметров и лимиты результата (limit/timeouts).
  • Единый формат JSON-ответов (чтобы модель не путалась).
Результат
  • Набор безопасных API-инструментов, которые достают факты из PostgreSQL.
  • Стабильные цифры/агрегаты без “аналитики из воздуха”.
Инструменты
  • Next.js Route Handlers
  • Prisma
  • Zod (валидация, опционально)
Безопасность
  • Rate limiting
  • Timeouts
  • Запрет опасных операций (только read)
Шаг 2
Цикл ответа: вопрос → tool → ответ
2–6 дней
Что сделать
  • Обновить серверный `/api/ai/chat`, чтобы модель могла запрашивать инструменты (или сервер сам подставлял данные).
  • Добавить системные правила: кратко, честный отказ вне задач/проектов, ссылки на источники (ID).
  • Привязать доступ к данным к сессии пользователя (RBAC).
Результат
  • Модель отвечает на основе фактов из БД, а не на “памяти”.
  • Снижение галлюцинаций, стабильная аналитика, контролируемые ответы.
Инструменты
  • ollama-js
  • Ollama локально
  • Next.js API routes
Безопасность
  • RBAC (видимость проектов/задач)
  • Скрытие полей (PII/финансы)
Шаг 3
RAG для правил/терминов (не для оперативных цифр)
4–10 дней
Что сделать
  • Сложить в базу знаний: словарь полей, определения KPI, регламенты, примеры корректных интерпретаций.
  • Настроить эмбеддинги и поиск, чтобы подставлять релевантные правила в контекст.
  • Указывать источники: какие документы/правила использованы.
Результат
  • Ассистент правильно трактует поля и метрики, отвечает “по регламенту”.
  • Менять правила можно без переобучения модели.
Инструменты
  • pgvector или Qdrant
  • Embeddings модель
  • ETL из docs/wiki
Безопасность
  • Санитизация документов
  • Контроль доступа к базе знаний
Шаг 4
Качество (eval) и эксплуатация
1–2 недели
Что сделать
  • Собрать golden set вопросов (20–100) + эталонные ответы/SQL-агрегаты.
  • Сделать автопрогон: краткость, корректность, отказ на нерелевантное, время ответа.
  • Добавить мониторинг latency/ошибок и фидбек в UI (полезно/неполезно).
Результат
  • Понимание, что ассистент отвечает правильно и безопасно.
  • Регресс-контроль при изменениях БД/витрин/моделей/промптов.
Инструменты
  • Playwright (UI)
  • Скрипты eval
  • Monitoring
Безопасность
  • Red-team вопросы (зарплаты/персональные данные/финансы)
  • Логи без секретов
Что получим на выходе
Итоговый результат внедрения подключения к базе.
  • Ассистент в Task.Log, который отвечает на основе фактов из PostgreSQL, а не “памяти”.
  • Набор витрин (views) и словарь данных, пригодные для аналитики и LLM.
  • Allowlist инструментов (tools) с валидацией, лимитами, таймаутами и форматами JSON.
  • RBAC: ответы ограничены правами пользователя (видимость задач/проектов).
  • Контур качества: golden set, автопрогоны, мониторинг latency/ошибок, red-team вопросы.
  • Платформа для расширения источников (MES/ERP/SCADA) по мере готовности и риск-оценки.