TL;DR

AI-модель забывает всё после каждой сессии. Векторная база данных решает эту проблему – хранит знания в виде чисел и находит похожее по смыслу, а не по ключевым словам.

Проблема: AI без памяти

Каждая сессия с LLM начинается с чистого листа:

БЕЗ RAG:                          С RAG:
┌──────────┐                      ┌──────────┐
│   LLM    │──→ Ollama            │   LLM    │──→ Ollama
│          │                      │   + RAG  │
└──────────┘                      └────┬─────┘
     │                                 │
  закрыл                            закрыл
  сессию                            сессию
     │                                 │
     ▼                                 ▼
┌──────────┐                      ┌──────────┐
│   LLM    │  "Я ничего не        │   LLM    │  "Да, в прошлый
│          │   помню"             │   + RAG  │   раз мы делали X"
└──────────┘                      └────┬─────┘
                                       │
                                  ┌────▼─────┐
                                  │  Qdrant  │ ← вектора
                                  └──────────┘

Вы потратили час объясняя модели архитектуру проекта. Закрыли терминал. Открыли снова – всё с нуля.

Обычный SQL здесь не поможет: он ищет по точному совпадению или LIKE-паттернам. Запрос “как настроить reverse proxy” не найдёт документ, в котором написано “проксирование запросов через nginx”. Разные слова, один смысл – это задача для векторного поиска.

Что такое Qdrant

Qdrant (произносится “квадрант”) – векторная база данных. Хранит данные не как строки таблицы, а как точки в многомерном пространстве.

Три ключевых концепции

1. Коллекция – аналог таблицы в PostgreSQL. Но вместо колонок и строк – набор точек (points) с векторами.

2. Вектор – координаты смысла в цифровом пространстве. Модель-эмбеддер превращает текст в массив чисел фиксированной длины. Тексты с похожим значением получают близкие координаты, даже если написаны разными словами:

"Docker контейнер"  → [0.12, -0.34, 0.56, ..., 0.78]   # 384 числа
"Контейнеризация"   → [0.11, -0.31, 0.54, ..., 0.76]   # похожий вектор
"Рецепт борща"      → [-0.89, 0.45, -0.12, ..., 0.03]  # совсем другой

3. Косинусная близость (cosine similarity) – мера похожести двух векторов. Не сравнивает длину, только направление:

cosine("Docker контейнер", "Контейнеризация") = 0.94  ← похожи
cosine("Docker контейнер", "Рецепт борща")    = 0.12  ← не похожи

Чем ближе к единице – тем больше общего в значении, даже если сами слова разные. 0 – ничего общего, 1 – одно и то же. На практике score выше 0.8 – хорошее совпадение.

Payload – метаданные к вектору

Каждая точка в Qdrant хранит не только вектор, но и произвольные данные:

{
  "id": "abc-123",
  "vector": [0.12, -0.34, ...],
  "payload": {
    "text": "Для reverse proxy используйте proxy_pass...",
    "file_path": "nginx-guide.md",
    "start_line": 45,
    "end_line": 89,
    "tags": "nginx, proxy"
  }
}

Payload позволяет модели не только найти релевантный кусок, но и сослаться на источник: “Согласно nginx-guide.md, строки 45-89…”

Практика: Qdrant за 15 минут

Шаг 1. Запускаем Qdrant

docker run -d \
  --name qdrant \
  -p 6333:6333 \
  -v qdrant-data:/qdrant/storage \
  qdrant/qdrant:latest

Проверяем:

curl -s http://localhost:6333/healthz
# healthz check passed

Dashboard доступен в браузере: http://localhost:6333/dashboard

Шаг 2. Создаём коллекцию

curl -X PUT http://localhost:6333/collections/demo \
  -H "Content-Type: application/json" \
  -d '{
    "vectors": {
      "size": 384,
      "distance": "Cosine"
    }
  }'

Параметры:

