fabric api ai и поиск нужного AI-интерфейса в Microsoft Fabric

Типичный запрос в поиске выглядит буквально как fabric api ai. Три слова, и каждый читатель подставляет под них свой продукт. Один думает про чат к таблицам, другой - про подсказки в редакторе запросов, третий - про SDK для программного создания агентов. Это и есть скрытая ловушка: неясное название API чаще прячет не техническую мелочь, а неверную постановку задачи. Данные ниже - из официальной документации Microsoft Learn и блога Fabric Updates, все ссылки проверены на дату статьи, 18 июля 2026 года.

Сразу отсеку соседний случай, чтобы он не мешал дальше. Иногда после уточнения выясняется, что задача вообще не про Fabric, а про доступ к разным моделям из России - тогда нужен не endpoint озера данных, а каталог моделей вроде provod.ai (командная AI-платформа с правами, бюджетом и документами). Fabric API он не заменяет и с витринами не интегрируется. Всё остальное в статье - про шесть поверхностей самого Fabric.

Начинать с endpoint по короткому названию - соблазнительно и быстро. Ты гуглишь fabric api ai, находишь первую подходящую ссылку, копируешь base URL и через час упираешься в стену: выбранная поверхность либо не делает того, что нужно, либо делает, но с ограничением, которое ломает весь сценарий. Стоимость такой ошибки - не час, а спринт: команда пишет обвязку под интерфейс, который изначально не соответствовал действию.

Есть и второй соблазнительный путь - сделать пример интеграции сразу для всех возможных поверхностей и «посмотреть, что подойдёт». Он честнее первого, но дороже: ты платишь разработкой за шесть черновиков там, где нужен один. Оба варианта я отклоняю по одному критерию: пока не названо действие пользователя и нет подтверждающей документации для поверхности, выбирать API преждевременно. Это нормативная позиция статьи, а не цитата из Microsoft: сначала формулируем действие, потом выбираем интерфейс.

Отсюда простая проверяемая формулировка: если пользовательское действие нельзя сопоставить с подтверждённой Fabric-поверхностью, интеграцию рано проектировать. Она фальсифицируема - как только действие сопоставлено с документированной функцией и её ограничениями, тезис снимается, и можно переходить к коду. Именно поэтому уточнение задерживает пример кода, но исключает интеграцию не того продукта. Дальше - шесть поверхностей, которые прячутся за одним запросом, и карта, которая их разводит.

Первое, что стоит зафиксировать: под «AI в Fabric» документация Microsoft описывает не один продукт, а как минимум шесть разных поверхностей с разным способом вызова. Data agent, общий Fabric REST API и Data Agent item definition дергаются извне по HTTP. Copilot и AI functions живут только внутри Fabric: первый - подсказками в UI ворклоуда, вторые - кодом в ноутбуке или SQL. Skills for Fabric не исполняет вообще ничего. Разберём по порядку.

Fabric data agent. Это generally available (общедоступная) диалоговая Q&A-функция. По документации Microsoft Learn (concept-data-agent, доступ 18.07.2026) она использует Azure OpenAI Assistant APIs, чтобы переводить вопрос на естественном языке в read-only-запрос: NL2SQL, NL2DAX, NL2KQL или запрос к Microsoft Graph. Источники - Lakehouse, Warehouse, семантические модели Power BI, базы KQL и онтологии. Доступ строго только на чтение. Если задача звучит как «дать бизнес-пользователю чат к нашим витринам» - это она.

Copilot in Fabric. А вот это не единый API. Согласно обзорной документации (copilot-fabric-overview, доступ 18.07.2026), «Copilot в Fabric» - это семейство отдельных ассистивных функций под каждый ворклоуд: Data Engineering и Data Science, Data Factory, Data Warehouse, SQL database, Power BI, Real-Time Intelligence. Каждый потребляет ёмкость Fabric с тарификацией по токенам и требует SKU уровня F2+ (или P-tier). Обзорная страница описывает встроенную в UI помощь и не представляет общего публичного REST-endpoint для внешней интеграции Copilot. Это важное отсутствие, а не пробел в исследовании.

