Retrieval-augmented generation на Apple Silicon — это в первую очередь стабильный ingest: границы чанков, размер батча относительно unified memory и то, куда на диске реально пишутся векторы. Эта заметка — компактная матрица решений, которую можно держать рядом с индексатором.

Предполагается, что вы уже разделяете офлайн-индексацию и онлайн-запросы. Типичные сбои, съедающие выходные: взрыв RAM на этапе эмбеддингов, путаница с путями после перезагрузки и тихая регрессия при смене размера чанка без зафиксированного eval-набора. Свяжите этот гайд с материалами про OpenClaw и автоматизацию (шлюзы, зеркала, ночные джобы), загляните на главную за контекстом платформы; страницы покупки — общий каталог, регионы: Гонконг, Сингапур, Токио, Сеул, восток США, запад США — пригодятся, если нужен выделенный удалённый Mac вместо ноутбука для ночной перестройки индекса.

Сценарии

Приватный код и тикеты. Важнее детерминированные границы секций (функции, заголовки), чем один большой токен-окно. Имеет смысл структурно-ориентированный сплит с умеренным перекрытием, чтобы диффы не рвали retrieval.

PDF и смешанный OCR. Часто выигрывают фиксированные символьные окна; перекрытие страхует от ответов на стыке строк таблиц. Ожидайте больший разброс recall — eval-harness лучше заложить сразу.

Высокий QPS чата над статическим корпусом. Укорачивайте текст чанка, ужесточайте фильтры по метаданным, выносите стоимость батчинга в индексатор, чтобы p95 запроса не плыл. На Apple Silicon обычно выгоднее ровные средние батчи, чем микробатчи, недозагружающие ускоритель.

Многоязычные или юридические корпуса. Выровняйте чанкинг с тем же токенизатором, что у эмбеддера: смесь CJK и латиницы может сдвинуть эффективное число токенов на десятки процентов. Если нужно точечно удалять данные клиента, заранее продумайте ID чанков и схему персистентности для tombstone без полной пересборки HNSW.

Подготовка данных

Нормализуйте пробелы, уберите повторяющиеся колонтитулы и до эмбеддинга сохраните в метаданных путь к источнику + смещение в байтах или номер страницы. Для перекрытия в 2026 году на Mac разумная отправная точка для прозы — 10–20% длины чанка; для техдоков при размере чанка 512–1024 токенов — фиксированные 64–128 токенов. Увеличивайте overlap, если ответы часто «сидят» на границе чанков; уменьшайте, если избыточность портит реранкер.

Выбор между окнами с учётом предложений (лучше связность, медленнее препроцессинг) и фиксированными символьными окнами (предсказуемый throughput). Гибрид: Markdown — по предложениям, PDF — фиксированное окно. Любой вариант фиксируйте версией препроцессора рядом со снимком векторов, чтобы отличать регрессии от догадок.

Прокиньте параметры через переменные окружения — так CI и удалённые джобы останутся воспроизводимыми:

export RAG_CHUNK_SIZE=768 export RAG_CHUNK_OVERLAP=96 export RAG_EMBED_BATCH=24 export RAG_MAX_CHARS_PER_CHUNK=3200

Минимальный CLI-вызов (подставьте свой модуль) упрощает аудит:

python -m app.rag_index \ --chunk-size "${RAG_CHUNK_SIZE}" \ --overlap "${RAG_CHUNK_OVERLAP}" \ --embed-batch "${RAG_EMBED_BATCH}" \ --persist-dir "${RAG_VECTOR_DIR}"

Сравнение векторных хранилищ

Таблица ниже — эвристическая матрица для локально-ориентированных пайплайнов на Mac с 16–64 ГБ unified memory. Пики памяти — порядок величины: они масштабируются с батчем, размерностью эмбеддинга и тем, держите ли сырой текст в RAM.

