SKU Search

• Обычно "," или ";"
• Применяется только в CLI; сам сервис CSV не парсит

• Локальная разработка: "127.0.0.1:8080"
• Production / Docker: "0.0.0.0:8080"
• IPv6: "[::1]:8080"

• Пакетная загрузка (до 500 элементов): 3000-5000 мс
• Интерактивный поиск: 1000-2000 мс

• Рекомендуется: 100-300 для 1С, до 500 для фоновой синхронизации, 1 000-5 000 для массовой первичной загрузки при мощном CPU/SSD.
• При превышении вернется 400 Bad Request.
• Защита от перегрузки CPU и RAM.
• Большой batch требует большего max_request_body_size_mb и соответствующего client_max_body_size в nginx. Подробные замеры и рекомендации — в разделе Производительность массовой загрузки.

• Влияет на лимит тела, который накладывает Axum до разбора JSON
• Должен быть достаточен для max_batch_size с самыми длинными полями (name, supplier, описания и т.п.)
• При превышении вернется 413 Request Entity Too Large
• nginx (или другой reverse proxy) должен иметь не меньший client_max_body_size

• Создается автоматически при старте
• Размещайте на быстром SSD (NVMe предпочтительно)
• Не используйте NFS, SMB — резкое падение производительности

• < 100 000 записей: 50-100 МБ
• 100 000-500 000: 150-250 МБ
• > 500 000: 300-500 МБ
• Больше = реже диск I/O, быстрее массовая загрузка

• 0: только точные совпадения (макс. скорость)
• 1: одна опечатка (рекомендуется для production)
• 2: две опечатки (+10-15% recall, но в 1.5-2 раза медленнее)

• false (по умолчанию): сервис не запустится и сообщит об ошибке SchemaError. Используйте, если потеря индекса недопустима.
• true: старый индекс переименовывается в ./data/index.bak.<timestamp>, создается новый пустой индекс. Сервис продолжит работу, но данные нужно будет загрузить заново.

• 1: включает однобуквенные коды ("М", "А", "Б"), но добавляет шум
• 2: оптимально для номенклатуры (отсекает предлоги, частицы)
• 3: максимальная скорость, если нет значимых коротких кодов

• Критично для точности BM25 и скорости
• Отсекает высокочастотные слова: "упак", "кор", "ящ", "комплект", "набор"
• Рекомендуется: true

• Загружается при старте. Если не найден — используется встроенный набор
• Добавляйте отраслевой шум: "упак", "кор", "ящ", "комплект", "набор"

• Финальный порог вычисляется как max(relative_threshold, max_score × auto_match_threshold), т.е. результат должен быть не хуже доли от максимального скора
• Рекомендуется: 0.85-0.90 для баланса точности/полноты
• Много ложных срабатываний → увеличьте до 0.92
• Ничего не находится → снизьте до 0.75-0.80

• true: оператор может ввести "болт м16 78454" в одно поле — найдется
• false: поиск только по полю name (быстрее, но менее гибко)
• Рекомендуется: true для интеграции с 1С/Excel

• "ghbdtn" → "привет"
• Экспериментальная функция, может давать ложные срабатывания
• Включайте, если пользователи часто забывают переключить раскладку

Результаты с score < (max_score × relative_score_threshold) отфильтровываются.

• 0.50: мягкая фильтрация (default, оставляет 50% от лучшего)
• 0.55: баланс точности/полноты (рекомендуется для production)
• 0.60-0.70: агрессивно, только очень релевантные

Критичные токены — короткие (≤ critical_token_max_length) ИЛИ содержащие цифры.

Захватывает: М16, 42р, XL, 220V, IP67, DIN125 и т.д.

• Включите для "грязных" баз, где важно точное совпадение по коротким кодам
• Отключите, если короткие коды встречаются в каждом товаре (теряете полноту)

• М16 (3 символа) — критичный при значении 4
• DIN125 (5 символов) — НЕ критичный при значении 4
• Увеличьте до 5, если у вас есть значимые 5-символьные коды (DIN125, ГОСТ7798)

