#knowledge_graph — Public Fediverse posts

EventRAG: как научить RAG искать первопричину во времени, а не в тексте

Завод теряет деньги не в момент поломки, а пока инженер ищет ответ на вопрос «почему». Заменить подшипник — полчаса; понять, что подшипник убила заявка на ТО, отложенная два месяца назад, — часы, и именно эти часы стоят дороже всего. По данным Siemens, незапланированный простой обходится 500 крупнейшим компаниям мира в $1,4 трлн в год, а средний крупный завод теряет 27 часов в месяц. Казалось бы, вот задача для корпоративного RAG-ассистента. Но обычный RAG здесь проваливается структурно: он ищет похожее по тексту, а первопричина цехового инцидента почти никогда не похожа на симптом. Аларм «потеря мастеринга оси» и наряд «замена батарей энкодера», отложенный 67 дней назад из-за отсутствия ЗИП, — для семантического поиска это разные вселенные. В итоге ассистент уверенно советует «перемастерить ось и продолжить» — симптом снят, причина осталась, при следующем отключении питания линия встанет снова. Разбираю EventRAG — архитектуру, которая учит RAG работать с потоками событий из PLC, MES, Historian и CMMS: каждое событие получает явный временной якорь, поверх строится причинный граф знаний, а поиск идёт от симптома назад по причинным связям — и вытягивает настоящий корень с последнего места выдачи выше всех отвлекающих сигналов. Внутри — полный разбор живого по типажу инцидента на роботе-паллетайзере Hyundai Hi5-N00 со всеми расчётами, AR-HUD для инженера, прозрачная экономика внедрения, двадцать схем и position paper, с которым мы участвуем в ISPR 2026 в Сараево. Все допущения и модельные цифры честно помечены.

https://habr.com/ru/articles/1056056/

#RAG #LLM #root_cause_analysis #knowledge_graph #Industry_50 #onpremise #MTTR #дополненная_реальность #предиктивное_обслуживание #промышленность

Почему ChatGPT называет одни бренды и молчит про другие: как машина знает компании

Я изучаю AEO/GEO (продвижение брендов в ответах нейросетей) и наткнулся на разбор про странную вещь: нейросети называют одни бренды и будто не замечают другие, причём качество продукта тут ни при чём ( SearchAtlas ). Объясняют это через понятие сущности: и поиск, и нейросети воспринимают бренд как отдельный объект знания со своими свойствами и связями. Тема показалась любопытной, и я полез в первоисточники: доки Google, schema.org, Wikidata, замеры Ahrefs и Frase, пару работ с arXiv. Там и уткнулся в неожиданное. Знание о бренде у машины устроено двумя совершенно разными способами, и их постоянно путают. Один способ работает у обычного поиска Google, это Knowledge Graph. Другой у языковых моделей вроде ChatGPT, это память в весах нейросети. Единого первоисточника у этого разбора нет, я собрал его из перечисленного под наш контекст, ссылки стоят по тексту. Дальше разложу оба механизма простым языком и покажу, что с каждым можно сделать.

https://habr.com/ru/articles/1055744/

#knowledge_graph #llm #gpt #schemaorg #wikidata #entity_seo #нейропоиск #seo #aeo #geo

Что скрывается за AI-стратегией SAP, Oracle и Palantir: зачем корпоративному ИИ семантическое ядро

SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou всё активнее строят вокруг корпоративного ИИ семантические слои: knowledge graph, ontology, process intelligence, business data cloud, agent memory и агентные платформы. Зачем им это, если языковая модель уже умеет читать документы, таблицы и API? Потому что корпоративному ИИ нужен не только доступ к данным. Ему нужен смысловой слой предприятия: термины, объекты, экземпляры, статусы, источники, связи и правила качества. Именно здесь начинается переход от отдельных ИИ-функций к системам, которые способны собирать комплексную управленческую позицию для действия. Разберём, что за этим стоит?

https://habr.com/ru/articles/1039996/

#искусственный_интеллект #корпоративный_ИИ #ИИагенты #RAG #knowledge_graph #ontology #семантическое_ядро #ERP #управление_данными #архитектура_ПО

Как я сделал AI-директора для малого бизнеса и почему отказался от RAG

Маленькая компания, человек 20. Гендир тонет в задачах. Помнить кто что обещал, отслеживать движение по целям, держать в голове десяток проектов одновременно. У больших корпораций для этого есть штат руководителей среднего звена и проджектов. У малых есть один директор, который пытается быть всем сразу. Лира берёт на себя часть этой работы. Это не корпоративный чат-бот, не ChatGPT с настройками компании. Конкретный продукт с конкретными функциями:

https://habr.com/ru/articles/1034298/

#ai #llm #claude #rag #aiагенты #agentic_ai #knowledge_graph #python #fastapi #бизнесавтоматизация

Инженерное знание как код: зачем я связываю MCP, агентов и модель изменений

Как только AI-агенты начинают участвовать в разработке, быстро выясняется неприятная вещь: проблема не в генерации кода, а в управлении смыслом изменений. В статье рассказываю, как я перестроил процесс проектирования фич через связку: — чата с агентом бизнес-аналитиком; — графовой модели изменений; — MCP-доступа к модели; — агентского бутстрапа; — формализованного техпроцесса. На примере разработки агентской памяти показываю, как User Story превращается в граф ролей, целей, мотивов, API и зависимостей, а агент перестаёт быть «чатиком сбоку» и становится участником инженерного процесса. Это не история про «ИИ пишет код». Это история про то, как инженерное знание начинает работать как код.

https://habr.com/ru/articles/1032582/

#agentic_workflow #MCP #ontology #knowledge_graph #semantic_layer #semantic_engineering #Ontology_MCP #AI_agents #software_architecture

LLM — поиск товаров

