ИИ в Яндексе: как разработчику собрать AI search по итогам июля

Июльские запуски Яндекса выглядят как набор разных новостей: Alice AI отвечает на звонки, понимает видео с камеры, строит прогулочные маршруты, помогает писать код и готовится выполнять офисные процессы. Но с инженерной точки зрения это один переход — от модели, которая генерирует ответ, к системе, которая находит данные, удерживает контекст и совершает проверяемое действие.

Именно так меняется AI search. Пользователь больше не хочет получать десять ссылок и самостоятельно собирать из них решение. Он ожидает ответ с источниками, возможность уточнить вопрос и, если задача допускает, выполнить следующий шаг: забронировать столик, построить маршрут или подготовить документ.

Разберём, что показал официальный дайджест «ИИ в Яндексе: главное за июль», и превратим продуктовые новости в архитектуру, которую можно использовать в собственном поиске.

Главный итог июля: поиск заканчивается не ответом

Классический поиск оптимизирует список документов. AI search должен оптимизировать завершение пользовательской задачи.

ИИ-хостес Яндекса не просто находит расписание ресторана. Он ведёт голосовой диалог, уточняет дату и число гостей, проверяет слот, предлагает альтернативу и оформляет бронирование. По данным Яндекса, во время тестов агент успешно обработал запрос в 99% случаев, а у отдельных партнёров число бронирований выросло на 23%.

Прогулочные маршруты в Яндекс Картах работают по похожей схеме: система находит интересные места, связывает их в физически выполнимый маршрут и создаёт описание с аудиогидом. В июле было доступно более 400 маршрутов в 36 городах.

Alice AI VLM добавляет ещё один тип поиска — по содержимому видео. Запрос «не сидел ли кот на столе» превращается не в поиск по имени файла, а в семантическое извлечение событий из архива.

Современный AI search — это не LLM поверх поисковой строки. Это цепочка: понять намерение → найти доказательства → собрать ответ → проверить ограничения → выполнить разрешённое действие.

Четыре слоя AI search

Большинство неудачных AI-поисков пытается сделать все четыре слоя одним Prompt. В результате невозможно понять, где возникла ошибка: источник не найден, контекст собран плохо или модель придумала связь между фактами.

Шаг 1. Ограничьте пространство задач

Фраза «поиск по корпоративным данным» слишком широка. Начните с нескольких типов запросов, для которых можно определить правильный результат.

Например, внутренний AI search может поддерживать:

· поиск точной инструкции или владельца процесса;

· сравнение двух версий документа;

· ответ на вопрос с обязательными цитатами;

· поиск похожего инцидента;

· подготовку действия без его автоматического выполнения.

Для каждого класса задайте отдельный критерий. Точный факт проверяется по источнику, сравнение — по полноте различий, а действие — по корректности заполненных параметров.

Шаг 2. Отделите Retrieval от генерации

LLM не должна вспоминать корпоративные данные из параметров модели. Сначала поисковый слой возвращает небольшой набор документов, затем генератор работает только с ними.

Практический конвейер выглядит так:

1. нормализовать запрос и извлечь фильтры;

2. выполнить лексический и семантический поиск;

3. объединить результаты и удалить дубликаты;

4. переранжировать кандидатов;

5. передать модели только верхние фрагменты вместе с идентификаторами источников.

Гибридный поиск обычно надёжнее чистого Vector Search. Семантика хорошо находит близкий смысл, но точные артикулы, названия методов, номера договоров и коды ошибок лучше сохраняет лексический индекс.

Шаг 3. Заставьте ответ ссылаться на доказательства

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

{
  "answer": "Краткий ответ пользователю",
  "citations": ["doc_17", "doc_42"],
  "confidence": "high",
  "needs_clarification": false
}

После ответа приложение проверяет, существуют ли указанные документы и действительно ли они содержат подтверждение. Ссылка сама по себе не делает ответ достоверным: модель способна сослаться на релевантный документ, который не подтверждает конкретное утверждение.

Минимальный запрос к модели через API

Ниже — упрощённый Python-пример. Retrieval уже вернул три фрагмента, а модель должна ответить только на их основе. В OdiRouter.ai генератор можно менять без переписывания поискового слоя.

import json
import os
import urllib.request

documents = [
    {
        "id": "doc_17",
        "title": "Регламент возвратов",
        "text": "Возврат оформляется в течение 14 календарных дней..."
    },
    {
        "id": "doc_42",
        "title": "Исключения для цифровых товаров",
        "text": "После активации цифровой лицензии стандартный возврат..."
    }
]

payload = {
    "model": "gpt-5.6-luna",
    "messages": [
        {
            "role": "system",
            "content": (
                "Отвечай только по переданным источникам. "
                "Если данных недостаточно, запроси уточнение. "
                "Для каждого вывода верни ID подтверждающего документа."
            )
        },
        {
            "role": "user",
            "content": json.dumps({
                "question": "Можно ли вернуть активированную лицензию?",
                "sources": documents
            }, ensure_ascii=False)
        }
    ],
    "response_format": {"type": "json_object"}
}

request = urllib.request.Request(
    "https://api.odirouter.ai/v1/chat/completions",
    data=json.dumps(payload).encode("utf-8"),
    headers={
        "Authorization": f"Bearer {os.environ['ODIROUTER_API_KEY']}",
        "Content-Type": "application/json"
    },
    method="POST"
)

