4.4 · Векторная БД + загрузка базы знаний

Неделя 4 · RAG · ⏱ ~8 ч (2 дня) · Проект

Зачем это AI-инженеру

В гл. 4.3 стратегия нарезки определена на 10–20 страницах kb/, но каждый прогон заново резал и эмбеддил всё в памяти. Теперь игрушечный поиск на numpy из гл. 4.1 превращается в настоящий индекс: сотни и тысячи чанков, метаданные, фильтры, повторная загрузка без дублей. Ingestion-пайплайн — это 60% реальной работы над RAG в компаниях: источники меняются, ломаются, дублируются. На собеседовании спрашивают «как вы обновляете индекс», «как фильтруете по тенанту/источнику», «чем pgvector отличается от отдельной векторной БД» — после этой задачи у нас будут ответы из собственного опыта.

Теория

Что даёт векторная БД сверх numpy

Векторная БД — хранилище, которое держит векторы вместе с текстом и метаданными и умеет искать ближайшие к запросу. Сравним её с тем, что уже умеет numpy:

Задача	numpy (гл. 4.1)	Векторная БД
Хранение	`.npy` в памяти	На диске, транзакции
Текст и метаданные	Отдельный JSON рядом	В той же записи
Фильтр «только гарантия»	Руками маской	`WHERE category = 'warranty'`
Обновление одного документа	Пересобрать массив	`DELETE` + `INSERT`
Миллионы векторов	Медленно и не влезает в память	ANN-индексы (HNSW, IVF)

На нашем масштабе (сотни — десятки тысяч чанков) точный перебор (brute force) занимает миллисекунды. Поэтому выбор хранилища здесь — вопрос удобства и знакомости, а не скорости.

ANN: приближённый поиск, коротко

Нам ANN не понадобится, но именно он отличает большие векторные БД и о нём спрашивают на собеседованиях. Точный поиск сравнивает запрос со всеми векторами: O(N). При миллионах векторов это медленно, поэтому используют приближённый поиск ближайших соседей (ANN):

HNSW — многоуровневый граф «соседей»; поиск идёт жадно от дальних связей к ближним. Быстрый, точный, но жрёт память. Стандарт в Qdrant, pgvector, многих других.
IVF — векторы разбиты на кластеры; ищем только в нескольких ближайших кластерах.

Цена ANN — recall < 100%: иногда настоящий ближайший сосед не находится. Важная практическая ловушка — фильтр + ANN: если сначала найти top-10 по вектору, а потом отфильтровать «только гарантия», может остаться 0 результатов (post-filtering). Хорошие БД умеют фильтровать внутри поиска или до него (pre-filtering, partition). На нашем объёме с точным поиском этой проблемы почти нет, но знать её обязательно.

Три варианта хранилища

Выбор хранилища на нашем объёме — вопрос удобства, поэтому сравниваем три типичных варианта: расширение к SQLite, расширение к Postgres и отдельный сервис.

sqlite-vec — расширение SQLite. Вектор хранится в виртуальной таблице vec0, поиск — обычным SQL. Один файл, ноль серверов, знакомый инструмент (базы магазина в курсе тоже SQLite с WAL). Делает точный поиск (brute force), чего на нашем масштабе более чем хватает. Проект молодой: синтаксис и возможности (метаданные-колонки, partition keys, выбор метрики) развиваются — сверяемся с README и документацией той версии, которую ставим.

