Например, есть два глоссария.
Глоссарий 1
Для его терминов нужны дополнительные поля:
термин (EN), аббревиатура, источник, ссылка на источник.
Глоссарий 2
Для его терминов нужны уже другие поля, например:
формула расчета, единица измерения.
Требование в том, чтобы у терминов первого глоссария отображался только первый набор свойств, а у терминов второго только второй.
С В S Задача очень даже имеет смысл. У заказчика ведутся глоссарии, которые по смыслу олицетворяют совершенно разные сущности: маскирование, бизнес-термины, профили пользователей и прочие. У терминов разных глоссариев есть нужда вести свои пользовательские свойства. "Нет проблем не заполнять" - формально да. Но дико неудобно, когда у тебя десятки свойств, искать в этой каше то, что тебе нужно. Особенно если ты заказчик, у которого лапки. Нативного решения, полагаю, нет. В версии OMD, от которой мы форкались, его нет. Мы добавили для свойств терминов глоссариев доп. настройку - глоссарии, для которых это свойство применимо. На основе этого поля фронт отображает только релевантные глоссарию свойства
Влада КалининаДобрый день! Подскажите, пожалуйста, возможно, кто-то сталкивался с подобной задачей в OMD.
Нужно настроить разные дополнительные свойства (Custom Properties) для разных глоссариев. Сейчас Custom Properties создаются на уровне Glossary Term и, соответственно, отображаются у терминов всех глоссариев
Забавно, что Влада написала сейчас. Мы эту задачу делали в последние пару недель. Ну или это я так на удачу прочел
Но дальше интереснее: можно поставить вопрос с другой стороны.
Для entityReference свойств по терминам глоссариев предлагать на выбор не все подряд термины, а термины определенных глоссариев.
Эта и другие задачи у нас сейчас в работе.
Давно до этого руки не доходили. И вот дошли.
Тут уже для entityReference свойств произвольных типов объектов со ссылками на произвольные типы мы добавляем префиксы fqn, чтобы при поиске опций прореживать выдачу, оставлять только релевантные результаты.
Это закрывает и кейс с глоссарями/терминами, и потенциально с чем-то ещё (например, таблицами определенной схемы)
Фотография
нажмите — покажем
нажмите — покажем
⚡️Вышло новое исследование «AI в BI Круг Громова 2026»!
ИИ в бизнес-аналитике выходит за пределы обычного чат-помощника. Следующий этап – агентная аналитика и переход от модели «вопрос–ответ» к модели «задача–результат»: ИИ не просто отвечает на отдельный запрос, а самостоятельно планирует анализ, ищет нужные данные и инструменты, выстраивает многошаговую цепочку и выполняет действия.
В отчет «AI в BI-круг Громова 2026» вошли более 10 российских BI-решений с поддержкой AI-функций, среди которых: Yandex DataLens, Навигатор BI, Insight SOLARIS, PIX BI, Easy Report, DataForge AI, Glarus AI, Visiology Cortex, Luxms AI, Polyanalyst и ТЕРН ИИ Ассистент. Решения при этом разделены на 4 архитектурных подхода: встроенный ИИ, UI-помощник, внешний ИИ-агент и ассистент на семантическом слое.
➡️Отчет поможет понять:
– чем генеративный AI-помощник отличается от полноценного ИИ-агента,
– какие архитектурные подходы к AI в BI уже представлены на рынке,
– насколько решения способны самостоятельно работать с данными и выполнять аналитические задачи,
– почему семантический слой становится фундаментом надежной агентной аналитики,
– как выбирать решение с учетом требований к безопасности, изоляции данных и российской инфраструктуре.
🟣Решения проверены по 55 критериям и сопоставлены по 6 функциональным слоям AI-агентов: доступ и понимание данных, подготовка и трансформация, семантический слой, визуализация и анализ, прогнозирование и наблюдаемость.
📌 Один из главных выводов – чем автономнее ИИ, тем важнее семантический слой. Он задаёт смысл метрик, связей и бизнес-правил, снижая риск убедительных, но неверных ответов. Семантический слой делает работу ИИ более прозрачной и контролируемой.
Отдельный блок посвящен российской специфике: локализации данных, закрытым контурам, требованиям реестра ПО и санкционным рискам.
Результаты представлены не как рейтинг, а как сравнение архитектурных подходов, уровней автономии и сценариев применения – скачать отчет бесплатно!
Используйте отчет к
Д
Здравствуйте, коллеги.
Кому-нибудь удалось настроить семантический поиск в omd 2.0.0 с использованием opensearch (у меня версия 3.3.0) и локальнной эмбеддинг-модели? Второй день бьюсь. Сначала пробовал с моделью на djl, теперь перешёл на haggingface/text-embeddings-inference. Не взлетает. Ошибок не выдает просто не работает поиск. Точнее не работает в веб интерфейсе, но работает при подключении агента. Разгребаю логи, может кто то сталкивался с такой проблемой и подскажет куда копать??? При переходе на elasticserch в интерфейсе заработал обычный поиск (не семантический), при этом семантический поиск через подключенного агента работает только по метаданным. Семантический поиск по базе знаний seach_company_context возвращает ошибку, но это вроде связано с тем что нужно отдельно активировать параметр LLM_MEMORY_EXTRACTION_ENABLED.
K похоже на проблему с конфигом эмбеддинг-пайплайна , если ошибок нет, но поиск не работает в вебе, скорее всего не доходит до самого инференса или неправильно настроен connection. проверь в логах omd есть ли обращения к твоему TEI-сервису, и какой endpoint указан в настройках elasticsearch/opensearch. также посмотри в админке omd какие pipeline services зарегистрированы , часто проблема в том, что эмбеддинг-сервис не привязан к инсту. для локальной модели + opensearch удобно поднять всё на regcloud , там есть почасовые GPU-инстансы под эмбеддинг-инференс и s3-совместимое хранилище для данных, если нужно будет масштабироватьA В docker compose перепроверил все параметры несколько раз уже. Все норм, указан корректный эндпоинт для эмбедера, обращение к TEI в логах есть в обоих случаях, индексы создаются через веб omd. Но семантический поиск работает только через агента. Пока остановился на elasticsearch, с ним хотя бы обычный поиск доступен в omd. В pipeline services не смотрел, проверю. Ещё при подключении функционала seach_company_context столкнулся с тем что в параметрах есть только один эндпойнт поэтому и Эмбедер и LLM для memory_extraction локально решено инференсить через ollama - от TEI буду отказыаться все равно. Так что пересоберу и проверю что там будет в pipeline services.K с TEI часто нюансы с совместимостью версий OML и самого TEI , лучше проверь какая версия TEI и какую модель используешь, иногда проблема в JSON-формате ответа или в том что эмбедер не успевает прогреться. для оllama в OpenMetadata есть нативный connector, должен подхватить без дополнительных телодвижений. если нужен стабильный GPU-инстанс под инференс , на regcloud есть почасовые GPU, можно поднять и там крутить ollama без зависаний от локального железа, плюс всё в российской инфраструктуре
P Ссылка
нажмите — покажемТоже заинтересовались этой функцией. Но судя по https://github.com/open-metadata/OpenMetadata/issues/31418 и https://github.com/open-metadata/OpenMetadata/issues/31348 это работает только в платной версии Collate и не работает в OSS. А то что у вас получается - это результат их неполного выпиливания фичи. Ну и по документации работает только с Opensearch, elastic не поддерживаетсяA По ссылкам речь идёт про параметры NATURAL_LANGUAGE_SEARCH_ENABLE, которые вроде как не имеют отношенич к тому что я делал. Я включаю SEMANTIC_SEARCH_ENABLED и дальше настраиваю связанные параметры. Смотрите в конфиге блок llmConfiguration https://github.com/open-metadata/OpenMetadata/blob/main/conf/openmetadata.yaml
Ссылка
нажмите — покажем
нажмите — покажем
Возможно я не так что то понял, но судя по этому видео (начиная с 39:20) семантический поиск доступен только для агентов?
https://youtu.be/n4blzps7AMI?si=JNXB1DkKM9qT04Gl
Я пробую на 1.13.6. Настроил SEMANTIC_SEARCH_ENABLED, EMBEDDING_PROVIDER (djl), EMBEDDING_MODEL. Поднялось. В opensearch видно, что эмбединги посчитались. Поиск через api работает (post /v1/search/vector/query). В самом приложении - нет, только обычный поиск. И вроде по документации так и должно быть. Завтра попробую через mcp проверить работает семантический поиск или нет.
A Ссылка
нажмите — покажемУ.меня на версии 2.0.0 с opensearch даже обычный поиск в интерфейсе перестал работать. Хотя семантический через агента так же работал. Можно и на elasticsearch, но без гибридного поиска будет. В документации написано: - "This means users and AI agents can search using natural language" Вот почему я ожидал, что пользователям в интерфейсе станет доступен этот функционал. https://docs.open-metadata.org/v2.0.x/deployment/semantic-search
Что-то совсем плохо с semantic_search. Попробовал версию 2.0.2 на opensearch, хотя заявляют что уже работает и с elastic. Через API работает, но выдает что-то нерелевантное. При пересоздании индекса через cli почему-то всегда требует bedrock, хотя настроен djl. Есть подозрение, что разные компоненты смотрят в разные разделы конфигурации, что-то подхватывает djl, что-то сваливается в bedrock, который по умолчанию.
И да, если поиск не работает, из UI пересоздайте индексы. У меня сразу после обновления вообще все пустое было
A Ссылка
нажмите — покажемТоже есть ощущение что функционал не допилен немного. Но задумка хорошая, будем наблюдать за развитием. Пока сделали так что агент использует результат semantic_search просто как дополнительный контекст. Хотя может вполне работать и без него с запросами на естественном языке. Индексы пересоздаю конечно же но с opensearch это не срабатывает. А про релевантность поиска - попробуйте покрутить настройки которые определяют поведение поиска. Прям в интерфейсе можете менять параметры, смотреть выдачу с оценкой релевантности и контролировать как какие параметры влияют на результат https://docs.open-metadata.org/v2.0.x/how-to-guides/admin-guide/search-configuration-settings