Гибридный ИИ: сочетание детерминированного анализа с логическим мышлением на основе логики LLM.

Как архитектура ИИ предотвращает правдоподобный, но ошибочный анализ.

Делиться

Введение

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

Была лишь одна проблема: большинство результатов были неверными!

Хуже того, ИИ быстро научился определять, какие числовые диапазоны выглядят правдоподобно, и начал генерировать убедительные — но сфабрикованные — результаты. В сочетании с выразительной генерацией языка LLM эти результаты легко можно было принять за правду. И такое поведение не ограничивалось одной моделью. Аналогичные закономерности наблюдались во всех протестированных системах: ChatGPT, Gemini Enterprise, DIA Brain и Microsoft Copilot.

Однако одних лишь правдоподобных данных недостаточно, корпоративным системам искусственного интеллекта необходимы надежные данные!

Дальнейшее расследование выявило повторяющиеся сбои. Даже при включенном «Интерпретаторе кода» системы:

• пропущенные строки или столбцы,
• Применены некорректные фильтры.
• Возвращает идентичные результаты для разных входных данных.
• незаметно перемешанные части набора данных,
• или же просто не справлялись с более сложными аналитическими задачами.

Это привело к важному осознанию:

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

Оглавление

1. Вариант использования
2. Гибридная архитектура
3. Планировщик анализа
4. Аналитический механизм
5. Пример комплексного решения.
6. Почему архитектура ИИ важна

1. Вариант использования

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

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

1. В нем представлены общие рекомендации по улучшению конкретных оперативных аспектов на основе поиска специализированной документации с пошаговыми инструкциями и оценочных анкет.
2. Данный инструмент предназначен для анализа текущей ситуации на предприятии или в производственной цепочке на основе результатов оценки и письменных рекомендаций экспертов. На основе этого анализа предполагается предоставить высококонкретные рекомендации по дальнейшим шагам по улучшению.

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

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

Однако структура файла представляет собой сложную задачу. Поскольку все результаты оценки, промежуточные вычисления, метаданные и подробные вопросы оценки хранятся в отдельных столбцах, таблица содержит более 800 столбцов. Количество строк соответствует количеству оценок в базе данных и может варьироваться от одной до нескольких сотен (рис. 1). Оценки представлены целыми числами от 0 до 4. Кроме того, файл содержит более 160 полей свободного текста с качественными наблюдениями, сильными и слабыми сторонами, а также рекомендациями экспертов.

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

Первоначально эти задачи казались вполне по силам современным системам искусственного интеллекта на основе LLM, особенно в режиме «интерпретатора кода». Как уже упоминалось во введении, это предположение быстро оказалось ошибочным.

2. Гибридная архитектура

Основная идея преодоления аналитической проблемы заключалась в четком разделении детерминированного анализа данных от рассуждений и интерпретации на основе LLM. На рис. 2 показана выбранная архитектура системы после нескольких итераций улучшения. Система была реализована в Microsoft Copilot Studio, поскольку эта платформа позволяет комбинировать детерминированные элементы рабочих процессов, такие как темы и потоки, с компонентами рассуждений на основе LLM.

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

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

Основное внимание в этой статье уделяется модулю аналитики. Он выполняет детерминированный анализ данных и предназначен для получения воспроизводимых и надежных аналитических результатов. Он получает от родительского агента инструкцию по анализу на естественном языке, называемую Parent_Instruction . Сам модуль аналитики состоит из тем, потоков и модулей ИИ, которые в Copilot Studio называются «подсказками».

Тема T_receive_Excel_File отвечает за загрузку и хранение файлов с результатами оценивания. Она срабатывает при загрузке файла в окно чата, о чем свидетельствует значение переменной System.Activity.Attachments . Тема проверяет, является ли загруженный файл файлом Excel, и если да, то сохраняет его в глобальной переменной Assessment_File .

Тема T_analyze_assessments активно вызывается родительским агентом, если у него есть аналитическая задача для выполнения и он получает входные данные Parent_Instruction . Вторым входным параметром являются данные оценки, хранящиеся в глобальной переменной Assessment_File . Тема содержит два основных аналитических компонента: Analysis_Planner и Analysis_Engine . Оба компонента встроены в агентные потоки F_Call_Analysis_Planner и F_Call_Analysis_Engine . Эти потоки служат связующим звеном между темой T_analyze_assessments и подсказками ИИ P_Analysis_Planner и P_Analysis_Engine .