LLM-поиск товаров: R&D применения технологий RAG и Knowledge Graph Search для продвинутого поиска товаров по сложным текстовым запросам. Как LLM и Knowledge Graph ищут товары

https://habr.com/ru/articles/1018860/

#LLM #RAG #Knowledge_Graph #ML #GraphRAG #Graph_Search

Как я построил Graph RAG систему с точностью 96.7% за 5 дней: от научных статей до production-ready пайплайна

Я реализовал Graph RAG систему, которая комбинирует 5 техник из свежих научных статей (KET-RAG, HippoRAG 2, VectorCypher) в единый пайплайн с декларативным Datalog reasoning-движком, полной провенансной трассировкой и типизированным API. Результат: 174/180 (96.7%) на билингвальном бенчмарке из 30 вопросов, оценённых в 6 режимах retrieval. Три режима достигли 100%. В статье — архитектура, 10 уроков оптимизации и эволюция от 38% до 96.7% за 10 итераций.

https://habr.com/ru/articles/1003064/

#GraphRAG #RAG #Neo4j #NLP #LLM #Python #Datalog #Knowledge_Graph #embeddings #PageRank

ERP.Next: Архитектура автономных ERP на основе мультиагентного ИИ

ERP-системы непрерывно развивались с самого начала своего создания. Но их архитектура до сих пор опирается на принципы, сформулированные до эпохи повсеместного распространения данных в реальном времени и развития автономного агентного искусственного интеллекта. Соответственно, можно с утверждением говорить, что текущая архитектура ERP-систем не отвечает современным вызовам. В этой статье разберем, почему ей нужен принципиально иной фундамент. Я предлагаю строить его на трех китах: семантический слой данных (USDL), открытая интеграционная среда и продвинутая мультиагентная платформа (AMAP). Далее я подробно представлю архитектуру такой ERP-системы, типы AI-агентов и примеры их работы в реальных бизнес-процессах. Ключевая идея — гибкая автономия под контролем человека. В статье я опираюсь на актуальные разработки и аналитику 2025 года, чтобы показать и возможности, и подводные камни мультиагентных систем в корпоративной ИТ-среде. 1. Вместо введения ERP-системы уже много лет являются центральной нервной системой крупного бизнеса. Они объединяют транзакции, данные и процессы в единый цифровой каркас. Исторически их архитектура заточена под главные задачи эпохи: обеспечить целостность данных, централизованный контроль и стандартизацию. Центральный механизм выполнения рабочих процессов и единая модель данных были главными козырями ERP, которые гарантировали надежную отчетность и соответствие регуляторным требованиям. Но мир изменился. Сегодня компании работают с постоянными потоками данных и телеметрии с IoT-устройств, в сложных цифровых экосистемах, в условиях рынка, где быстрые решения определяют операционные и финансовые результаты. Старая, монолитная архитектура ERP не успевает за новой реальностью.

https://habr.com/ru/companies/mt-integration/articles/992644/

#ERP #AInative_ERP #мультиагентные_системы #Knowledge_Graph #цифровая_трансформация #корпоративная_ИТархитектура #искусственный_интеллект #erpсистемы

Intent Weaving for AI Coding Agents
https://www.autohand.ai/updates/intent-weaving
#ycombinator #intent_weaving #AI_coding_agents #autonomous_execution #strategy_translation #mission_compiler #knowledge_graph #governance #adaptive_planning #benchmarks

Мама, у меня RAG: пути к улучшению, когда он «наивный»

В последние пару лет RAG (retrieval-augmented generation) стал одной из самых обсуждаемых технологий в области обработки текстов и поисковых систем. Его идея проста: объединить поиск (retrieval) и генерацию (generation), чтобы быстрее находить нужную информацию и создавать более точные тексты. Рост объёмов данных и информационного шума привёл к тому, что классические методы поиска и генерации уже не всегда справляются с новыми задачами. Например, большие языковые модели без доступа к актуальной информации могут искажать факты, а традиционные поисковики при запросах на естественном языке дают слишком общий результат. RAG решает эти проблемы, добавляя дополнительный "слой знаний" за счёт внешних баз данных, что особенно полезно для чат-ботов, систем вопрос-ответ, рекомендательных сервисов и многих других приложений. Целью данной статьи является погружение читателя в технологию RAG, а также ознакомление с основными критериями и методами его улучшения. В этой статье мы обсудим, как именно устроен RAG, как правильно оценивать его эффективность и какие существуют техники улучшения – от уже известных методов до совершенно новых решений.

https://habr.com/ru/articles/885770/

#graph_rag #RAG #retrival_augumented_generation #llmмодели #knowledge_graph #graphrag #semantic_search #genai #ии_и_машинное_обучение

[Перевод] Улучшение RAG с помощью графов знаний

Генерация с дополненной выборкой (RAG) — это метод, который соединяет внешние источники данных для улучшения вывода больших языковых моделей (LLM) . Этот метод идеально подходит для LLM для доступа к частным или специфичным для предметной области данным и решения проблем, связанных с галлюцинациями . Поэтому RAG широко используется для поддержки многих приложений GenAI, таких как чат-боты AI и системы рекомендаций . Базовый RAG обычно объединяет векторную базу данных и LLM, где векторная база данных хранит и извлекает контекстную информацию для пользовательских запросов, а LLM генерирует ответы на основе извлеченного контекста. Этот подход хорошо работает во многих случаях, однако он испытывает трудности со сложными задачами, такими как многоадресное рассуждение или ответы на вопросы, требующие соединения разрозненных фрагментов информации. Например, вопрос « Какое имя было дано сыну человека, который победил узурпатора Аллектуса? »

https://habr.com/ru/articles/871700/

#GraphRAG #rag #llm #milvus #knowledge_graph