Профиль Перекрытие чанков Батч эмбеддинга Пик RAM индексатора (ориентир) Квоты / ограничения Путь персистентности
Встроенный SQLite / файл Низкое (5–12%) → меньше строк 8–16 2–6 ГБ + модель Один файл БД; лимит по числу строк / PRAGMA page_size ~/Library/Application Support/yourapp/rag/sqlite_vec.db
Chroma (persistent client) Среднее; дедуп ID чанков 16–32 4–10 ГБ + модель Сегменты коллекции; следите за inode и % диска ~/Library/Application Support/yourapp/chroma
LanceDB (колоночное) Гибко для крупных корпусов 24–48 6–14 ГБ + модель Шардирование по таблице; compaction после массового upsert ~/Library/Application Support/yourapp/lancedb
Qdrant (localhost) Настройка + payload-фильтры 32–64 8–18 ГБ с учётом демона max_collection_size / watermark диска в конфиге Docker volume или /usr/local/var/qdrant

Дисциплина квот: ограничьте коллекцию макс. числом документов и байтами на диске; перед разрушающей переиндексацией снимите snapshot каталога персистентности. На macOS держите данные под ~/Library/Application Support или на отдельном томе APFS, чтобы Time Machine и удалённый rsync имели один корень.

export RAG_VECTOR_DIR="$HOME/Library/Application Support/yourapp/vectors" export CHROMA_TELEMETRY_DISABLED=1 export OMP_NUM_THREADS=8

Оценка и регрессия

Зафиксируйте золотой набор вопросов (30–100 пунктов) с ожидаемыми ссылками на источники. При смене чанкинга или эмбеддингов перезапускайте: hit@k, MRR (если есть разметка), латентность p95 на том же классе машин. В артефакт eval пишите хеш токенизатора, ревизию модели и параметры чанков.

Чек-лист приёмки длительной удалённой задачи (индексация на арендованном Mac или CI-агенте):

  • Префлайт: квота диска ≥ 2× (корпус + векторный след); в лог джоба — вывод df -h и ulimit -n.
  • Детерминизм: закреплённый lockfile зависимостей; контрольная сумма модели эмбеддингов; фиксированный RAG_SEED, если в стеке есть сэмплирование.
  • Возобновление: идемпотентные ID чанков; после сбоя checkpoint-файл под RAG_VECTOR_DIR.
  • Телеметрия: wall time, строк/сек, пик RSS через /usr/bin/time -l (macOS) или сэмплирующий профайлер.
  • Критерии выхода: метрики в согласованной дельте к baseline; ручная проверка пяти «злых» запросов; tarball RAG_VECTOR_DIR с SHA-256 манифеста.

Последний шаг удобно автоматизировать теми же паттернами, что и синхронизацию зависимостей в теме OpenClaw / автоматизация: индексатор должен быть таким же скучным, как ночное зеркалирование.

FAQ

Больший батч всегда ускоряет эмбеддинги? Нет: после порога давление на unified memory вызывает swap. Прогоните батчи {8,16,24,32,48} и выберите «колено», где прирост throughput выравнивается.

Одна векторная БД на всё? Минимум разделите dev/prod. В мультитенантном SaaS — отдельные корни персистентности на арендатора: проще квоты и бэкапы.

Как часто переиндексировать? При смене модели эмбеддингов — обязательно; при смене политики чанков — только если eval показывает чистый выигрыш. Частичная переиндексация лучше полной, если метаданные однозначно мапят ID на источники.

Форсить Metal / Core ML для эмбеддингов? Если рантайм поддерживает — да, но только после проверки побитового или почти побитового совпадения на сотне пробных векторов. Расхождение CPU/GPU без замера численно уже подводило команды.

Параметры ANN-индекса? Считайте ef_construct, M (и аналоги) частью той же матрицы: выше — больше RAM и диска на сборке, ниже — хуже recall. Фиксируйте их в манифесте приёмки рядом с чанками и батчем.

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