F_Call_Analysis_Planner получает только один входной параметр, Parent_Instruction , и перенаправляет его компоненту P_Analysis_Planner . Этот компонент генерирует Selection_Rule — основную инструкцию анализа, которая должна быть выполнена компонентом P_Analysis_Engine . Внутреннее устройство P_Analysis_Planner описано в главе 3.

F_Call_Analysis_Engine получает три входных параметра: Selection_Rule от Analysis_Planner , Mapping_File , предоставленный SharePoint, и файл Assessment_File ). Все три входных параметра передаются в подсказку ИИ P_Analysis_Engine , которая проводит анализ данных в соответствии с указаниями Analysis_Planner . Функция P_Analysis_Engine подробно описана в главе 4.

3. Планировщик анализа

Компонент P_Analysis_Planner является интеллектуальной частью конвейера анализа данных и генерирует инструкцию анализа, называемую Selection_Rule . Эта инструкция представляет собой перевод Parent_Instruction на естественном языке и, как правило, уникальна для каждого запроса. Для минимизации вероятностных вариаций процесс перевода ограничен строгими правилами.

Компонент Analysis_Planner сам не анализирует данные оценки. Его единственная задача — преобразовать вероятностную Parent_Instruction в детерминированную спецификацию анализа.

Далее мы более подробно рассмотрим отдельные части инструкции. Полную инструкцию можно скачать здесь.

 You are Analysis_Planner, an expert assistant for translating natural-language assessment analysis requests into structured Selection_Rules. Your task is to create a Selection_Rule JSON object for the Analysis_Engine. You receive only one input: 1. Parent_Instruction : A natural-language analysis request from the parent agent (orchestrator). You must analyze Parent_Instruction and determine: - which type of analysis is required, - which assessment content categories are relevant, - whether concept or execution maturity/findings are requested, - whether specific chapters are requested, - and whether row filters are required. The Selection_Rule you generate will later be used by the Analysis_Engine together with: - the real assessment data file, - and the Mapping_File to execute the analysis deterministically.

Приведённый выше фрагмент кода показывает начальную инструкцию для P_Analysis_Planner . Он чётко определяет назначение и область применения и явно разделяет планирование и выполнение. Планировщик преобразует запрос, а фактическое выполнение делегируется P_Analysis_Engine .

Далее следует более подробный раздел, описывающий семантику данных оценки. Разумеется, эта часть в значительной степени зависит от конкретного случая использования и набора данных. В ней определяются семантические категории, используемые для фильтрации строк, и категории, используемые для выбора фактических целей анализа (КАТЕГОРИИ ЦЕЛЕВОГО СОДЕРЖАНИЯ и АТРИБУТЫ ВЫБОРА ЦЕЛЕВЫХ ДАННЫХ).

 ASSESSMENT DATA SEMANTICS The assessment data can be addressed through the following semantic categories. ROW FILTER CATEGORIES Use these categories only for row_filters: - VS_Nr: Unique identifier of the value stream. Use when filtering by value stream number. - Value Stream: Name of the value stream. Use when filtering by value stream name. - ... TARGET CONTENT CATEGORIES Use these categories only in target_selection_rules.data_category: - chapter_score: Numeric maturity score. Use for maturity calculations, score analysis, and average maturity analysis. - strength: Assessor statements describing strengths. - ... TARGET SELECTION ATTRIBUTES Use these attributes only inside target_selection_rules: - data_category: Defines which target content category is needed. - aggregation_allowed: Use: - mean for numeric maturity averages - summary for textual summaries - ...

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

Это разделение важно, поскольку набор данных для оценки содержит более 800 столбцов, в том числе:

• рейтинги зрелости,
• Результаты текстовой оценки эксперта,
• метаданные,
• организационные схемы,
• варианты анкеты,
• а также различия между концепцией и реализацией.

Таким образом, выбор правильных целевых столбцов становится критически важной частью процесса анализа.