• size: 384 – размерность вектора (зависит от модели эмбеддинга, all-MiniLM = 384)
• distance: "Cosine" – метрика сравнения (косинусная близость)

Проверяем:

curl -s http://localhost:6333/collections/demo | python3 -m json.tool

Шаг 3. Добавляем данные (upsert)

384 числа вручную писать не нужно – используем Python-скрипт, который генерирует демо-вектора (в реальности их создаёт модель эмбеддинга):

#!/usr/bin/env python3
# demo-upsert.py — добавляем точки в Qdrant
import requests, random

QDRANT = "http://localhost:6333"

random.seed(42)
points = [
    {
        "id": 1,
        "vector": [random.uniform(-1, 1) for _ in range(384)],
        "payload": {
            "text": "Для reverse proxy в nginx используйте proxy_pass",
            "source": "nginx-guide.md",
            "topic": "nginx"
        }
    },
    {
        "id": 2,
        "vector": [random.uniform(-1, 1) for _ in range(384)],
        "payload": {
            "text": "Docker Compose описывает многоконтейнерное приложение в YAML",
            "source": "docker-guide.md",
            "topic": "docker"
        }
    }
]

resp = requests.put(f"{QDRANT}/collections/demo/points",
                    json={"points": points})
print(resp.json())
# {"result":{"operation_id":0,"status":"acknowledged"},...}

pip install requests
python3 demo-upsert.py

upsert – если точка с таким ID существует, обновит; если нет – создаст. Идемпотентная операция.

Шаг 4. Семантический поиск

Ищем точку, ближайшую к нашему запросу:

#!/usr/bin/env python3
# demo-search.py — семантический поиск в Qdrant
import requests, random

QDRANT = "http://localhost:6333"

# Для демо: используем вектор, идентичный точке 1 (nginx)
# В реальности вектор запроса создаёт модель эмбеддинга
random.seed(42)
query_vector = [random.uniform(-1, 1) for _ in range(384)]

resp = requests.post(f"{QDRANT}/collections/demo/points/search",
                     json={
                         "vector": query_vector,
                         "limit": 2,
                         "with_payload": True
                     })

for hit in resp.json()["result"]:
    score = hit["score"]
    text = hit["payload"]["text"]
    source = hit["payload"]["source"]
    print(f"  [{score:.4f}] {source}: {text}")

python3 demo-search.py
#   [1.0000] nginx-guide.md: Для reverse proxy в nginx используйте proxy_pass
#   [0.0353] docker-guide.md: Docker Compose описывает многоконтейнерное...

Точка с nginx получила score 1.0 (идеальное совпадение – мы искали тем же вектором). Docker получил почти 0 – совсем другой смысл.

Шаг 5. Реальный семантический поиск (с Ollama)

В реальном pipeline вектора создаёт модель эмбеддинга. Вот как это работает с Ollama:

# Скачиваем модель эмбеддинга
ollama pull all-minilm

# Получаем вектор запроса
curl -s http://localhost:11434/api/embed \
  -d '{"model":"all-minilm","input":"как настроить reverse proxy"}' \
  | python3 -c "
import sys, json
emb = json.load(sys.stdin)['embeddings'][0]
print(f'Размерность: {len(emb)}')
print(f'Первые 5 чисел: {[round(x,4) for x in emb[:5]]}')
"
# Размерность: 384
# Первые 5 чисел: [-0.0312, 0.0891, -0.0456, 0.1234, -0.0678]

Тот же текст всегда даёт тот же вектор. Похожие тексты дают похожие вектора. На этом и строится семантический поиск.

Под капотом: как работает RAG-поиск

