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

Стоит отметить, что “возникающие способности” (emergent abilities) языковых моделей, с одной стороны основаны на большом массиве знаний человечества и, с другой стороны, на текущем уровне понимания человечества являются, вообще говоря, необъяснимыми и непрогнозируемыми. Выглядит так, что языковые модели “смогли” разложить знания человечества на элементарные составляющие так, что дальнейшее “прибавление” осмысленной информации, дает прирост “силы” возникших способностей. Однако, по всей видимости, для текущей науки и философии, структура этих элементарных составляющих до сих пор остается неизвестной. В этом смысле, языковые модели уже опережают человечество в том, что можно назвать “пониманием” знания.

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

Для работы на уровне знаний, формулировки мета-знания и разработки инструментов оптимизации знаний разрабатывается мини-фреймворк core-kbt (KBT = Knowledge Base Trajectory). Пытаемся снимать сложность познания мета-знаний по-слоям, шага за шагом. В данный статье опишем только базовую информацию о core-kbt мини-фреймворке и подробнее остановимся на пример решения задачи объективного выбора лучшего из двух вариантов.

Текущие подходы в core-kbt

Текущие фичи и подходы в core-kbt тезисно:

  • архитектура ИИ-функций (AI-functions): возможность разработки интеллектуальных функций через написание теймплейтов для LLM-промпта и JSON Schema ответа, представленные как отдельные файлы

  • архитектура для вычисления ИИ-функций через “процессы”, которые упрощают кеширование и анализ ответов от LLM-провайдеров, и ускоряют цикл разработки, при возникновении ошибок

  • универсальное представление LLM-промпта в структурированном виде

  • онтология представление мета-знаний

  • реализация конкретных ИИ-функций: группа развития знаний

  • реализация конкретных ИИ-функций: группа развития мета-знаний.

Полезные примеры интеграции core-kbt:

  • интеграция с Obsidian для развития знаний: https://github.com/ady1981/obsidian-templater-core-kbt

  • а также пример решения задачи обоснованного выбора лучшего из двух вариантов и интеграция с n8n.

Репозиторий с кодом core-kbt: Ссылка

Архитектура ИИ-функций (AI-functions)

ИИ-функций - это интеллектуальные функции, с четко определенными схемами вводных и выходных данных. Предлагается реализовывать ИИ-функции как “интеллектуальные” универсальные модульные компоненты. Существует два способа реализации функций ИИ:

  1. Шаблон Jinja2: Шаблон LLM-промпта для LLM.

  2. Модуль Python: Функция Python, которая может содержать произвольную логику, включая вызовы других ИИ-функций и вызов внешних API.

Схема выходных данных задается с помощью JSON Schema. Эта схема подставляется в итоговый LLM-промпт и таким образом у LLM запрашивается ответ в формате, заданном этой схемой. Сервер Flask предоставляет эти функции через RESTful API, обрабатывая авторизацию и отправку. См. примеры реализаций ИИ-функций ниже.

Универсальное представление LLM-промпта в структурированном виде

Для того, чтобы получить ответ от LLM нужно для задачи создать LLM-промпт. Понятно, что для конкретной задачи мы хотим получить самый оптимальный LLM-промпт для максимально “правильного” ответа. Так же известно, что LLM, основанная на текущей архитектуре, каждый раз решает только одну задачу - generatively-continue-prompt. Для решения проблемы создания самого оптимального LLM-промпта предлагается следующий подход:

  1. сформулируем generatively-continue-prompt в максимально общем виде, с корректным выделением всех логических частей

  2. все логические части будем описывать в терминах аспектных свойств и значений. Получилось следующее универсальное представление LLM-промпта в структурированном виде:

LLM_prompt:
    prompt_structure_and_notation_self_specification: []  
    target_specification:  
    - task_specification  
    - target_semantic_specification  
    information_retrieval_strategy:  
    - context_knowledge_specification:  
      - context_knowledge_topic  
      - context_knowledge_source:  
          - properties  
          - content  
    - knowledge_sources_selection_strategy  
    - context_preparation_strategy  
    - contextual_alignment_strategy
    - contextual_memory_strategy  
    - ...  
    output_generation_strategy:  
    - execution_plan_specification  
    - task_decomposition_specification  
    - knowledge_consolidation_specification  
    - evaluation_metrics  
    - iteration_and_refinement_strategy  
    - examples  
    - safety_and_ethics_specification  
    - post_generation_verification_specification  
    - ...  
    output_specification:  
    - structure_and_formatting_specification  
    - output_constrains_specification  
    - output_content_strategy  
    - ...

“Универсальность” промпта означает, что какова бы ни была задача пользователя, можно сформулировать промпт для LLM в этом виде. Логические блоки предлагается определять через аспектные признаки и значения, и это позволит, если использовать продуманную систему аспектов, итеративно прийти к максимально эффективному LLM-промпту. Систему аспектов можно создать по теории Логики. Такой подход можно назвать логическо-аспектным подходом к LLM-промптингу. На примере решения задачи объективного выбора лучшего из двух вариантов можно увидеть, что такой подход является эффективным.

Реализация ИИ-функций: группа развития знаний

Приведем примеры ИИ-функций, которые можно объединить в “группу развития знаний”.

ИИ-функция

Описание

Описание входных данных

Описание выходных данных

Примеры решаемых задач

generate

общий вид генерации ответа

Спецификация требуемой цели, спецификация контекста знаний, стратегия поиска знаний, стратегия генерации, уточнение спецификации формата ответа

Список ответов

- генерация примера по описанию- генерация ревью- генерация краткого изложения- определение термина по описанию

factual_question_answering

ответ на фактологический вопрос

Вопрос, спецификация контекста знаний

Список ответов, с указанием источника информации

incontext_question_answering

ответ на фактологический вопрос в заданной информации

Вопрос, спецификация контекста знаний

Список ответов, с указанием ссылки на фрагмент-источник

aspected_analyze

Аспектный анализ заданной информации

Заданная информация, спецификация контекста знаний

Список значений аспектных признаков

aspected_commonality_analyze

В каких аспектах заданные 2 сущности совпадают

Две сущности для сравнения, спецификация контекста знаний

Список значений общих аспектных признаков

aspected_devergence_analyze

В каких аспектах заданные 2 сущности различаются

Две сущности для сравнения, спецификация контекста знаний

Список значений различающихся аспектных признаков

rewrite

Переписать информацию по заданным примерам, с сохранением смысла

Заданная информация, примеры, спецификация контекста знаний

Переписанная информация

aspected_rewrite

Переписать информацию, с сохранением требуемых аспектов

Заданная информация, спецификация требуемой цели, спецификация контекста знаний

Переписанная информация, измененные аспектные признаки

disjoint_sequence_item_generation

Дополнить последовательность новыми элементами

Последовательность элементов, спецификация контекста знаний

Новые элементы

group_identification

Определение того, как называется группа (или класс), к которому принадлежат заданные элементы

Последовательность элементов, спецификация контекста знаний

Название группы

Отметим, что для всех текущих Templater-теймплейтов в Obsidian достаточно только этой группы ИИ-функций.

Пример решения задачи обоснованного выбора лучшего из двух вариантов и интеграция с n8n

Рассмотрим следующую задачу: допустим пользователю нужно обоснованно выбрать лучший вариант из двух альтернатив. Предложим универсальный подход к этой задаче и покажем как этот подход реализован с помощью core-kbt и n8n. Для примера возьмем такую задачу. Владельцу будущего продукта нужно выбрать веб-фреймворк по такому описанию:

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

  • Вариант A: FastAPI (Python)

  • Вариант B: Gin (Go)