Ограничение допустимых типов анализа имеет не меньшее значение. Планировщик намеренно не может придумывать произвольные аналитические операции. Поэтому в разделе «ТИПЫ АНАЛИЗА» определены единственные допустимые типы анализа — в настоящее время всего два. Это значительно повышает предсказуемость и надежность последующего выполнения. Конечно, список можно легко расширить для отдельных сценариев использования.

 ANALYSIS TYPES Use exactly one of these analysis_type values: - numeric_mean Use for: - average maturity - mean maturity - ... - text_summary Use for: - strengths - improvement potentials - ...

В следующем разделе описывается, как планировщик выбирает соответствующие целевые столбцы абстрактным и детерминированным способом. Правила различают два предопределенных типа анализа: numeric_mean и text_summary , и, наконец, определяют, какие столбцы набора данных будут выбраны для конкретного запроса.

 RULES FOR target_selection_rules NUMERIC MATURITY ANALYSIS For numeric maturity analysis: - analysis_type must be: "numeric_mean" - data_category must be: ["chapter_score"] - ... TEXT SUMMARY ANALYSIS For textual summary analysis: - analysis_type must be: "text_summary" - data_category: include only requested categories: - "strength" - "potential" - "recommendation" - "remark" - ...

Аналогичная логика применима и к процессу фильтрации строк.

 RULES FOR row_filters Use row_filters only for filtering rows in the assessment dataset. Allowed row filter keys are: - VS_Nr - Value Stream - ... Do NOT use row_filters for: - chapter_id - ... These belong only to target_selection_rules.

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

 OUTPUT FORMAT Return only valid JSON. Do not return markdown. Do not return Python code. ... Use exactly this structure: { "status": "success", "parent_instruction_summary": "", "selection_rule": { "analysis_type": "", "target_selection_rules": { "data_category": [], "aggregation_allowed": [], "concept_execution": null, "chapter_id": null }, "row_filters": {} }, "warnings": [] }

Если запрос неясен, планировщик должен явно вернуть структуру ошибки, а не «угадывать» потенциально неверную инструкцию анализа.

 If the task is unclear, return: { "status": "error", "parent_instruction_summary": "", "selection_rule": { "analysis_type": null, "target_selection_rules": { "data_category": [], "aggregation_allowed": [], "concept_execution": null, "chapter_id": null }, "row_filters": {} }, "warnings": [ "The analysis task is not clearly understood." ] }

На данном этапе планировщик преобразовал неоднозначный естественный язык в детерминированную спецификацию анализа. Однако фактическое выполнение обработки данных еще не произошло.

В главе 5 мы проследим реальный запрос пользователя через весь конвейер обработки данных и рассмотрим, как P_Analysis_Planner генерирует Selection_Rule и как P_Analysis_Engine выполняет его на наборе данных для оценки.

4. Аналитический механизм

В отличие от P_Analysis_Planner , P_Analysis_Engine не анализирует задачу. Он лишь выполняет спецификацию анализа, сгенерированную P_Analysis_Planner .

Как и в главе 3, мы сосредоточимся только на наиболее важных частях инструкции. Полную спецификацию можно скачать здесь.

Инструкция P_Analysis_Engine начинается с определения базовой задачи. По сути, приглашение AI используется в качестве контролируемой среды выполнения Python. Код предопределен в инструкции приглашения и должен только выполняться, но не изменяться.

 You are Analysis_Engine, a deterministic pandas-based analysis executor. Your task is to analyze an Excel assessment dataset using Code Interpreter. You receive three inputs: 1. document The Excel file containing the assessment data. 2. Mapping_File The Excel file describing the columns of document. 3. Selection_Rule A JSON object that defines: - which columns to select from Mapping_File - which row filters to apply to document - which type of analysis to perform You must not reinterpret the original user request. You must not infer additional columns. You must not change Selection_Rule. You must not generate a new analysis approach. You must only execute the deterministic Python script below. Use Code Interpreter to execute the Python script. Return only the JSON result printed by the script. Do not return markdown. Do not explain the code. Do not add text before or after the JSON result.

P_Analysis_Engine получает три входных файла:

1. Файл Assessment_File загружается пользователем через интерфейс чата. Он сохраняется во внутренней document prompt-internal.
2. Файл Mapping_File , который поток F_Call_Analysis_Engine загружает из SharePoint в рамках подготовки к выполнению.
3. Правило Selection_Rule , сгенерированное программой P_Analysis_Planner (см. главу 3).

Файл Mapping_File играет решающую роль в определении семантики множества столбцов в Assessment_File на более высоком уровне абстракции. Благодаря этому уровню абстракции, Selection_Rule достаточно указать, какой тип информации требуется, в то время как P_Analysis_Engine выбирает соответствующие столбцы набора данных во время выполнения.

На рис. 3 показана структура файла Mapping_File . Он содержит строку для каждого столбца файла Assessment_File , потенциально релевантного для анализа данных. Столбцы данных, которые явно не имеют отношения к анализу, не представлены в Mapping_File и, следовательно, не видны P_Analysis_Engine . Для каждой строки в файле указаны критерии отбора:

• data_category :
  Функциональное значение столбца, например, степень зрелости, сила роста, название растения, регион или сезон.
• chapter_id :
  Уникальный идентификатор главы, посвященной оценке.
• chapter_name :
  Удобочитаемое название главы, посвященной оценке.
• concept_execution :
  Указывает, относится ли столбец к стадии зрелости концепции или реализации.
• aggregation_allowed :
  Определяет, какой тип агрегирования допустим для столбца, например, mean для числовых показателей зрелости или summary для текстовых результатов.

Далее в инструкции P_Analysis_Engine следует абзац о том, как интерпретировать правило выбора (Selection_Rule).

 Rules for Selection_Rule: - analysis_type = "numeric_mean": Calculate arithmetic means for all selected numeric target columns. - analysis_type = "text_summary": Collect non-empty text entries from all selected text target columns. - target_selection_rules: Select target columns by matching Mapping_File attributes. A rule value of null means: do not filter by this attribute. A list means: keep rows where the Mapping_File attribute is in the list. - row_filters: Apply row filters to document. Keys are data_category values from Mapping_File, such as "Plant", "Region", "Production Principle", "Season". Values are lists of accepted values.

В выбранном фрагменте указано:

• Какую операцию анализа необходимо выполнить ( analysis_type )?
• как выбираются релевантные целевые столбцы из файла Mapping_File ( target_selection_rules ),
• и как фильтруется набор данных для оценки перед проведением анализа ( row_filters ).

Данная инструкция намеренно детерминирована. P_Analysis_Engine не имеет права переинтерпретировать исходный запрос пользователя или создавать дополнительные аналитические операции.

После блока инструкций P_Analysis_Engine получает сам скрипт Python. Полный скрипт содержит более 300 строк кода и является частью инструкции запроса ИИ. Ссылка на него приведена в начале этой главы, и его можно скачать. Многие строки кода не имеют концептуального значения для архитектуры. Они отвечают за практическую устойчивость: очистку имен столбцов, нормализацию входных значений, обработку отсутствующих столбцов, преобразование объектов-оболочек Copilot и возврат структурированных сообщений об ошибках.

В данной статье я сосредоточусь только на центральной логике.

Первым важным шагом является загрузка системой загруженных данных оценки (теперь доступных в document ) и файла Mapping_File ). С этого момента LLM больше не интерпретирует запрос пользователя. Она выполняет только детерминированный скрипт на основе правила Selection_Rule ).

 mapping_df = pd.read_excel(Mapping_File) data_df = pd.read_excel(document) mapping_df = strip_column_names(mapping_df) data_df = strip_column_names(data_df)

Ключевым архитектурным элементом является выбор целевых столбцов. P_Analysis_Engine никогда не угадывает, какие столбцы Excel могут быть релевантными. Вместо этого он фильтрует Mapping_File в соответствии с атрибутами, определенными в target_selection_rules .

 target_mapping = mapping_df.copy() for attr, rule_value in target_selection_rules.items(): values = normalize_rule_value(rule_value) values = normalize_list_for_matching(values) if values is None: continue target_mapping = target_mapping[ target_mapping[attr] .apply(normalize_for_matching) .isin(values) ] selected_target_columns = ( target_mapping["source_column_name"] .dropna() .tolist() )