with urllib.request.urlopen(request, timeout=60) as response:
    result = json.load(response)
    print(result["choices"][0]["message"]["content"])

Model ID приведён как пример. Для production нужно проверить поддержку структурированного вывода у выбранного маршрута и валидировать ответ на стороне приложения.

Шаг 4. Добавьте диалог, но не превращайте историю в мусор

В Поиске с Алисой AI пользователь может перейти от результата к уточняющему диалогу. Для собственного AI search это означает, что система должна различать:

· новый запрос;

· уточнение предыдущего объекта;

· изменение одного фильтра;

· переход к другой задаче.

Не нужно отправлять модели всю историю сессии. Храните структурированное состояние: текущий объект, фильтры, выбранные источники и нерешённые вопросы. Полный диалог можно использовать для аудита, но рабочий контекст должен оставаться коротким и предсказуемым.

Шаг 5. От ответа к действию — только через отдельный контракт

ИИ-хостес показывает, почему Agent нельзя строить как продолжение текста. Чтобы оформить бронирование, недостаточно сгенерировать фразу «столик забронирован». Нужно вызвать систему расписания и получить подтверждение.

Полезно разделить инструменты на три класса:

Такой подход совпадает с логикой анонсированного Yandex B2B Tech универсального агента: доступ можно ограничивать, важные действия подтверждает человек, а цепочка решений и использованных инструментов остаётся доступной для анализа.

Мультимодальный поиск: сначала создайте индекс событий

Alice AI VLM позволяет искать события в архиве умной камеры естественным языком. Наивная реализация такого продукта отправляла бы модели всё видео при каждом запросе. Это дорого и медленно.

Практичнее обработать поток заранее:

6. разделить видео на события или временные окна;

7. создать текстовые описания и Embedding;

8. сохранить время, объект, действие и степень уверенности;

9. искать по индексу, а исходный фрагмент открывать только для проверки.

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

Что программа 75/75/75 говорит о разработке AI search

В июле Яндекс объявил программу 75/75/75: к концу 2026 года не менее 75% разработчиков должны регулярно использовать AI, он должен участвовать минимум в 75% изменений и генерировать не менее 75% кода внутри таких изменений.

Самая полезная часть новости — не проценты. Яндекс отдельно подчёркивает, что архитектурные решения, проверка качества и ответственность остаются у разработчиков. AI даёт эффект, когда встроен в процесс: помогает писать код, тесты и документацию, но не подменяет критерии приёмки.

Для команды AI search это означает:

· использовать coding agent для создания адаптеров и тестов;

· генерировать Eval Fixtures вместе с реализацией;

· проверять Retrieval отдельно от ответа модели;

· не принимать LLM Judge за единственный источник истины;

· хранить архитектурные решения в репозитории, а не только в истории чата.

Безопасность Alice AI: что на самом деле означает ISO/IEC 42001

В июле модели Alice AI LLM, Alice AI VLM и Alice AI ART прошли аудит процессов по стандарту ISO/IEC 42001. Для разработчика важна точная интерпретация: сертификат оценивает систему управления созданием и внедрением AI, а не гарантирует, что каждый ответ модели фактически верен или безопасен.

Даже сертифицированная модель требует:

· фильтрации чувствительных данных;

· проверки источников;

· контроля Tool Calls;

· мониторинга ошибок и дрейфа качества;

· версии Prompt, модели и политики в каждом Trace.

Где в архитектуре нужен мультимодельный API

Yandex AI Studio логично выбирать командам, которые строят продукт внутри экосистемы Alice AI и Yandex Cloud. Мультимодельный слой полезен, когда нужно сравнить несколько семейств, подготовить резервный маршрут или разделить задачи по цене и сложности.

Через OdiRouter.ai можно использовать 200+ моделей через единый API. Например, быстрая модель классифицирует запрос, сильная синтезирует сложный ответ, а модель другого семейства проверяет критичный результат.

При этом Retrieval, права доступа, источники и бизнес-действия должны оставаться в приложении. Смена модели не должна менять политику безопасности поиска.

Метрики AI search, которые действительно нужны

Общая оценка «ответ понравился» не позволяет понять, что улучшать. Если Retrieval не нашёл документ, замена модели не исправит систему.

Production-чеклист

10. Определены поддерживаемые типы запросов.

11. Retrieval тестируется независимо от LLM.

12. Каждое утверждение может быть связано с источником.

13. Система умеет запросить уточнение.

14. Read и Commit-инструменты имеют разные права.

15. Необратимые действия подтверждаются.

16. Диалог хранится как структурированное состояние.

17. Внешний контент считается недоверенным.

18. Есть резервный модельный маршрут.

19. Качество измеряется на реальных запросах.

Вывод

Июльские обновления показывают, что ИИ в Яндексе развивается не как отдельный чат. Alice AI становится слоем поиска, зрения, голоса и действия, а Yandex AI — частью инженерных и корпоративных процессов.

Для разработчика главный урок прост: AI search нельзя построить одной моделью. Нужны хороший Retrieval, ссылки на доказательства, структурированная память, ограниченные инструменты и измеримый критерий завершённой задачи.

Модель отвечает за интерпретацию и синтез. Поисковый индекс отвечает за факты. Приложение отвечает за права и действия. Только при таком разделении AI search перестаёт быть красивым ответом и становится надёжной функцией продукта.