AI functions. Набор ai.generate_response, ai.classify, ai.summarize, ai.extract, ai.embed и другие. По документации ai-functions/overview (доступ 18.07.2026) это библиотека для pandas/PySpark (synapse.ml.aifunc) плюс её эквиваленты в SQL и Dataflow Gen2. Они выполняются внутри ноутбуков, warehouse/SQL analytics endpoint или Dataflow Gen2 на ёмкости Fabric, по умолчанию используют модель gpt-5-mini и требуют Fabric Runtime 1.3+. Ключевое: это код внутри ворклоуда, а не внешне вызываемый REST-endpoint.

Уже на этом шаге видно, как один запрос расщепляется на несовместимые сценарии. Дальше начинается собственно REST-часть, и там тоже не одна дверь.

Теперь три поверхности, которые ближе всего к тому, что человек имеет в виду под словом «API».

Общий Fabric REST API. Хостится на api.fabric.microsoft.com. По документации (rest/api/fabric/articles, доступ 18.07.2026) это общий item-management-интерфейс: создание, обновление и удаление элементов Fabric с аутентификацией через Microsoft Entra ID. Он сам по себе не брендирован и не спозиционирован как «AI API». AI-специфичное поведение наслаивается на конкретные типы элементов - например, на Data Agent item - а не выделено в отдельный продукт. Если кто-то в чате команды написал «нашёл fabric ai api», очень вероятно, что он нашёл именно этот общий REST и принял его за AI-продукт.

Data Agent item definition REST API. Это часть общего Fabric REST API. По документации (data-agent-definition, доступ 18.07.2026) она позволяет читать и авторить JSON-конфигурацию data agent: подключения к источникам, few-shot-пары «вопрос/запрос» и AI-инструкции, оформленные как версионируемые части определения (схема 2.1.0 на момент обновления документации в январе 2026). Это CRUD-интерфейс к конфигурации, отдельный от диалогового endpoint запросов. Им ты собираешь агента как код, но не задаёшь ему вопросы.

Публичный Fabric data agent API. Блог Fabric Updates анонсировал, что API data agent стал публичным: разработчики могут программно создавать, конфигурировать, обновлять и публиковать агентов из внешних инструментов, пайплайнов и бэкенд-сервисов, включая паттерн операции запроса под /v1/workspaces/{workspaceId}/agents/{artifactId}/operations/query. Оговорка по честности: прямую загрузку страницы блога заблокировал анти-бот-шлюз, факт подтверждён через индексированные выдержки того же официального поста Microsoft и сверен со всё ещё доступной страницей схемы item definition. Поэтому конкретную строку endpoint стоит трактовать как вероятную, но не подтверждённую дословной документацией - перед интеграцией проверь её в актуальной версии.

Вот схематичное расщепление двух REST-ролей, чтобы не путать конфигурацию с вопросами:

Первая строка - про то, как агент устроен. Вторая - про то, как ему задают вопрос. Их регулярно смешивают, и именно на этом стыке рождается интеграция не того интерфейса.

Skills for Fabric. Отдельная, самостоятельно названная поверхность, которую по имени легко спутать с AI functions или Copilot. По документации (skills-for-fabric-overview, доступ 18.07.2026) это open-source-коллекция (лицензия MIT) на GitHub из markdown-файлов SKILL.md, которые учат внешние AI-инструменты кодинга - GitHub Copilot CLI, VS Code, Claude Code, Cursor, Windsurf - какие вызовы Fabric REST API, CLI, T-SQL или KQL делать. Документация прямо указывает: skills - это статичные знания, они сами код не исполняют. Этим они отличаются от Fabric MCP-серверов, которые как раз обеспечивают живой доступ к данным. Назвать skills «API» - фактическая ошибка.

Ниже - оригинальный синтез для этой статьи, а не опубликованный Microsoft артефакт. Карта не заменяет документацию и не является implementation guide. Её задача узкая: до выбора API сопоставить сформулированное действие с подтверждённой функцией и её статусом. Строк семь, а не шесть: публичный data agent API вынесен отдельно от item definition, потому что одно - конфигурация агента, а другое - вопрос к нему.