Запрос пользователя          База знаний (Qdrant)
"как настроить proxy"         ┌──────────────────┐
        │                     │ nginx-guide.md   │→ [0.12, -0.34, ...]
        ▼                     │ docker-guide.md  │→ [0.89, 0.45, ...]
 Embedding Model              │ ssh-guide.md     │→ [-0.56, 0.23, ...]
 (all-MiniLM)                 └──────────────────┘
        │                              │
        ▼                              │
 [0.11, -0.31, ...]       косинусная близость
        │                              │
        └──────────────────────────────┘
                    │
                    ▼
            Ранжирование:
            1. nginx-guide.md  → 0.94
            2. docker-guide.md → 0.67
            3. ssh-guide.md    → 0.23
                    │
                    ▼
            Top-K результатов → в контекст LLM

Ключевые этапы:

1. Векторизация (embedding) – текст запроса превращается в вектор той же моделью, которой индексировалась база
2. Векторный поиск (vector search) – Qdrant ищет ближайшие точки по косинусной близости (алгоритм HNSW, логарифмическая сложность)
3. Ранжирование (ranking) – результаты сортируются по оценке релевантности (score)
4. Подстановка контекста (context injection) – лучшие K результатов вставляются в промпт LLM вместе с метаданными

Важное правило: одна модель эмбеддинга для индексации и поиска. Если индексировали через all-minilm, искать тоже через all-minilm. Разные модели дают несовместимые вектора.

Мини-тест

1. Почему PostgreSQL с LIKE '%proxy%' не заменяет векторный поиск?

2. Коллекция создана с size: 384. Можно ли добавить вектор длиной 768?

3. Score = 0.95. Score = 0.45. Что это значит для качества поиска?

4. Что такое payload в Qdrant и зачем он нужен в RAG?

Артефакт: docker-compose.yml

Готовый файл для запуска Qdrant с персистентным хранилищем:

# docker-compose.yml — Qdrant для RAG Pipeline
services:
  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    ports:
      - "6333:6333"   # REST API + Dashboard
      - "6334:6334"   # gRPC (для Python SDK)
    volumes:
      - qdrant-data:/qdrant/storage
    environment:
      - QDRANT__SERVICE__GRPC_PORT=6334
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:6333/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s

volumes:
  qdrant-data:

Скрипт проверки:

#!/bin/bash
# check-qdrant.sh — проверка что Qdrant работает

set -euo pipefail

QDRANT_URL="${QDRANT_URL:-http://localhost:6333}"

echo "=== Qdrant Health Check ==="

# 1. Health
HEALTH=$(curl -sf "$QDRANT_URL/healthz" 2>/dev/null || echo "FAIL")
if echo "$HEALTH" | grep -q "passed"; then
    echo "[OK] Qdrant is healthy"
else
    echo "[FAIL] Qdrant is not responding at $QDRANT_URL"
    exit 1
fi

