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

Стоит отметить, что “возникающие способности” (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-промптингу. На примере решения задачи объективного выбора лучшего из двух вариантов можно увидеть, что такой подход является эффективным.

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

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

Отметим, что для всех текущих 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. Где под универсальность понимается, что эта функция решает конкретную задачу с фиксацией всех необходимых и достаточных признаков для этой задачи.

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