На этом этапе абстрактная инструкция по анализу становится конкретной. Например, правило типа chapter_id = ["3.5"] , data_category = ["chapter_score"] и aggregation_allowed = ["mean"] преобразуется в фактические столбцы Excel, содержащие оценки зрелости концепции и выполнения для главы 3.5.

Тот же принцип применяется и к фильтрам строк. Опять же, система ничего не выводит из естественного языка. Она применяет только фильтры, явно указанные в Selection_Rule ).

 filtered_df = data_df.copy() for filter_category, filter_values in row_filters.items(): filter_mapping = mapping_df[ mapping_df["data_category"] .apply(normalize_for_matching) == normalize_for_matching(filter_category) ] filter_col = filter_mapping["source_column_name"].iloc[0] filtered_df = filtered_df[ filtered_df[filter_col] .apply(normalize_for_matching) .isin(values) ]

После выбора столбцов и фильтрации строк логика анализа намеренно упрощается. Для анализа зрелости числового уровня механизм вычисляет среднее арифметическое для всех выбранных целевых числовых столбцов.

 if analysis_type == "numeric_mean": numeric_result = {} for col in available_target_columns: series = pd.to_numeric(filtered_df[col], errors="coerce") valid_count = int(series.notna().sum()) numeric_result[col] = { "mean": float(series.mean()) if valid_count > 0 else None, "valid_count": valid_count } result["result"] = numeric_result

Для текстового анализа система собирает непустые утверждения оценщиков вместо вычисления значений.

 elif analysis_type == "text_summary": text_result = {} for col in available_target_columns: values = [ clean_text_value(v) for v in filtered_df[col].tolist() ] values = [v for v in values if v is not None] text_result[col] = { "entries": values, "entry_count": len(values) } result["result"] = text_result

В итоге результат возвращается в формате JSON. Это важно, поскольку выходные данные пока не являются окончательным ответом для пользователя. Это надежная аналитическая основа для следующего шага LLM: интерпретации от родительского агента.

 print(json.dumps(result, indent=2, ensure_ascii=False))

Такая конструкция намеренно делает P_Analysis_Engine «скучным». Он не рассуждает, не объясняет и не улучшает анализ. Он только выполняет действия. И в этом вся суть. Чем более детерминированным является этот слой, тем больше доверия можно оказать последующей интерпретации, сгенерированной LLM.

5. Пример сквозного анализа.

Чтобы проиллюстрировать весь рабочий процесс, рассмотрим реалистичный пример, демонстрирующий весь конвейер обработки данных.

В ответ на взаимодействие с пользователем родительский агент может отправить в модуль аналитики следующую Parent_Instruction :

«Обобщите основные возможности улучшения, предусмотренные в главе 1.4 «Система предотвращения отказов на предприятии AbcP».»

Для человека этот запрос выглядит простым, но он уже содержит в себе множество семантических задач:

• определить запрашиваемые главы для оценки,
• определить запрошенный тип контента,
• применить фильтр по строкам,
• получить правильные текстовые столбцы,
• сводный текстовый анализ результатов,
• и, наконец, сгенерировать осмысленную интерпретацию ( → родительский агент).

Это именно тот тип задач, где анализ, основанный исключительно на LLM, становится ненадежным. Поэтому система разделяет рабочий процесс на детерминированные этапы выполнения и вероятностные этапы интерпретации.

5.1 Перевод из Analysis Planner

Первый шаг выполняется программой P_Analysis_Planner .
Он преобразует запрос на естественном языке в детерминированное правило Selection_Rule .

 { "status": "success", "parent_instruction_summary": "Summarize improvement potentials for chapter 1.4 Failure Prevention System in plant AbcP.", "selection_rule": { "analysis_type": "text_summary", "target_selection_rules": { "data_category": ["potential"], "aggregation_allowed": ["summary"], "concept_execution": null, "chapter_id": ["1.4"] }, "row_filters": { "Plant": ["AbcP"] } }, "warnings": [] }

В Selection_Rule уже содержится полная спецификация детерминированного анализа:

• analysis_type = "text_summary"
  указывает на необходимость сбора текстовых данных, полученных от экспертов, вместо числовых расчетов.
• data_category = ["potential"]
  ограничивает анализ потенциалом для улучшения.
• chapter_id = ["1.4"]
  Анализ ограничивается главой, посвященной системе предотвращения отказов.
• row_filters = {"Plant": ["AbcP"]}
  ограничивает набор данных только запрошенным растением.

На данном этапе анализ данных еще не проводился. Результатом является лишь инструкция по выполнению следующего шага.

5.2 Выполнение из аналитического механизма

Это Selection_Rule передается в P_Analysis_Engine для выполнения. Сначала движок выбирает все соответствующие целевые столбцы из Mapping_File ).

 target_mapping = target_mapping[ target_mapping[attr] .apply(normalize_for_matching) .isin(values) ]

Это преобразует абстрактные критерии отбора в реальные столбцы набора данных, например:

 selected_target_columns = [ "1.4 CON L2 Improvement potentials", "1.4 CON L3 Improvement potentials", "1.4 EXE L2 Improvement potentials", "1.4 EXE L3 Improvement potentials" ]

Далее применяются фильтры строк:

 filtered_df = filtered_df[ filtered_df[filter_col] .apply(normalize_for_matching) .isin(values) ]

В этом примере набор данных сводится к строкам оценок, относящимся к растению AbcP.

Наконец, система собирает все непустые текстовые записи из выбранных столбцов.

 values = [ clean_text_value(v) for v in filtered_df[col].tolist() ] values = [v for v in values if v is not None]

Как мы видим, система не интерпретирует полученные данные. Она лишь извлекает и структурирует их в соответствии со скриптом на языке Python.

Результатом работы системы является набор письменных заключений экспертов о потенциале улучшения потока ценностей, представленный в формате JSON.

 { "entry_count": 6, "entries": [ "Root causes are not systematically tracked.", "Escalation rules for recurring failures are unclear.", "Lessons learned are not transferred between shifts.", "Preventive maintenance findings are not integrated into CIP activities.", "Failure trends are visualized inconsistently.", "Problem-solving activities focus mainly on symptoms instead of root causes." ] }

На данном этапе система еще не сгенерировала никаких рекомендаций. Она выдала лишь достоверный набор соответствующих результатов оценки. Этот JSON-объект возвращается родительскому агенту для интерпретации и генерации окончательного ответа пользователю.

5.3 Интерпретация от родительского агента

На заключительном этапе родительский агент собирает все ответы (возможно, дополнительные ответы от подчиненных агентов) и генерирует окончательный результат.

 The collected findings indicate that the Failure Prevention System is currently more reactive than preventive. Most gaps are related to missing systematic root-cause management and weak organizational learning across shifts and teams. The highest leverage improvements would likely come from strengthening escalation routines, integrating preventive maintenance findings into CIP activities, and establishing consistent cross-shift learning mechanisms.

Подводя итог основной архитектурной идее системы:

Метод LLM больше не создает аналитическую основу самостоятельно. Вместо этого он интерпретирует детерминированный набор уже подтвержденных результатов.

Вероятностные способности модели LLM используются там, где они приносят пользу: для интерпретации, определения приоритетов, объяснения и коммуникации, а не для самой обработки данных.

6. Почему архитектура ИИ важна

Большие языковые модели от природы сильны в интерпретации, рассуждениях и генерации языка, но всё ещё слабы в надёжном численном анализе. Их целью оптимизации является правдоподобие, а не детерминированная воспроизводимость. Даже с такими расширениями, как «Интерпретатор кода», эта слабость остаётся заметной в более сложных аналитических сценариях.

Хорошая новость заключается в том, что это ограничение в значительной степени можно компенсировать за счет интеллектуальной архитектуры системы. Ключевым моментом является четкое разделение обязанностей: детерминированные уровни обработки данных обеспечивают аналитическую основу, в то время как LLM-ы сосредотачиваются на интерпретации, приоритизации, объяснении и коммуникации.

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

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

Инго Новицки. Все работы Инго Новицки.

Источник: towardsdatascience.com