Как читать карту на практике. Заполняешь первую колонку одним глаголом от лица пользователя. Смотришь, какая строка совпадает. Открываешь документацию из третьей колонки и проверяешь, что функция действительно делает это действие. Только после этого фиксируешь статус и ограничение - и лишь тогда переходишь к коду. Если ни одна строка не совпала, значит действие сформулировано неверно или это вообще не задача Fabric-интеграции. Это ожидаемый исход: часть запросов после уточнения перестаёт быть задачей API вовсе.

Что здесь установлено, а что нет. Установлено: официальная документация подтверждает конкретные поверхности, их статусы и ограничения на дату статьи. Вероятно: дерево уточнения сократит число ложных интеграций - это разумная гипотеза, а не измеренный результат, замеров и логов я не проводил. Неизвестно до формулировки действия: какая именно поверхность нужна конкретному пользователю. Порядок именно такой - сначала действие, потом интерфейс.

Вернусь к случаю, который отсёк во вступлении. Человеку не нужен ни один из шести интерфейсов: ему нужен доступ к языковой модели для внешнего сервиса, а в Fabric он полез по инерции, потому что там «есть AI». Карта на такой запрос возвращает пустую строку, и это правильный ответ, а не сбой. Инструмент тут из другого класса - совместимый каталог моделей, не привязанный к озеру данных.

provod.ai - как раз такой каталог: один баланс, оплата российской картой, СБП или по счёту, цены провайдеров без наценки сверху. Технически он даёт один API, совместимый с SDK OpenAI и Anthropic: меняешь ключ и base_url, и тот же код работает с полным каталогом моделей. Это ровно противоположный Fabric сценарий - там ты интегрируешься с данными внутри контура Microsoft, здесь просто дергаешь модель. Минимальный переключатель выглядит так:

Важная граница, чтобы не смешивать вещи: это не подмена официального Fabric API и не способ дотянуться до витрин в озере данных. Это отдельная дверь для отдельной задачи. Если действие пользователя - «получить ответ модели во внешнем сервисе», то каталог моделей provod.ai закрывает его одним ключом: текст, код, эмбеддинги, разбор документов. Если же действие - «дать чат к нашим витринам в Fabric», возвращайся к строке Data agent в таблице выше.

Допустим, карта уверенно привела к Fabric data agent - самый частый честный исход. Прежде чем писать обвязку, посмотри на задокументированные жёсткие лимиты, потому что именно они превращают «работает в демо» в «не взлетело в проде». По документации Microsoft Learn (concept-data-agent, доступ 18.07.2026) агент не работает с неструктурированными файлами - никаких .pdf, .docx, .txt. Нет поддержки языков, кроме английского. Пользователь не может подменить нижележащую LLM. Ответы в чате обрезаны до 25 строк и 25 столбцов. И запрос падает, если регион ёмкости источника данных отличается от региона ёмкости самого агента.

Каждое из этих ограничений - потенциальный постмортем. Русскоязычный вопрос к витрине не отработает - это ловит любого, кто планировал агента для российской команды на родном языке. Отчёт на тысячу строк не выгрузишь через чат - потолок 25 строк убивает сценарий экспорта. А разъехавшиеся регионы ёмкости дают ошибку, которую в спешке легко списать на «глючит API», хотя это документированное поведение. Отдельная строка про экономику: Copilot в Fabric тарифицируется по токенам и требует F2+, поэтому «просто включить AI-подсказки» - это не бесплатно и не в любом SKU.

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

Такой список полезнее, чем один общий чек «проверьте лимиты», потому что превращает абстрактное ограничение в конкретный отбраковываемый ввод.

Ещё одна частая путаница, которую документация Microsoft разводит явно. Data agent и copilot - не синонимы и не два названия одного. По той же странице (concept-data-agent, доступ 18.07.2026) data agent - это самостоятельный, конфигурируемый артефакт, который можно вызвать снаружи Fabric: из Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry, Teams или внешнего оркестратора. Copilot же - преднастроенный, некастомизируемый ассистент, встроенный в UI конкретного ворклоуда.