# 2. Collections
curl -sf "$QDRANT_URL/collections" | python3 -c "
import sys, json
data = json.load(sys.stdin)
cols = data.get('result', {}).get('collections', [])
if cols:
    for c in cols:
        print(f\"  {c['name']}\")
    print(f'Total collections: {len(cols)}')
else:
    print('[INFO] No collections yet')
"

echo "=== Done ==="

Запуск:

docker compose up -d
chmod +x check-qdrant.sh
./check-qdrant.sh

Продакшен-параметры

Для справки – параметры нашего рабочего RAG pipeline:

Что дальше

Это первый пост серии RAG Pipeline. Qdrant – хранилище. Но чтобы pipeline заработал, нужны ещё два компонента:

• RAG Pipeline 2/N – Embeddings: Ollama vs API – как превращать текст в вектора, выбор модели, batch vs single, подводные камни с русским текстом
• RAG Pipeline 3/N – Chunking – размер чанка, overlap, split по границам функций, metadata для цитирования

Telegram: @DevITWay Сайт: devopsway.ru

Откройте roadmap.sh/mlops. Там 90+ тем, разбросанных по 11 категориям. Feature Store, Model Registry, Data Versioning, Experiment Tracking, Model Serving, A/B Testing, Data Labeling… Каждая тема – отдельный мир с документацией на 200 страниц.

Если вы DevOps-инженер, который хочет перейти в MLOps, эта карта выглядит как план захвата Луны, когда вам нужно просто доехать до работы.

Проблема roadmap.sh – он показывает всё, что существует, но не говорит, что из этого реально нужно. Это как список из 500 инструментов в Prometheus – технически они есть, практически вы используете 12.

Здесь другой подход. Вместо экспертных мнений – данные.

Методология: откуда данные

В основе – 838 вакансий из двух источников:

Из каждой вакансии извлечены: название роли, технологический стек, зарплатная вилка, требования к английскому, формат работы.

Из 566 вакансий getmatch – 62 с чистым заголовком «MLOps». Это контрольная группа – те, кого рынок буквально называет MLOps-инженерами.

Что рынок реально просит

Общий TOP-12: 80% вакансий

Из 90+ тем на roadmap.sh рынок фактически спрашивает 12 навыков. Вот они – отсортированы по частоте упоминания в 566 вакансиях:

Заметили? 10 из 12 – это чистый DevOps. MLOps-специфика начинается только на 11-м месте.

Это не баг, это фича. MLOps – это DevOps, который понимает жизненный цикл моделей. Не наоборот.

Стек MLOps-инженера: 62 вакансии под микроскопом

А вот что просят конкретно в вакансиях с заголовком «MLOps»:

Вывод: Airflow (оркестрация) + MLflow (трекинг) – это два навыка, которые отличают MLOps от обычного DevOps. Каждый из них – в 50% вакансий. Всё остальное – надстройка.

Что roadmap.sh считает важным, а рынок – нет

Вот инструменты, которые roadmap.sh ставит на видное место, но в 838 вакансиях – ноль упоминаний:

*DVC – единственный, который встречается на hh.ru, потому что hh.ru ловит ML-ориентированные вакансии, а не ops-ориентированные.

Это не значит, что W&B – плохой инструмент. Это значит, что рынок РФ его не просит. Учить его «на всякий случай» – как учить суахили, потому что «мало ли».

Что рынок просит, а roadmap.sh не показывает

Российская специфика: on-premise доминирует (отсюда Ansible 32.9%), AWS – всего 5.7%, Yandex Cloud – 3.9%. Облака – вторичны. Если вы учите SageMaker, потому что так написано на roadmap.sh, – вы учите неправильное облако.

Зарплатная пирамида

Данные из 279 вакансий с зарплатой в рублях (getmatch, на руки):

          ████████            1М+ ₽ (4)      CTO, руководитель ML
        ████████████          500–700К (11)  Архитектор, Principal
      ████████████████        400–500К (51)  Senior MLOps/SRE
    ████████████████████      300–400К (139) Mid/Senior  ◀ ПИК
  ████████████████████████    200–300К (57)  Junior+/Mid DevOps
████████████████████████████  50–200К (17)   Начальный уровень

Медиана: 325 000 ₽/мес (на руки)

Пик рынка – 300–400К. Это уровень, на который попадает инженер с DevOps-базой + Airflow + MLflow. Для 400К+ нужна GPU-специфика (CUDA, Triton) или управленческий опыт.

Кто нанимает MLOps в России

TOP-10 компаний по количеству вакансий за 9 месяцев:

65% вакансий – удалёнка. Английский требуется в 16% случаев (обычно B1–B2).

SFIA-маппинг: от новичка до архитектора

SFIA 9 содержит навык MLNG (Machine Learning) – уровни L2 через L6. Ниже – наложение реальных стеков из вакансий на эти уровни:

L2 – Помощник (50–150К)

Помогает с подготовкой данных, выполняет типовые операции.

Стек: Python, SQL, Linux basics, Git, Docker

L3 – Практик (150–250К)

Обучает и настраивает модели, базовая оценка результатов.

Стек: + Bash, PostgreSQL, Jupyter, pandas, scikit-learn

L4 – Специалист (250–350К)

Проектирует ML-пайплайны, выбирает алгоритмы, решает проблемы дрифта.

Стек: + Kubernetes, CI/CD, Terraform, Prometheus/Grafana, Airflow, MLflow

L5 – Эксперт MLOps (350–500К)

Управляет production ML lifecycle, CI/CD for ML, мониторинг моделей, GPU-кластеры.

Стек: + Seldon/Triton, ClearML, CUDA, Kafka, Spark, Helm, ArgoCD

L6 – Стратег (500К–1М+)

Стратегия ML-платформы, governance, оценка рисков, бюджет инфраструктуры.

Стек: + архитектура ML-платформы, cost optimization, team management, vendor evaluation

Сравнение подходов: roadmap.sh vs данные

Рабочий план: от DevOps к MLOps

Если вы уже DevOps-инженер (Linux, Docker, K8s, CI/CD), вот минимальный путь в MLOps:

Шаг 1. Python для ML-пайплайнов

Не «учить Python с нуля». А понять, как:

• читать и модифицировать train.py
• работать с pandas/numpy для данных
• запускать FastAPI для model serving

Ваш bash-скриптинг никуда не денется – Python его дополняет, а не заменяет.

Шаг 2. MLflow – трекинг экспериментов

50% MLOps-вакансий. Ставится за 10 минут, интегрируется с S3/PostgreSQL, которые вы уже знаете:

pip install mlflow
mlflow server --backend-store-uri postgresql://... --artifacts-destination s3://...

Шаг 3. Airflow – оркестрация пайплайнов

50% MLOps-вакансий. Если вы работали с Jenkins или GitLab CI – Airflow это то же самое, только для данных. DAG – это ваш Jenkinsfile, написанный на Python.

with DAG("retrain_model", schedule="@weekly") as dag:
    extract = PythonOperator(task_id="extract", python_callable=extract_data)
    train = PythonOperator(task_id="train", python_callable=train_model)
    deploy = PythonOperator(task_id="deploy", python_callable=deploy_model)
    extract >> train >> deploy

Шаг 4. Model serving на K8s

Вы уже знаете Kubernetes. Добавьте:

• Seldon Core (16% вакансий) – model serving с canary, A/B, shadow
• Triton Inference Server (16% вакансий) – GPU-оптимизация

Деплой модели – это тот же Helm chart, только с gRPC-эндпоинтом вместо HTTP.

Шаг 5 (опционально). GPU и LLM

14.5% MLOps-вакансий уже просят LLM/GPT. Тренд растёт. Если хотите 400К+:

• CUDA basics – как модель использует GPU
• vLLM – serving для LLM
• GPU-мониторинг (DCGM + Prometheus)

Чего точно не нужно учить прямо сейчас

• W&B / Neptune – 0 вакансий в РФ, MLflow покрывает 100% задач
• Feast (Feature Store) – 2 из 566, на практике DataFrame хватает
• Dagster / Prefect – Airflow доминирует, переучитесь, когда (если) рынок изменится
• SageMaker / Vertex AI – если вы не в AWS/GCP-конторе, это мёртвый груз
• Great Expectations – концепция правильная, инструмент нишевый (0 вакансий)

Итог

MLOps – это не 90 тем. Это DevOps + два инструмента (Airflow + MLflow) + понимание того, чем модель отличается от микросервиса.

Рынок подтверждает:

• 12 навыков покрывают 80% вакансий
• Медиана – 325К на руки
• 65% вакансий – удалёнка
• Переход DevOps → MLOps реалистичен – 10 из 12 ключевых навыков у вас уже есть

Не учите всё. Учите то, что просят.

Данные: 566 вакансий getmatch (Telegram API) + 272 вакансии hh.ru, июль 2025 – апрель 2026. Методология: regex-парсинг стека, классификация по 70+ паттернам, кросс-валидация между источниками.

📱 Telegram: @DevITWay 🌐 Сайт: devopsway.ru