Чаму аналітычным AI-агентам патрэбны семантычны пласт, а не сыры SQL
Text-to-SQL па сырых табліцах выдумляе метрыкі і абыходзіць правілы доступу. Семантычны пласт накшталт Cube, дададзены праз MCP, дае AI-агентам кіраваны бізнес-сэнс.
Крыніцы: The Semantic Layer for AI Agents: How to Stop LLMs From Inventing Metrics
Дазволіць агенту з аналізу на базе ШЫ післяваць код SQL — гэта найшырэйшы спосаб зробіць дэман, які вражае людзей. Адночасна гэта і найшырэйшы спосаб стварыць абязы, калі такі SQL запускаецца працоўваць з чыстымі табламі складу без будзь-якага бізнес-кантэксту. Проблемы не выходзяць з сінтаксісу — проблемы ў значэнні.
Возьмімо слова „дохады“ і запытаемся, што яны включаюць:
- Брутто чы ў чыстыя?
- Чы вырахоўваныя ўтрымкі?
- Кальколькі столбца з датамі вялікі за квартал?
- Чы „актыўны кліент“ значыць актыўны момент замовлення чы актыўны сёння?
- Кальколькі карэнтнасць рэгіёнаў прымаецца?
- Кальколькі правіла пераканварэння валюты?
- Чы гэтаму корыстніку воўсе дазволена адразу бачыць даныя таго кліента?
Пры прыеме неапдэтаванага тэксту ў SQL выклікаюцца проблемы самэлькі ў гэтых аспектах. Мадэль можа стварыць правільны SQL, база дадзеных можа яго запрацаваць без працоў, але рэзультаты все равно можу быць некорэктнымі. З гэтай прычыны агенту для аналізу патрэбны сэмантычны слой між ям і бізнес-данымі. Cube ўсё тое ж адлічваны прыклад такога слоя, і ён служыць прыкладам у наступным апісанні.
Схемы не несу значэння
Ідэя перакладу тэксту ў SQL ўсё ж хорашая. Яна дапамагае распрацоўшчыкам, аналітыкам і бізнес-выкарыстоўвальнікам працаваць быстрэй. Але схема складшання дадзеных рэдка калі несе тое значэнне, якое людзі ад яе чакаюць.
У таблыце ёсць столбцы такія як amount, status, created_at, customer_type, region_id і currency, але ніхто ў бізнесе не ставіць запытакі такім спосабам. Ніхто не прасіць пра sum(amount) grouped by region_id where status = 'paid'. Усе прасяць, як вырасілы дохады падпрыемстваў у Паўдэнной Індыі ў пярэднім квартале.
У гэтым адносным выказванні крыўчацца множыцца рашэнняў. Чым являецца дохад, і што прызначае компанію як кліента? Калькуюцца па каторой даце квартал, і як адбываецца картаграфаванне Паўдня Індыі? Чы робяцца вярненні грошаў і анульваныя замовленні? Якія правілы валюты дыяюць, і што можа бачыць той, хто ставіць запыт? Мадэль можа толькі здагадвацца па кожнам з гэтых пытанняў. Аднак здагадкі — гэта не кераванне. Калі адпаведзь агента не падтрымваецца дашбордам, людзі перастаюць яму даваць доверлівасць. Калі ён включае неправільную табелю, цячыны выглядаюць правдападобна, але ўсё ж не такія, якія ёсць на самай працэ. Калі ён ігнаруе правілы доступу, адпаведзь стае вылівам дакументаў.
Таму справжнія пытанне — не тое, чы можа мадэль пісаць SQL, а тое, чы вообшча яна должна ствараць бізнес-логіку.
Што робіць семантычны слой
Семантычный слой знаходзіцца між неапдэтаванымі дадзеннямі і тымі, хто іх выкарыстоўвае, ператвараючы тэхнічныя структуры базы дадзеных у стандартызаваныя бізнес-канцэпцыі. Ён візначае паметры, меры, выміры, способы з’еднання, сегменты, іерархіі, правіла доступу, правіла кэшавання, прадзейсненныя агрэгаты і API-і, якія вікорыстоўваюцца для ўтрымання інформацыі, замест таго, каб адкрываць табліцы і столбцы.
Конкрэтна, orders.amount, customers.type, orders.created_at і refunds.amount стаюць Revenue, Enterprise Customer, Order Date і Refund-Adjusted Revenue. Агентам неабходны такія тэрміны. Без семантычнага слоя агент аналізуе схему і сам стварае выводы. За наявнасці такога слоя ён працюе на адпраўленых вызначэннях. Агент усё ж не ўсёвыражна ідэальны, але адной з галоўных прычын халюцынацый у аналіцы знікае, таму што візначэння паметры больш не трэба рэконструюваць з неапдэтаваных табліц.
Гэта катэгорыя, а не адзін продукт. Cube, dbt Semantic Layer (збудаваны на MetricFlow) і Looker's LookML кожны з іх рашылае тую ж проблему у своіх экосістэмах. Cube прывлекае ўвагу тут, таму што яго падход для агентаў ёсць нечым выключна цяплым, хоць архітэктура мае большое значэнне, чым марка.
Чаму Cube ёсць гарным прыкладам
Cube — гэта не проста шар дашбордаў. Адзін кераваныя модэль сапраўдзіць падтрымку для інструментаў BI, вбудоўанай аналітыкі, API і агентаў AI, якія ствараюцца на адной базе кубаў, памероў, вымераў, з’едынэнняў, сегментаў, іерархій, прадзейстрованых аграгатаў і правіл адчынення. Гэтыя элементы ўсе ў тым жа розмірэ, калі трэба для стварэння аналітычнага агента.
Яго сабственны апіс адзычынкі добра выказвае галоўную ідэю: агенты не запытваюць хранілню безпасна, яны запытваюць сэмантычны шар, а час адчынення выступае як захоўнік межы межу агента і хранілні.
Пораўняйце, што кожны з іх дае модэлю. Калі ёсць неапранутая табліца, модэль бачыць толькі назвы столбцоў. Калі ёсць семантычны слой, модэль таксама отрымае затверджаныя панявы, расчыткі, якія стояць за кожной з іх, спосабы ўзаінтэрэсавання, тое, да чаго можа даступіць тэкушчы корыстнік, а таксама безпечны спосаб запытання. Перазнаходжэнне бізнес-логікі для кожнага запытання ёсць марнатрацыяю рэсурсоў, таму агент павінен запытваць слой, які ужо яе мае.
З’яўленне плюс значэнне: дзе паслужыць MCP
MCP — гэта стандартны спосаб падключэння AI-асістэнтоў да зовнішніх інструментоў і дадзеных, але падключэнне не ўсё роўна розумеў. Калі даць агенту прымітны доступ да неапранутых табліц складу праз MCP, яму все равно даведзіцца самостайна з’ясавляць значэнне, што ёсць первісной проблемай у новай структуры.
Болей эфектыўны падход — гэта направленне агента праз семантычны слой:
AI agent
→ MCP client
→ semantic-layer MCP server (e.g. Cube's)
→ semantic layer (governed metrics, dimensions, joins, policies)
→ data warehouse
MCP караце доступ, а семантычны слой — значэнне. Агент не павінен запытаць базу дадзэння, якія таблыцы трэба з’яеднаць, каб вылічыць дохад. Ён павінен запытаць семантычны слой пра затверджаны показнік дохаду і выміры, якія ён можа выкарыстоўваць.
Есць два застэрэжэнні, якія памагаюць застацца адкрытымі, адколі гэтая галоўка развіваецца быстра і лёгка перацініць ўсё. Oficыяльны сервер MCP Cube, які ўходзіць у склад Cube Cloud і доступны праз HTTPS з OAuth, — гэта не тое ж самае, што серверы MCP для Cube, створаныя спільнай спяльнотай, напрыклад, тые, якія распространяюцца праз Smithery. Іхня доверлівасць, падтрымка і тыпаведчык разныя, і для практычнага выкарыстоўвання трэба выбіраць oficыяльны, кераваны падход. Таксама, адгукаванне MCP як абавесці ў гэтай галоўцы ўзнікла не так давэўна, яна дадаўцца як дапамога да API REST, SQL і GraphQL, якія гэтыя продукты працавалі ўжо гады. Гэта працюе, але гэта функцыянал 2025–2026 гадоў, таму пераканайцеся, што ён супарадні з версіяй, яку вы насправды выкарыстоўвайце.
Больш адміністрацыйны спакт на всіх этапах
Калі все складзенае, прабег працы выглядае так:
user question
→ AI analytics agent
→ MCP / tool call
→ semantic layer (approved metrics, dimensions, joins, segments, policies)
→ data warehouse
→ governed result
→ agent explanation
Агент не мае вольнае руку ў працэўванні з необработанымі дадзеннямі. Ён павінен выкарыстоўваць кераваны інтэрфейс, таму каманда контролюе, якія показнікі існуюць, якія выміры ёсць дзейнарамі, як працююць з’ѐеднанні, якія фільтры дазволены, хто можа бачыць якія радкі, чыя ўтварэнні прыходзяць з кэшу чы раней аграгаваных дадзенняў, і як запіты выкананы праз API. Гэта лепшая, чым прасіць мадэль напісаць SQL і спадзявацца, што бізнес-логіка будзе правільная.
Прыклад працы: адрысаванне выручкі
Запытайце пра адрысаванне выручкі падпрыемства за пасляпэўны квартал. Без семантычнага шару агент выважвае, якая табела мае выручку, чы гэта значыць брутто, чыста, зарэўанавана чы паўнастаўленая, чы вырачанні выключаюцца, як ідэнтыфікуюцца падпрыемственыя рахункі, якая столбець часу візначае пасляпэўны квартал, чы валюты трэба пераканваты і чы гэты корыстнік можа бачыць кожны сегмент. SQL можа быць выкананы, але выкананне — гэта не тое ж самае, што правільнасць.
За дапамою сэмантычнага шара такія адказы вялікі час ужэ існуе. Дохадзіны — апраўнаная мера, Корпатывыя кліянты — апраўнаны сегмент, Дата замовлення — апраўнаная вектарная характэрыстыка часу; логіка вярнення грошаў задаецца аднойчы, а політыка доступу прыменяецца залежна ад таго, хто запрашвае. Агент не стварае новых показнікаў, а просіць апраўнаныя. Гэта аддзеляе генераванне SQL на языке працовай мовы ад кераваных аналітых на аднойчыні агентаў.
Што можа пайсці не так з прымітным доступам да складу
Прамы доступ дае агенту занадта многа прыгод для спадзявання, і неудачы ў такім случае ўсё можна працягнуць:
- Стварэнне новых показнікаў: дохадзіны вырахоўваныя інакш, чым у панелі керавання фінансамі.
- Неправыя з’еднанні: запыт выкананы, але з’еднанне дублюе рэкорды або выкасывае іх.
- Відсутныя фільтры: анульваныя замовленні, тэстовыя акаунты, выкасываныя рэкорды або внутршнія корыстувальнікі застаюцца ў базе.
Агентам, якія адпавядаюць на бізнес-запыткі, патрэбны строгейшыя меры захоплення, чым тыя, якія забезпечвае генераванне SQL. Ім патрэбны семантычныя обмежэнні.
Закаленне SQL без адкрывання первісных таблэц
Відмова ад гнучкасці — гэта не цена адарожнення. Зрэлы семантычны шар можа заставіць дверы SQL застацца ачытымі, спрамаванымі на кераваныя об’екты, а не на фізычныя таблэцы. У SQL API Cube кожны кюб або відглед выглядае як таблец, а яго памеры, выміры і сегменты — як столбцы. Пакалі ён выкарыстоўвае протакол і дыялект Postgres, практычна будзь-які кліент, які падтрымлівае Postgres, можа з’яўіцца падключыцца.
Інструменты і агенты падтрымляюць запыты у стылі SQL, але мадэль вялічына тое, што можа быць запытана. Агент не пераскаквае праз сырые таблыцы; ён працуе з апраўнанымі паказнікамі і вымірамі, што являе сабою практычны компроміс, які ўжо болей прыбліжаны да таго, як павінны функцыонаваць аналітычныя сістэмы ў працэсе вырабоцтва.
Правіла доступу маюць такое ж значэнне, як і паказнікі
Для канверсацыйных агентоў кантроль доступу стае крытычным, адколі палатка для чату запоўнена вопытамі без чысткіх меж. Калі хтось пытаецца: «Пакажыце мне дохады па кліентах», — сістэма павінна знаты, якіх кліентаў гэтае адноса можа бачыць, які рэгіон чы ўчаснік дыялогу дапытваецца, і чы розрахованы дэталі на рэвэлі кліентаў чы толькі агрэгатныя даны.
Кюб выкорыстоўвае політыкі доступу і безпеку на рэвэльнай гэтыні ў сэмантычным слое. Такая распаўсюджэнне ўсвядомлена: ніхто не павінен пакладацца на агента, каб той сама адкрываў усе правілы без прыказа. Запіс „ніколі не адкрываць неавтарызаваныя даны“ у прыказе ёсць запросам. Калі слой обмежвае паводлівага карыстальніка пэўнымі рэвэлямі, вымірамі і мерамі, гэта ёсць прыменэннем правіл. Прыменэнне правіл ёсць набліжна сільнейшым, і яно выконваецца ў слое даных, а не ў прыказе.
Аспект выконвання: кэшаванне і прадзейстрованне
Аналітыка на адносах ёсць ітэратыўная. Чалавек запытаеся пра выручку па рэгіонах, пасля чаго раздзелі яе па продуктах, пасля чаго парабяліць з пярэднім кварталам, а пасля чаго обмежыць яе толькі корпаратыўнымі кліентамі. Калі кожны крок стае новым, складным запытам да хранілні, затрымкі і віткі стрэмгана растуць.
Праця механізмаў прадзейснення і кэшавання дадзэнняў у Cube, якія керуецца яго двайнам CubeStore, прышвартовуе час адпаведзення на часта запітання. Адным з рэзультатаў было прыблізна падвоўчанне зусім костаў складу пасля таго, як агрэгатаванне дадзэнняў перайшла ў базу дадзэнняў Cube. Такім чынам, для паўтараючыхся запітанняў семантычны слой выступае як слой для падвышэння працэснасці, а таксама і як слой для керавання.
Дзе гэты падход даў рэзультаты
Агенты, якія адпавядаюць на запітанні пра доход, сегменты кліяў, выкарыстоўванне продуктав, аналітыку, спрамованую да кліяў, панелі керавання, KPI-яў чы адказы на запітанні пра показнікі, адчуваюць найбольшыя выгоды, так сама як і будзь-які сцэнарый самаслужбовай аналітыкі.
Найбольшыя рэзультаты досягаюцца там, дзе вялікія часткі дадзэнняў вялікі час вжываюцца знову. Створыце мадэлі ARR, MRR, доходу, пакідання кліяў, утрымання кліяў, актыўных корыстувачаў, коефіціента пераканання, валовага маржы, часу рашэння проблемы чы адхвату функцый як раз, і кожны агент будзе іх вжываць знову, замест таго, каб пераскладваць іх ў кожны раз, калі змінюецца запіт.
Дзе команды павінны быць адзяйнымі
Нічага з гэтага не ўзьміцца з чароўнай палочкі, і кераванне павінна быць рэальным, а не проста назвай. Непашырэны модэль вызывае труднасці у агента. Некарэктныя ваказанні па метрыках даюць правільныя, але неправдывыя цыфры. Занадта шырокія правілы доступу продовжаюць адкрываць даныя для несанкціонаванага доступу. Модэль, наполнены ўскладненымі, майжэ ідэнтычнымі метрыкамі, дазволяе агенту выбраць некорэктную з іх. А калі ступень свежасці невідома, адпаведны адказ можа здавацца актуальным, хоча базуецца на застарэлых даных.
Таму корыстны вопыт не ў тым, чы існуе семантычны слой. Ён у тым, чы гэты слой ўстатківае для таго, каб агент могаў яго безпечна вікорыстоўваць. Модэль павінен быць задокументаваны, маты версіі, працаваць праз тэсты, карацца правамі на доступ і быць зрозумелым, падходзіць да панелей керавання, якім люды вяруюць, быць прыўязаным да пераканання якосці даных і чытка адзначаць ступень свежасці і меры. Слабы слой дае слабыя адказы агента.
З необработанага SQL да кераваных аналітых
Разлік між падчыннімі полягае у тым, што бачыць агент і што можа быць наражана на абяранне:
- Просты пераклад тэксту ў SQL: агент бачыць табелі і столбцы складу, а галоўны рызык — гэта вымышлена бізнес-логіка.
- SQL плюс документацыя схемы: гэта палегшэнне, але з’ѐеднанні і показнікі все ўсё лёгка можу быць неправільна вікорыстаны.
- Толькі семантычны шар: агент працуе з візначанымі показнікамі, вімірамі, адносамі і правіламі. Гэта безпечнейша форма, пры чым якасць контролюецца за дапамогою мадэлі, якая стоіць за ёю.
- Семантычны шар плюс MCP: аналітыка, керованая правіламі, выкладзена як інструменты агента; наразе гэта найкрашчы варыянт для керованай AI-аналітыкі.
Пераклад тэксту ў SQL застаецца корыстным, але для бізнес-аналітыкі ён павінен відбывацца на адной семантыцы, керованай правіламі, а не на спадчынных прыпушчэннях ўзгалі ўжо схемы.
Спіс пераконтраціяў пры тым, прычым агент прыкасаецца да бізнес-даных
- Спачатку размясціце ключовыя показнікі у семантычным шары.
- Указаць, які вымяры і споўненні ёсць дазволенымі.
- Застосавляць правілы доступу і правілы на рэвэлі в меразі.
- Прадаць API, якія керуюцца правіламі, там, дзе раней былі необработаныя табліцы.
- Даходзіць да меразы праз MCP толькі за дапамою апраўнаных, офіцыйных інструментаў.
- Ведаць лог кожнага запіту агента разам з SQL, які ён стварыў.
- Прадаць кожную адпаведзь з адзначэннем метрыкі, якая стоіць за ёю.
- У кожнай адпаведзі паведамляць, насколькі свежыя ёсць даны.
- Прабаваць звычныя бізнес-запыты і парабяляць рэзультаты з надзеянымі панелямі метрык.
- Заблокаваць прымытны доступ да чутлівых табліцы складу.
- Выбраць, што будзе дзеяць, калі запрошаная метрыка не мае вызначэння.
- Навучыць агента адпавядаць «не вызначана», а не імпровізаваць.
- Версіяваць вызначэнні метрык як код.
- Прабавіць правілы доступу з рэальнымі ролямі корыстнікаў.
- Следзіце за запытамі, які выдаюць памылкі або даюць неясныя рэзультаты.
Найважлівэйшая правіла: калі паказнік не ўзначаны, агент не павінен яго выдумваць. Ён павінен прагтучыць уточнэнняў або сказаць, што паказнік недоступны.
Запытанні для каманд з разработкі продукту
Перш чым даць новаму агенту аналітыкі всю структуру складу, спачатку зупініцеся і выясніце калькі лягкіх пытанняў. Адначыце, якія бізнес-запытанні ён павінен адпавядаць, якія паказнікі затверджаны, якія вектары ўзятыя ў расчытанні і якія з’еднанні ёсць безпечнымі. Выясніце, хто можа бачыць шта, насколькі свежымя маюць быць даны, якія адпаведзі затрэбаваныя з адпаведным адзначэннем або цітатай, і якія запытанні трэба адхіліць. Толькі пасля чаго прадасце гэты скарыстаны спектар агенту.
Куб — адзін з спосабоў стварэння паверхні дадзэнняў, а dbt Semantic Layer, LookML і MetricFlow падходзяць да таго ж задачы з іншых кантэкстаў. Важлівы урок не стосуецца конкрэтнага продукту. Агентам неабходны кераваныя бізнес-семантыкі пры працэ са бізнес-дадзэннямі.
Ключовая мысль
Рассматрэчванне аналітыкі на базе AI як чыстае заведама з тэксту ў SQL не дае правільнага розумення, адколі кераванне значэнням ёсць складнейшай часткай. Агент, які працуе з необработанымі табламі складу, можа напісаць абсалютна правільны SQL, але пры тым прадаст некарэктныя бізнес-рэшэнціяў за дапамогою выдуманых показнікаў, некорэктных з’еднанняў, ігноравання правіл доступу чыя-небудзь цыфры, якія суперчаюць дашборду. Семантычны слой змінюе інтэрфейс: затверджаныя показнікі, выміры, з’еднання, правілы і API заменяюць необработаную структуру дадзэнняў, якая павінна быць адгукнутая. MCP забезпечвае з’еднанне, семантычны слой — значэння, а кераваная аналітыка патрабуе і таго, і другога.
Супаўзвязаныя матэрыялы
- Стварэнне агента для атрымання кваліфікаваных кандалаў з AI на Python з FastAPI і Pydantic — Ператвараеце неактуальныя кандалы на кваліфікаваныя: структураваная выкарыстоўвання LLM, аправарэнне за дапамою Pydantic, атрыманне балоў на аднойчынных правілах, хранэнне ў PostgreSQL, адрады і можлівасць перагляду чалавекам.
- Порэванне кераваных агентаў: Anthropic, LangGraph і Google ADK — Хто керуе сандбоксам, крантамі і трэйсамі? Порэванне Anthropic Managed Agents, LangGraph і Google ADK з цэнамі, спосабамі абяканняў і кароткім кераваннем для прыняцця рашэння.