pgvector — расширение PostgreSQL: тип vector, операторы расстояния (<-> L2, <=> косинусное расстояние, <#> отрицательное скалярное произведение), индексы HNSW и IVFFlat. Лучший выбор, если в проекте уже есть Postgres: векторы рядом с бизнес-данными, транзакции, JOIN.

Qdrant — отдельная векторная БД (Rust), с REST/gRPC API, коллекциями, payload-фильтрами и HNSW. Удобна, когда векторов много, нужен масштаб и продвинутые фильтры. Плата — ещё один сервис в инфраструктуре.

Для проекта берём sqlite-vec, остальные — читаем для сравнения.

sqlite-vec: схема

Идея: обычная таблица с текстом и метаданными + виртуальная таблица с векторами, связанные по rowid.

1
CREATE TABLE IF NOT EXISTS chunks (
2
  id            INTEGER PRIMARY KEY,
3
  chunk_key     TEXT UNIQUE NOT NULL,   -- sha256(url + section + text)
4
  category      TEXT NOT NULL,          -- delivery | payment | returns | warranty | promo | orders | products
5
  archived      INTEGER NOT NULL DEFAULT 0,  -- 1 = old version, excluded from search by default
6
  doc           TEXT NOT NULL,          -- page: kb/returns.md (or the web page URL)
7
  url           TEXT NOT NULL,          -- citation target: kb/returns.md#opened-tea-returns
8
  section       TEXT,
9
  text          TEXT NOT NULL,
10
  doc_hash      TEXT NOT NULL,          -- hash of the whole page content
11
  embed_model   TEXT NOT NULL,
12
  loaded_at     TEXT NOT NULL
13
);
14

15
-- Check the sqlite-vec docs for the exact vec0 options of your version
16
CREATE VIRTUAL TABLE IF NOT EXISTS vec_chunks USING vec0(
17
  embedding float[1024]                 -- bge-m3; must equal your model's dimension
18
);

Подключение из Python (иллюстративно, сверяем с README):

1
import sqlite3
2
import sqlite_vec
3

4
db = sqlite3.connect("index.db")
5
db.enable_load_extension(True)
6
sqlite_vec.load(db)
7
db.enable_load_extension(False)

Если enable_load_extension отсутствует — Python собран без поддержки расширений SQLite (бывает с системным Python на macOS); ставим Python через Homebrew/pyenv/uv.

Вставка и KNN-запрос (k nearest neighbors — найти k ближайших к запросу векторов). Чанк вставляем в chunks, а его вектор — в vec_chunks с тем же rowid:

1
from sqlite_vec import serialize_float32
2

3
cur = db.execute(
4
    "INSERT INTO chunks (chunk_key, category, archived, doc, url, section, text, "
5
    "doc_hash, embed_model, loaded_at) "
6
    "VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ON CONFLICT(chunk_key) DO NOTHING",
7
    (key, category, archived, doc, url, section, text, doc_hash, MODEL, now),
8
)
9
if cur.rowcount == 1:  # inserted, not a duplicate
10
    db.execute("INSERT INTO vec_chunks (rowid, embedding) VALUES (?, ?)",
11
               (cur.lastrowid, serialize_float32(vec)))
12

13
rows = db.execute(
14
    """
15
    SELECT c.category, c.url, c.section, c.text, v.distance
16
    FROM vec_chunks v JOIN chunks c ON c.id = v.rowid
17
    WHERE v.embedding MATCH ? AND k = ?
18
    ORDER BY v.distance
19
    """,
20
    (serialize_float32(qvec), 10),
21
).fetchall()

Обратим внимание на distance: это расстояние (меньше = ближе), а не сходство. По умолчанию — L2; для нормализованных векторов порядок тот же, что у косинуса (гл. 4.1).

Фильтр по метаданным с векторным поиском

KNN выше ищет по всей базе, а ассистенту часто нужна одна категория: на вопрос о гарантии — только куски про гарантию. Наивный вариант — найти top-k по всей базе, потом WHERE c.category = 'warranty' в JOIN. Это post-filtering: при k=10 может оказаться, что все 10 — из карточек товаров (products, их в базе больше всего), и для гарантии получим ноль. Варианты:

Метаданные/partition key прямо в vec0 — в свежих версиях sqlite-vec можно объявить колонки вроде category text (или category text partition key) и archived integer в виртуальной таблице и фильтровать по ним в том же KNN-запросе. Проверяем в документации своей версии.
Отдельная vec0-таблица на категорию — грубо, но надёжно.
Большой k + фильтр + обрезка (взять k=200, отфильтровать, оставить 10) — простой компромисс на малом объёме.
Точный поиск в numpy по подмножеству: вытащить векторы нужной категории и посчитать как в гл. 4.1 — на нашем объёме тоже вариант.

Выбираем 1, если поддерживается; иначе 3. Главное — тест: «поиск с фильтром warranty всегда возвращает k результатов из категории warranty, если они есть».

Второй фильтр — archived. Старая версия правил возврата (returns-2025.md, archived: true) по тексту почти совпадает с актуальной, и без фильтра поиск охотно поднимет устаревшие сроки. По умолчанию архив исключаем (archived = 0 тем же способом, что и категорию), включаем только явным флагом. Из индекса архив не удаляем: на нём позже проверяется, что retrieval не путает версии.

Ingestion-пайплайн

Схема и поиск готовы; теперь — как наполнять индекс и обновлять его, когда база знаний меняется. Этим занимается ingestion-пайплайн (загрузка):

sources.yaml ─► load (kb/*.md: front matter → метаданные)
             └► [по желанию] fetch (GET, кэш на диск) ─► clean (HTML → Markdown)
     ─► chunk (стратегия из AIL-19) ─► dedupe (chunk_key) ─► embed (батчами)
     ─► upsert в SQLite ─► отчёт: страниц, чанков новых/старых/удалённых

Принципы из бэкенда здесь работают так же:

Идемпотентность. Повторный запуск без изменений в базе знаний не меняет индекс. Достигается детерминированным ключом чанка: sha256(url + section + text), и UNIQUE в схеме.
Инкрементальность. Храним doc_hash страницы (файл вместе с front matter: смена archived тоже переиндексирует страницу). Если хэш не изменился — страницу пропускаем целиком (ни chunking, ни эмбеддинги). Если изменился — удаляем старые чанки этой страницы (DELETE ... WHERE doc = ? и соответствующие строки vec_chunks) и вставляем новые. Файл удалили из kb/ — его чанки тоже удаляются.
Кэш сырья (для веб-страниц). Скачанный HTML сохраняем в raw/web/<slug>.html. Отлаживать чистку придётся много раз, а качать заново — невежливо к сайту. Для kb/ кэш не нужен.
Батчи эмбеддингов и кэш (гл. 4.1).
Транзакции. Обработка одной страницы — одна транзакция: либо все её чанки обновились, либо ничего.
Записываем embed_model. Сменили модель — по этому полю видно, что индекс надо перестроить.

Загрузка базы знаний

Первый шаг пайплайна — load. Корпус проекта — справочный центр магазина «Полка» в папке kb/: Markdown-файлы с заголовками, источник истины, как документация в репозитории. Первые 10–20 страниц появились в гл. 4.3, здесь дописываем базу до 30–50.

Источник	Где	Особенности
Правила магазина	`kb/delivery.md`, `payment.md`, `returns.md`, `warranty.md`, `promo.md`, `orders.md`	Длинные страницы с таблицами; ссылка раздела = файл + якорь
Архив	`kb/returns-2025.md` (`archived: true`)	Старая версия правил возврата — ловушка для retrieval
Карточки товаров	`kb/products/*.md`	Много коротких страниц; есть похожие (`lamp-light.md` и `lamp-light-mini.md` с разной гарантией)

Каждый файл начинается с front matter — отсюда load.py берёт метаданные:

---
title: Возврат товара
category: returns
updated: 2026-03-01
---

# Возврат товара

## Возврат вскрытого чая {#opened-tea-returns}

load.py разбирает front matter (yaml.safe_load), проверяет category по допустимому списку и падает с именем файла, если front matter нет или он битый; в текст чанков front matter не попадает. Список источников держим в sources.yaml, а не в коде.

Тексты выдуманы, поэтому черновики пишет облачная модель по брифу, а мы правим их руками. Встроенные сложности оставляем сознательно, на них построены будущие evals: архивные правила возврата; таблицы тарифов и гарантий; похожие товары; числа, которые расходятся между страницами (порог бесплатной доставки в delivery.md и в promo.md); вопросы, ответ на которые требует двух разделов.

Веб-страница (по желанию). Сбор публичных страниц пригодится на работе, поэтому одну реальную справочную страницу (правила доставки службы) добавляем через fetch.py → clean.py с category: delivery, source: web. Вежливость к сайтам: пауза между запросами (0.5–1 с), понятный User-Agent без личных данных, уважаем robots.txt, кэшируем. Если страница рендерится JavaScript’ом и в HTML пусто — сначала ищем, нет ли исходников в виде Markdown (например, в публичном GitHub-репозитории сервиса), и лишь потом думаем о headless-браузере.

HTML → Markdown: сначала вырезаем основной контент (контейнер статьи; CSS-селектор находим в devtools), потом конвертируем (markdownify, html2text или trafilatura). Проверяем глазами: таблицы и списки должны уцелеть.

Ссылка с якорем

Последнее поле чанка, которое надо продумать до загрузки, — url. Для цитат (гл. 5.3) у чанка должна быть ссылка, ведущая как можно ближе к месту: kb/returns.md#opened-tea-returns, а не просто kb/returns.md. Заголовкам даём стабильные id: явный {#anchor} (так сделано на страницах из гл. 4.3) или детерминированный slug из текста заголовка. Явный id лучше — он не меняется, когда заголовок переформулируют. У веб-страницы якоря обычно есть в id у заголовков HTML — сохраняем их на этапе чистки. Якорь раздела записываем в url чанка.

DeepSeek и Ollama: как это сделать у нас

Индексация — единственное место проекта, где модель вызывается сотни и тысячи раз подряд, и это только эмбеддинги. У DeepSeek их нет — это разобрано в главе 4.1 · Эмбеддинги руками на numpy. Поэтому весь ingestion работает локально и бесплатно: Ollama или Sentence Transformers. Облачный ключ для ingest.py не нужен вообще.

`embed.py` с выбором бэкенда

1
# Illustrative: one interface, backend chosen by env vars (EMBED_BACKEND, EMBED_MODEL)
2
import os
3
import numpy as np
4

5
BACKEND = os.environ.get("EMBED_BACKEND", "ollama")   # ollama | st | openai
6
MODEL = os.environ["EMBED_MODEL"]                     # e.g. bge-m3 / BAAI/bge-m3
7

8
def embed(texts: list[str]) -> np.ndarray:
9
    if BACKEND == "ollama":
10
        import ollama
11
        res = ollama.embed(model=MODEL, input=texts, truncate=False, keep_alive="10m")
12
        return np.asarray(res["embeddings"], dtype=np.float32)
13
    if BACKEND == "st":
14
        from sentence_transformers import SentenceTransformer
15
        st = _cached_st(MODEL)                        # TODO: load once, reuse
16
        return st.encode(texts, normalize_embeddings=True, batch_size=32).astype(np.float32)
17
    raise ValueError(f"unknown backend {BACKEND}")    # 'openai' is optional, for comparison
18

19
def model_tag() -> str:
20
    return f"{BACKEND}:{MODEL}"                       # store this in chunks.embed_model

Что это меняет в схеме и пайплайне:

Размерность vec0 = размерность модели. У bge-m3 1024 (по карточке BAAI/bge-m3), поэтому в схеме выше embedding float[1024]; у другой модели число будет другим (например, 384 у paraphrase-multilingual-MiniLM-L12-v2 из гл. 4.1). Число не берём из памяти: вызываем len(embed(["test"])[0]) и подставляем результат.
embed_model хранит и бэкенд: ollama:bge-m3 и st:BAAI/bge-m3 — разные индексы, даже если имя модели одно (глава 4.1).
Батчи. input у /api/embed принимает список. Размер батча (16–64 чанка) подбираем по скорости своей машины: слишком большой батч не ускоряет и ест память.
Модель в памяти. Первый вызов грузит модель (поле load_duration в ответе). Параметр keep_alive держит её загруженной между запросами — важно для search.py, иначе каждый поиск начинается с загрузки. Обратная сторона на машине с 8 GB, где рядом открыты браузер и IDE: загруженная модель держит память, пока не истечёт keep_alive. Для ingest.py хватает короткого keep_alive; после индексации проверяем ollama ps и выгружаем модель (ollama stop <модель>). Не держим одновременно эмбеддинг-модель, генератор и реранкер, не прикинув их суммарный размер.
Ollama должен быть запущен. Если сервер не отвечает на localhost:11434, ingest.py должен падать с понятным сообщением («Ollama не запущен: ollama serve»), а не с трейсбеком на 40 строк.
Латентность поиска теперь без сети: эмбеддинг вопроса локальной моделью на обычном ноутбуке (например, Apple Silicon) занимает порядка десятков миллисекунд, если модель уже загружена. Этой цифре не верим на слово — измеряем.

Сравнение провайдеров для индексации

Что нужно индексу	Claude	OpenAI	DeepSeek	Ollama / Sentence Transformers
Эмбеддинги тысяч чанков	Нет своих (Voyage AI)	Да, платно за токены, rate limits	Нет	Да, бесплатно; ограничено скоростью машины
Батч в одном запросе	—	Да (список в `input`)	—	Да (список в `input`; у ST — `batch_size`)
Сеть при поиске	—	Запрос к API на каждый вопрос	—	Нет, всё локально
Ключ в `.env` для `ingest.py`	—	`OPENAI_API_KEY`	—	Не нужен

Практика этой главы делается целиком на локальном бэкенде. OpenAI-эмбеддинги — только «для сравнения» и только в отдельный index_openai.db (смешивать векторы разных моделей в одной таблице нельзя). Отправлять kb/ в облако можно: база знаний публичная.

Маршрут изучения

Открываем sqlite-vec → README целиком, затем по ссылке из README — документацию: установка для Python, vec0, KNN-запросы, метаданные/partition keys, метрики расстояния (≈45 мин). Выносим точный синтаксис для своей версии и как в ней фильтровать по колонке в KNN-запросе.
Открываем pgvector → README: разделы про создание колонки vector, операторы расстояния, HNSW и IVFFlat, «Filtering» (≈30 мин). Обратим внимание, как здесь описана проблема фильтрации с ANN-индексом и способы её решения — это то же, что в теории выше.
Открываем Qdrant → документация: Concepts → Collections, Points, Payload, Filtering, Indexing (≈30 мин). Выносим, чем payload-индекс помогает фильтрам и почему Qdrant фильтрует во время поиска по графу, а не после.
Сверяем страницы kb/ из гл. 4.3 с макетом из «Практики»: front matter, явные якоря у заголовков, целые таблицы (≈20 мин). Для необязательного пункта открываем публичную страницу правил доставки реальной службы и в devtools находим контейнер текста и id заголовков (≈10 мин).
Документация конвертера HTML → Markdown, если делаем веб-страницу (markdownify или html2text на PyPI, или trafilatura) — параметры для заголовков, таблиц и списков (≈15 мин).
Перечитываем справку Ollama /api/embed (≈10 мин): input списком, truncate, keep_alive, поля load_duration и prompt_eval_count. Выносим, как держать модель загруженной во время ingest.py и search.py.

На что обратить внимание

Несовпадение размерности float[N] в vec0 и модели → ошибка вставки (это хорошо, лучше, чем молча).
distance ≠ similarity. Меньше — ближе. Не сортируем по убыванию по привычке.
Post-filtering возвращает меньше k результатов или ноль. Фильтр тестируем на редкой категории.
Архив в выдаче: забыли фильтр archived — и бот уверенно цитирует отменённые правила возврата.
Дубли при повторной загрузке: ключ не детерминирован (включает время или случайный id). Ключ только из содержимого.
Осиротевшие векторы: удалили строки из chunks, забыли vec_chunks → в выдаче JOIN пропадает строка, а k фактически меньше. Удаляем в одной транзакции.
Мусор в тексте чанков — главный враг качества (см. гл. 4.3): front matter, навигация веб-страницы. Проверяем 10 случайных чанков глазами.
Таблицы режутся пополам при chunking, а HTML-таблицы с colspan ломают конвертеры. Таблицу тарифов держим в одном чанке или превращаем в список «зона: вес, цена, срок».
Одна ссылка на весь файл kb/delivery.md — цитата будет бесполезной. Нужны якоря.
Блокировки и капча при агрессивном скачивании веб-страниц. Паузы и кэш.
Безопасность: проект не ходит в базы магазина; в .env только ключ провайдера LLM (DeepSeek; OpenAI/Anthropic — если делаем сравнение), .env в .gitignore. При локальных эмбеддингах индексации ключ не нужен вовсе. Индекс (index.db) и raw/ тоже в .gitignore — их можно пересобрать скриптом; kb/ — наоборот, в git: это исходники. Настоящие сообщения клиентов в облако не уходят; тестовые вопросы выдумываем.

Практика

Структура проекта projects/02-support-kb-rag/:

02-support-kb-rag/
  sources.yaml          # kb/ path + optional web pages (URL, content selector, delay)
  kb/                   # shop help center: Markdown with front matter, source of truth
  rag/
    load.py             # read kb/*.md: front matter -> metadata, keep heading anchors
    fetch.py            # optional: GET + disk cache in raw/web/
    clean.py            # optional: HTML -> Markdown, keep anchors, tables
    chunk.py            # strategy chosen in AIL-19
    embed.py            # batch embeddings + cache
    store.py            # sqlite-vec schema, upsert, search
  ingest.py             # CLI: python ingest.py [--category returns]
  search.py             # CLI: python search.py "query" --category returns -k 5
  tests/test_store.py

Готово, когда

Индекс по всей базе знаний (30–50 страниц kb/, все категории) в одном index.db, с метаданными category, archived, url (kb/<file>.md#<anchor>), section.
Поиск с фильтром по категории работает и всегда отдаёт k результатов нужной категории; архивные страницы по умолчанию не попадают в выдачу; поиск отвечает быстрее секунды.
Повторный запуск загрузки не создаёт дубликатов; изменённая страница заменяет свои чанки.
Тест фильтра проходит офлайн; .env, index.db, raw/ не в git, kb/ — в git.

Тест для самопроверки

Вопрос 1

Зачем векторная БД, если numpy ищет по 5000 векторам за миллисекунды?

Ради хранения на диске, метаданных и фильтров, обновления отдельных документов, транзакций и масштабирования (ANN) — а не ради скорости на малом объёме.

Вопрос 2

Что такое HNSW и какова цена ANN-поиска?

Граф ближайших соседей в несколько уровней, по которому поиск идёт жадно. Цена — приближённость: recall меньше 100%, плюс память на граф и сложности с фильтрами.

Вопрос 3

В чём проблема post-filtering на примере «найти чанки только из категории warranty»?

Если сначала взять top-10 по всей базе, а потом отфильтровать warranty, среди десяти может не оказаться ни одного чанка про гарантию (все места займут многочисленные карточки товаров), хотя они есть в базе: результат пустой или неполный. Нужен фильтр внутри/до поиска или больший k.

Вопрос 4

В sqlite-vec результат KNN содержит distance. Как сортировать, чтобы самые похожие были первыми?

a) по убыванию
b) по возрастанию
c) неважно
d) по rowid

b) по возрастанию: это расстояние, меньше — ближе.

Вопрос 5

Как сделать загрузку идемпотентной?

Детерминированный ключ чанка из его содержимого (sha256(url + section + text)) с UNIQUE и ON CONFLICT DO NOTHING, плюс пропуск страниц с неизменным хэшем.

Вопрос 6

Что не так в этой функции генерации ключа чанка?

1
def chunk_key(chunk):
2
    return f"{chunk['url']}-{uuid.uuid4()}"

uuid4() случаен: каждый запуск даёт новый ключ, и UNIQUE никогда не срабатывает — каждый прогон дублирует все чанки. Ключ должен зависеть только от содержимого.

Вопрос 7

Зачем хранить doc_hash страницы отдельно от chunk_key?

Чтобы целиком пропускать неизменённые страницы (без chunking и эмбеддингов) и понимать, что страница изменилась и её старые чанки надо удалить.

Вопрос 8

Когда стоит выбрать pgvector, а не sqlite-vec?

a) всегда
b) когда в проекте уже есть Postgres и нужны векторы рядом с бизнес-данными
c) когда векторов меньше 1000
d) когда нет интернета

b).

Вопрос 9

Почему у чанков страницы kb/returns.md нужна ссылка с якорем, а не просто путь к файлу?

returns.md — длинная страница со многими разделами; без якоря ссылка в ответе ведёт в начало файла, и проверить утверждение (например, про вскрытый чай) невозможно.

Вопрос 10

Почему удаление старых чанков и вставка новых для одной страницы должны идти в одной транзакции?

Иначе сбой посередине оставит страницу без чанков или с дублями старой и новой версии, а vec_chunks разойдётся с chunks (осиротевшие векторы).

Вопрос 11

Что вероятнее всего занимает больше времени в поиске на нашем индексе: SQL-запрос KNN или эмбеддинг вопроса через API?

Эмбеддинг вопроса через API (сетевой запрос, десятки-сотни мс); точный KNN по нескольким тысячам векторов в SQLite — миллисекунды. С локальной Ollama сети нет, и эмбеддинг загруженной моделью обычно быстрее облачного, но всё равно, как правило, дольше KNN — нужно измерить.

Вопрос 12

После перехода с облачных эмбеддингов на Ollama bge-m3 схема осталась embedding float[1536]. Что произойдёт и как правильно выбрать размерность?

Вставка упадёт с ошибкой несовпадения размерности: у bge-m3 1024 измерения. Размерность берут из реального вектора (len(embed(["test"])[0])), а при смене модели индекс перестраивают целиком.

Вопрос 13

Первый search.py после перерыва отвечает 3 секунды, следующие — 80 мс. Что происходит и как это исправить в Ollama?

Ollama выгрузила модель из памяти, и первый запрос включает её загрузку (видно по load_duration). Модель держат загруженной через keep_alive и прогревают одним запросом при старте; в замерах прогрев отделяют.

Вопрос 14

Почему для ingest.py в нашем стеке не нужен ключ DeepSeek?

a) DeepSeek бесплатный
b) у DeepSeek нет эндпоинта эмбеддингов, а индексации нужны только эмбеддинги — они локальные
c) ключ берётся из Ollama
d) DeepSeek сам строит индекс

b). Генерация в ingest.py не участвует, а эмбеддинги делает Ollama или Sentence Transformers локально.

Что дальше

Индекс готов, и у нас есть базовая точка качества. Неделя 5 начинается с 5.1 · Переформулировка запроса и метаданные: учим систему понимать вопросы так, как их задают клиенты, и автоматически ставить фильтр по категории.