Доля токенов запроса, которые должны совпасть в результате.

• 0.5: минимум 50% токенов должны совпасть (рекомендуется)
• 0.7: строже, 70% токенов (меньше ложных срабатываний)
• 0.0: отключить фильтрацию (старое поведение)

• Больше → выше точность, но медленнее
• Меньше → быстрее, но можно пропустить релевантные результаты
• Рекомендуемый диапазон: 2-5

• true: можно искать по supplier, brand, color и т.д.
• false: динамические поля игнорируются

• true: для нечеткого поиска обязательно наличие name (режим совместимости, default)
• false: можно искать ТОЛЬКО по динамическим полям, без указания name (коммерческий режим)

Защита от ситуации, когда все результаты имеют очень низкий score и относительный порог отбрасывает все.

• Рекомендуемое значение: 0.01-0.05
• Не меняйте без крайней необходимости

Защита от экспоненциального роста запросов при сложных поисках.

• Рекомендуемое: 300-1000
• 500 — баланс безопасности и точности
• При превышении — лишние клаузулы отбрасываются с предупреждением

• Если true и name пустой — позволяет добавить/найти товар без названия, отключая стемминг/эмбеддинги для пустого имени.
• Документ индексируется только по ID, code, art и т.п.
• Рекомендация: true для справочников, где название неизвестно при загрузке; false для стандартного каталога.

• Включает точный поиск по реквизитам. Требует больше места на диске.

• "hard" — точный фильтр: в результаты попадают только товары, у которых ВСЕ указанные в запросе extra-поля совпадают точно. Это поведение по умолчанию.
• "soft" — бустирование: совпадение по extra увеличивает скор товара, но не отсекает товары без совпадения. Регулируется весом search.weights.extra_match_boost.
• "off" — игнорировать extra при поиске: поля возвращаются в ответе, но не влияют на выборку и ранжирование.

• Автоматически извлекает ID из строк вида "e1cib/data/...?ref=..." или "{GUID} Название".
• Рекомендация: включайте, если в name часто приходят 1С-ссылки; иначе оставьте false для экономии CPU.

• Обычно используется для артикулов, штрихкодов, внутренних кодов.
• Влияет только на прямой поиск по полю: query.code, query.art, query.barcode. Например, при case_sensitive_fields = ["code"] запрос code="ABC-123" найдет только ABC-123, а code="abc-123" — нет.
• Поиск через общее поле name (unified search) остается регистронезависимым: запрос name="abc-123" найдет товар с code="ABC-123".
• Чтобы регистрозависимость exact-поиска заработала для уже загруженных данных, выполните переиндексацию после изменения этого параметра.

• Поиск по каким дополнительным полям будет РЕГИСТРОЗАВИСИМЫМ при прямом указании в запросе.
• Как и case_sensitive_fields, не влияет на поиск через общее поле name.

• Увеличить (1.2-1.5) → точные совпадения выше в результатах
• Уменьшить (0.8-0.9) → точные совпадения менее важны

• Много опечаток → увеличьте до 0.8-0.85
• Нечеткий поиск часто ошибается → уменьшите до 0.5-0.6

Пример: запрос "болты" ищет "болты" (точное совпадение), а не "болт" (основа).

Формула: score × (1.0 + matched_tokens × coverage_boost_per_token)

• Запрос "болт м16 оцинкованный" (3 слова). Товар содержит все 3 → бонус 3×0.2=+60%
• 0.1 — слабый бонус, 0.2 — баланс, 0.3 — сильный

• Запрос "болт" → "Болт м16" получает бонус
• "Гайка болт" — не получает (начинается с "гайка")
• 1.0 — без бонуса, 1.15 — +15%, 1.3 — +30%

• Поле desc (точное совпадение)
• Точное совпадение по полю desc получает дополнительный бонус

• Текстовый буст через плоские атрибуты

