|
Professor Seleznov
|
Для человека с большим профессиональным опытом в ИТ совершенно ясно, что уровень развития языковых моделей произвел революцию в мире информационных технологий. Появились новые информационные инструменты и, связанные с ними, новые прикладные разделы науки. Грядет пересмотр основ представления об информации, переоценка приоритетов и смыслов.
Стоит отметить, что “возникающие способности” (emergent abilities) языковых моделей, с одной стороны основаны на большом массиве знаний человечества и, с другой стороны, на текущем уровне понимания человечества являются, вообще говоря, необъяснимыми и непрогнозируемыми. Выглядит так, что языковые модели “смогли” разложить знания человечества на элементарные составляющие так, что дальнейшее “прибавление” осмысленной информации, дает прирост “силы” возникших способностей. Однако, по всей видимости, для текущей науки и философии, структура этих элементарных составляющих до сих пор остается неизвестной. В этом смысле, языковые модели уже опережают человечество в том, что можно назвать “пониманием” знания.
Стоит ожидать, что в скором времени в ИТ отрасли основную ценность будут иметь не код, не документация, и, к сожалению, не технические инженеры, а знания и мета-знания, т.е. знания о знаниях. ИТ отрасль уже пришла к пониманию, что “всё” эффективно представлять как код и следующий шаг будет состоять в том, что “код всего” будет вычисляться через знания, которые будут сами, в свою очередь, будут вычисляться и оптимизироваться из ядра знаний и мета-знаний. Поэтому название следующей “остановки” научного прогресса понятно - это мета-знания.
Для работы на уровне знаний, формулировки мета-знания и разработки инструментов оптимизации знаний разрабатывается мини-фреймворк core-kbt (KBT = Knowledge Base Trajectory). Пытаемся снимать сложность познания мета-знаний по-слоям, шага за шагом. В данный статье опишем только базовую информацию о core-kbt мини-фреймворке и подробнее остановимся на пример решения задачи объективного выбора лучшего из двух вариантов.
Текущие подходы в core-kbt
Текущие фичи и подходы в core-kbt тезисно:
- архитектура ИИ-функций (AI-functions): возможность разработки интеллектуальных функций через написание теймплейтов для LLM-промпта и JSON Schema ответа, представленные как отдельные файлы
- архитектура для вычисления ИИ-функций через “процессы”, которые упрощают кеширование и анализ ответов от LLM-провайдеров, и ускоряют цикл разработки, при возникновении ошибок
- универсальное представление LLM-промпта в структурированном виде
- онтология представление мета-знаний
- реализация конкретных ИИ-функций: группа развития знаний
- реализация конкретных ИИ-функций: группа развития мета-знаний.
Полезные примеры интеграции core-kbt:
Репозиторий с кодом core-kbt: Ссылка
Архитектура ИИ-функций (AI-functions)
ИИ-функций - это интеллектуальные функции, с четко определенными схемами вводных и выходных данных. Предлагается реализовывать ИИ-функции как “интеллектуальные” универсальные модульные компоненты. Существует два способа реализации функций ИИ:
- Шаблон Jinja2: Шаблон LLM-промпта для LLM.
- Модуль Python: Функция Python, которая может содержать произвольную логику, включая вызовы других ИИ-функций и вызов внешних API.
Схема выходных данных задается с помощью JSON Schema. Эта схема подставляется в итоговый LLM-промпт и таким образом у LLM запрашивается ответ в формате, заданном этой схемой. Сервер Flask предоставляет эти функции через RESTful API, обрабатывая авторизацию и отправку. См. примеры реализаций ИИ-функций ниже.
Универсальное представление LLM-промпта в структурированном виде
Для того, чтобы получить ответ от LLM нужно для задачи создать LLM-промпт. Понятно, что для конкретной задачи мы хотим получить самый оптимальный LLM-промпт для максимально “правильного” ответа. Так же известно, что LLM, основанная на текущей архитектуре, каждый раз решает только одну задачу - generatively-continue-prompt. Для решения проблемы создания самого оптимального LLM-промпта предлагается следующий подход:
- сформулируем generatively-continue-prompt в максимально общем виде, с корректным выделением всех логических частей
- все логические части будем описывать в терминах аспектных свойств и значений. Получилось следующее универсальное представление 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:
- 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. Где под универсальность понимается, что эта функция решает конкретную задачу с фиксацией всех необходимых и достаточных признаков для этой задачи.-Предложения, отзывы и любая обратная связь приветствуется.-Источник
|