С точки зрения Логики задача раскладывается и представляется следующим образом. Необходимо определить аспектные признаки для понятия, которое “объединяет” варианты А и B. Эти аспектные признаки должны быть определены корректный способом из требований пользователя и всех остальных обязательных требований, для фиксации значений всех существующих в задаче степеней свободы. В самом общем виде для определения аспектных признаков для понятия требуется задать:

  • понятие (concept)

  • контекст рассмотрения (frame of reference)

  • точку зрения наблюдателя (point of view)

  • стратегия ракурса рассмотрения наблюдателя (perspective observer strategy).

Соответственно, для решения задачи требуются следующие ИИ-функции:

  • идентификации вышестоящего общего понятия (см. ИИ-функцию superordinate_concept_identification)

  • определение аспектных признаков, одновременно с определением точки зрения наблюдателя (the point of view) и стратегии ракурса рассмотрения наблюдателя, из описания контекста задачи (см. ИИ-функцию perspective_features). Дополнительно к аспектным признакам мы также попросим LLM-модель оценить вес каждого аспекта по сравнению с остальными аспектами и вес каждого признака внутри аспекта по сравнению с остальными признаками

  • сравнение понятий (вариантов) по значению аспектных признаков, в форме значения (см. ИИ-функцию perspective_feature_comparison):

    • значение “+1” - если Вариант A лучше Варианта B по этому аспектному признаку

    • значение “-1” - если Вариант A хуже Варианта B по этому аспектному признаку

    • значение “0” - если Вариант A невозможно сравнить с Вариантом B по этому аспектному признаку

Имея значения весов (score) аспектов среди остальных аспектов, весов признаков внутри аспекта и результат сравнения признаков, итоговый результат сравнения вариантов А и B вычисляется уже точно как взвешенная сумма значения сравнения признаков.

Эта логика решения задачи реализована в ИИ-функции concept_aspect_comparison.

Текущая реализация ИИ-функций особенно эффективна в связке с инструментами интеграции типа n8n. Для n8n разработан пример workflow, в котором входные данные для ИИ-функций берутся из Input Data Table и результат вычисления ИИ-функций вставляется в соответствующую Output Data Table. Для запуска concept-comparison workflow будут полезны следующие шаги:

  • запустить core-ktb сервер, например на порту 5001, см. README.ru.md

  • в n8n:

    • сделать “import from file” для файла examples/n8n/concept-comparison.json

    • создать Input Data Table по примеру файла examples/n8n/concept-comparison-input.csv

    • создать Output Data Table по примеру файла examples/n8n/concept-comparison-output.csv

    • исправить связи в своём concept-comparison workflow, чтобы на шаге “Read input table” было чтение из соответствующей concept-comparison-input таблице, и на шаге “Update output table” была запись в соответствующую таблицу concept-comparison-output

  • concept-comparison workflow готов к работе. Для запуска необходимо:

    • задать свои входные данные:

      • задать свою ситуацию в поле observer_context_description

      • задать варианты в полях a_concept и b_concept

      • задать название модели LLM в поле LLM_model

    • запустить worklow

    • результат вычисления ИИ-функции concept_aspect_comparison представится в табличном виде и запишется в concept-comparison-output.

Скриншот с примером результата вычислений:

Комментарии к таблице concept-comparison-output:

  • итоговый результат сравнения пишется в строку типа model_total:

    • в колонках a_concept_winner, b_concept_winner - отмечен итоговый вариант-победитель, набравший больше баллов в процентах, по сравнению с альтернативой

    • в колонке message указывается победитель текстом и пишутся детали задачи

    • в колонке a_concept_score - итоговый нормированный балл a_concept в процентах

    • в колонке b_concept_score - итоговый нормированный балл в процентах, обратный к a_concept

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

В итоге, есть готовая универсальная ИИ-функции concept_aspect_comparison и пример её интеграции в n8n workflow. Где, под универсальностью понимается, что эта функция решает конкретную задачу с фиксацией всех необходимых и достаточных признаков для этой задачи.

Предложения, отзывы и любая обратная связь приветствуется.