• 0.0 — совпадение по extra не влияет на скор.
• 0.3-0.5 — мягкое приоритезирование: подходящие товары поднимаются выше, но не вытесняют релевантные по названию.
• 1.0-2.0 — сильный буст: товары с совпавшими extra могут оказаться на первых местах даже при менее точном совпадении по name.

• 1: минимальное расширение
• 2: стандартное (рекомендуется)
• 3: максимальное (может давать ложные срабатывания)

• 3: "пер" (короткий), "перф" (обычный)
• 4: "перф" (короткий), "перфо" (обычный)
• 5: "перфо" (короткий)

• 1.0: без буста
• 2.0: умеренный буст
• 4.0: сильный буст (рекомендуется)
• 8.0: экстремальный (только для точных совпадений)

• true: короткие запросы (1-3 слова) → последовательный (точнее), длинные (4+) → булевый (быстрее)
• false: всегда последовательный (максимальная точность)

• 2: быстрый переход на булевый (меньше точности)
• 3: сбалансированный (рекомендуется)
• 5: максимальная точность для длинных запросов (медленнее)

• 2: найдет даже по 2 буквам ("пе" → "перфоратор"), но больше шума
• 3: оптимально для русского языка (рекомендуется)
• 4: только по 4 буквам ("перф" → "перфоратор")

• 5-6: оптимально (баланс)
• 8-10: точнее, но индекс больше
• 15: индекс в 2 раза больше

• Для кодов (tnved, артикулы): 0.8-1.0
• Для названий (бренд, поставщик): 0.5-0.7
• Для характеристик (цвет, размер): 0.3-0.5

• true: "поставщики" найдет "поставщик"
• false: только точное совпадение (для кодов и артикулов)

• true: "Ромашка" найдет "Ромашкаа"
• false: только точное совпадение

• 10: для быстрых ответов
• 30: стандарт (рекомендуется)
• 50-100: для автозапчастей (много аналогов)

• "fs_only": только полнотекстовый поиск (быстро, точно, default)
• "embedding_only": только эмбеддинги (семантический)
• "hybrid": последовательный гибрид
• "parallel": параллельный гибрид (максимальная скорость)

• Преимущество полнотекстового поиска: 0.8 / 0.2
• Сбалансированный (по умолчанию): 0.6 / 0.4
• Преимущество эмбеддингов: 0.4 / 0.6

• "min_max": масштабирование на [0,1] по максимуму.
• "robust": нормализация на 95-й перцентиль, менее чувствительна к выбросам (default).
• "z_score": центрирование на среднем и деление на std, затем масштабирование z-значений на [0,1].
• "softmax": экспоненциальное преобразование, сумма скоров после нормализации = 1.
• "none": не нормализовать, использовать сырые скоры источника.

Режим влияет только на гибридный/параллельный поиск в PRO, когда скоры полнотекстового поиска и эмбеддингов объединяются.

• query_name — исходный запрос пользователя.
• matched_id_out — ID найденного товара.
• action — accept, reject или zero_result.

И опциональные поля для улучшенного анализа:

• product_name, product_art, product_barcode — данные найденного товара.
• matched_by — поле, по которому произошло совпадение (name, code, art, barcode, attrs).
• position — позиция товара в выдаче.
• session_id — ID сессии для анализа реформулировок.
• expected_id — ID товара, который ожидал увидеть пользователь.

Пример:

{
  "query_name": "болт м10",
  "matched_id_out": "ID-001",
  "action": "accept",
  "product_name": "Болт М10х50 DIN 933",
  "matched_by": "name",
  "position": 1
}

curl 'http://localhost:8080/admin/learn?type=synonym'

Типы рекомендаций:

• synonym — предлагаемые синонимы на основе accept-записей.
• missing_product — популярные запросы без результатов (zero_result).
• check_product — товары с высоким reject rate.
• typo — возможные опечатки и альтернативные написания.

Каждая рекомендация содержит recommendation_type, title, description, confidence (0.0–1.0) и data.