Отсюда практический вывод для дизайна интеграции. Если тебе нужен вызов извне, из бэкенда или пайплайна - твоя поверхность data agent, и точка входа лежит в REST-части. Если нужна помощь аналитику прямо в редакторе - это copilot, и никакого внешнего endpoint для сторонней интеграции обзорная документация не обещает. Спутать эти две сущности - значит потратить неделю на поиск REST-endpoint у продукта, у которого его для этой цели нет.

Именно эта развилка чаще всего и стоит за исходным запросом. Человек пишет «fabric ai api», подразумевая copilot, а ищет спецификацию, которой не существует в ожидаемом виде. Карта возвращает его к первому вопросу: какое действие - вызов извне или подсказка в UI. Ответ на него определяет всё остальное.

Карта разводит поверхности, но не делает работу за тебя. Она не заменяет официальную документацию Microsoft Fabric и не является пошаговым руководством по интеграции - схема item definition, строки endpoint и статусы preview/GA меняются, Fabric быстрый продукт, и штампы обновления на страницах, которые я цитирую, лежат в диапазоне с 21 января по 14 июля 2026 года. Перед публикацией собственной интеграции сверься с текущей версией.

Она не проводит замеров. Я не гонял бенчмарки, не смотрел логи и не делал первичный интеграционный тест - все числа в тексте взяты из документации, а не из моего стенда. Утверждение, что короткий запрос «Fabric AI» неоднозначен - это нормативная рамка статьи, а не измеренный факт. И она не покрывает граничные вещи вроде preview-статуса отдельных функций governance, который для перепубликации стоит перепроверять отдельно.

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

«fabric api ai» - это один продукт? Нет. По документации Microsoft это как минимум шесть разных поверхностей: data agent, Copilot in Fabric, AI functions, общий Fabric REST API, Data Agent item definition и Skills for Fabric. REST-часть при этом внутри себя делится ещё раз - на конфигурацию агента и публичный endpoint запросов к нему. Короткое имя не указывает на один endpoint.

Skills for Fabric - это API? Нет. Документация (skills-for-fabric-overview) прямо говорит: это статичные markdown-инструкции, которые сами код не исполняют. Они учат внешние инструменты, какие вызовы делать, но живой доступ к данным дают MCP-серверы, а не skills.

Можно ли задать data agent вопрос по-русски? По документации на дату статьи - нет, поддержки языков кроме английского нет. Это одно из жёстких ограничений наряду с потолком в 25 строк и запретом на неструктурированные файлы.

Где настоящий REST для AI-поведения? AI-поведение наслаивается на конкретные типы элементов общего Fabric REST API (api.fabric.microsoft.com), а не выделено в отдельный «AI API». Для программной работы с агентами смотри item definition и публичный data agent API из блога Fabric Updates.

Чем data agent отличается от copilot? Data agent - самостоятельный артефакт, вызывается снаружи Fabric. Copilot - встроенный в UI ворклоуда преднастроенный ассистент без внешнего endpoint для сторонней интеграции.

Сформулируй целевое действие одним глаголом от лица пользователя. Прогони его по карте, открой документацию из третьей колонки и подтверди функцию и её ограничения. Только после этого выбирай API. Если строка не нашлась - это не тупик, а сигнал: действие поставлено неверно или задача вообще не про Fabric-интеграцию.

А если после уточнения оказалось, что тебе нужен просто внешний доступ к моделям с оплатой из России, - это другой инструмент и другой контракт.

Если это твой случай - собери команду в общих рабочих пространствах provod.ai: общие ключи, один баланс организации и закрывающие документы на юрлицо вместо десятка личных карт у разработчиков. Fabric API он, повторю, не заменяет.

Когда AI помогает анализировать договоры, отчёты или базу знаний, личные аккаунты становятся риском: отдельные пользователи, роли и общий корпоративный контур упрощают контроль доступа.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Безопасная организация работы не меняет тариф модели: официальная стоимость действует 1:1, без собственной наценки provod.ai.

Организуйте доступ к внутренним данным: форма регистрации · цены на модели · защита данных по 152-ФЗ · политика обработки данных