Меня зовут Антон, сейчас занимаюсь прикладными проектами индекса цифровой зрелости БРИКС. Пробую за счет инструментов ИИ собирать каскады моделей ИИ для выявления неочевидных зависимостей в разных экономических и культурных процессах на основе данных извлекаемых из открытых источников. 

В рамках эксперимента я поставил себе задачу применить ИИ в прикладной задаче, при этом использовать только доступные всем инструменты и понятные нарративы. Одним словом, решил примерить на себя роль «Сделай там что-то с ИИ-шечкой, только быстро!» Рассказываю, что из этого поучилось (ссылки на рабочие блокноты, промпты и скриншоты прилагаются).

Для честности эксперимента отмечу, что с ИИ опыт имею, поэтому эксперимент не совсем чистый, но тем не менее позволяет понять: что, как и куда вкручивать для получения приемлемого результата. Я старался действовать так, если бы мой уровень знаний предметной области был на начальном пользовательском уровне, а опыт практической работы с ИИ-инструментами заключался в использовании пользовательских промптов. Обязательным условием было то, что можно использовать только знания, «добытые в бою», т. е. полученные в процессе реализации текущего проекта. Базовые знания, которыми обладает условный пользователь, я определил способностью заходить в интерфейс DeepSeek/Perplexity и запускать Google Colab. 

Целью эксперимента я выбрал попытку реализации такой схемы работы с LLM:

Весь эксперимент был разделен на 5 этапов, каждый по 8 часов.

Этап 1. Разработка прототипа чат-бота на базе LLM с RAG

Цель: реализовать в Google Colab прототип чат-бота на базе LLM с RAG, используя доступные библиотеки (Hugging Face, LangChain и др.), который не менее чем на 70% соответствует представленной выше схеме.

Задачи:

• Освоить работу в Google Colab.

• Реализовать RAG-архитектуру.

• Интегрировать LLM.

• Реализовать механизм хранения контекста диалога.

Способ реализации:

1. Поэтапная разработка с использованием:

   • Deepseek и ChatGPT для генерации шаблонного кода.

   • Готовых решений с GitHub, Habr и Medium.

   • Документации LangChain и Hugging Face.

2. Тестирование отдельных компонентов:

   • Deepseek и ChatGPT для генерации шаблонного кода.

   • Готовых решений с GitHub, Habr и Medium.

   • Документации LangChain и Hugging Face.

Путь самурая, или шаг за шагом непонятно куда

Шаг 1. Изучил рабочую схему с помощью DeepSeek и Perplexity. Попросил нейросети рассказать, что на ней находится. Получил такой ответ: 

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

Шаг 2. Проанализировал схему. Уточнил у чат-бота: 

«Проанализируй приложенную схему и расскажи 1. Схема какого процесса на ней изображена. 2. Как работает каждый элемент в пайплайне на схеме (поэтапно): для чего он нужен, что он делает, что получает на вход, как обрабатывает информацию, что отдает на выход».

Из ответа узнал следующее:

• На схеме представлен классический конвейер Retrieval-Augmented Generation (RAG) с этапом препроцессинга запроса и отбором релевантных фрагментов перед финальной генерацией ответа.

• Верхнеуровнево процесс состоит из следующих пунктов:

  • LLM (реформулировка, Reformulation) — объединение нового запроса и истории сообщений + превращение в «самодостаточный» единый запрос.

  • VectorStore (векторный поиск, Vector Search) — поиск в векторном хранилище наиболее близких по смыслу фрагментов документов (чанки).

  • LLM (фильтрация, Chunk Selection) — остаются только упорядоченные чанки, которые действительно дополняют единый запрос.

  • LLM (контекстная генерация, Contextual Answer Gen) — из чанков формируется контекст и генерируется ответ на «обогащенный» запрос.

  • LLM (постобработка ответа, Polish & Format) — проверяется стилистика и тон ответа, уточняются формулировки и т. д.

Шаг 3. Запросил у чат-бота рабочий код для реализации задачи. Для этого сформировал новый запрос: 

«Нужно в течение 8 часов реализовать представленную схему в виде работающего проекта на Google Сolab. Все используемые инструменты должны быть бесплатными, а сам проект полностью реализован в Google Colab. Требование к LLM — легкая, предобученная, поддержка русского языка. Предложи мне 1. План реализации этой задачи, 2. Опиши пайплайн и все ключевые компоненты. Напиши максимально понятный и подробно закомментированный рабочий код на Python, который реализует эту задачу в Google Colab и использует только облачные ресурсы Google Colab»

Изучил предложенный код и поэтапно перенес его в Google Colab. Код работал, но не все было понятно. 

Шаг 4. Погрузился в тему и внес изменения. В процессе погружения я изучал предметную область: встречающиеся ключевые понятия и то, как происходит преобразование информации. Во время изучения сторонних материалов нашел статью Memory-Enhanced RAG Chatbot with LangChain: Integrating Chat History for Context-Aware Conversations, в которой подробнейшим образом расписывается процесс реализации подобной задачи. 

Статья показалась мне полностью понятной. Опубликованная в ней блок-схема очень помогла разобраться в процессе:

Код из этой статьи лег в основу моей реализации чат-бота. Я поблочно перенес код в свой блокнот, добавил комментарии, текстовые блоки. Убедился, что все блоки работают и код выполняется без ошибок. Составил и прочекал технический стек — все элементы совместимые, подходят под выбранные задачи и рекомендуются к использованию.

Шаг 5. Протестировал функционал. Когда начал тестировать функционал, появились ошибки. Исправили их вместе с чат-ботом: 

• нашли несколько логических ошибок; 

• подкорректировал текст основного промпта qa_system_prompt (модель сначала использует FAISS, но при отсутствии релевантного контекста отвечает из своих знаний);

• сделали более дружелюбный и приятный UI.

Встретился с первым ограничением Groq AI — лимитом по количеству токенов в минуту для выбранной модели deepseek-r1-distill-llama-70b (не более 6000). 

Исправил все ошибки и недостатки, которые выплыли во время тестирования.

Результаты

Реализован работающий прототип в Google Colab (ссылка на блокнот) со следующими характеристиками:

1. Основной функционал:

   • Загружает и обрабатывает PDF-документы, извлекая текст по страницам.

   • Разбивает текст на чанки (фрагменты) для индексации. 

   • Создает векторное хранилище (FAISS) с эмбеддингами для поиска по смыслу. 

   • Получает пользовательский запрос и формирует уточненный вопрос с учетом истории. 

   • Извлекает релевантный контекст из FAISS и подает его в LLM (Groq API). 

   • Модель генерирует ответ с опциональным блоком thinking (размышления).

   • Выводит интерактивный UI с диалогом.

2. Технические параметры:

   • Используется модель deepseek-r1-distill-llama-70b через Groq API.

   • Эмбеддинги создаются с помощью модели sentence-transformers/all-MiniLM-L6-v2.

   • Векторная база построена на FAISS.

   • Чанки текста: chunk_size=350.

   • История чата хранится в InMemoryChatMessageHistory.

   • UI построен на ipywidgets, с HTML-рендерингом сообщений.

   • Среднее время ответа: 2.8 секунды.

Выводы

Цель была достигнута: создан функциональный прототип, соответствующий представленной схеме.

Также подтверждена работоспособность ключевых компонентов:

• RAG-цепочка (загрузка → векторизация → поиск).

• Контекстный диалог.

• Интеграция LLM.

Этап 2. Повышение точности и полноты ответов реализованного чат-бота

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

Цель: за очередные 8 часов повысить точность и полноту ответа чат-бота на базе LLM с RAG на сложные пользовательские запросы с нелогичными элементами, достигая совпадения с эталонным ответом не менее чем на 90% по содержанию, используя настройку параметров системы и промпта LLM.

Задачи:

• Диагностировать причины некорректного ответа LLM на сложный и частично абсурдный запрос.

• Улучшить управляющий промпт.

• Подобрать оптимальные параметры chunk_size и search_kwargs в пайплайне.

• Оценить влияние изменений на полноту и точность ответа.

• Добиться воспроизведения эталонного ответа LLM.

Способ реализации:

• Промпт-инжиниринг: изменение системного промпта qa_system_prompt с акцентом на логический разбор запроса, выявление ошибок и строгую работу с контекстом.

• Тестирование различных параметров:

  • Увеличение размера фрагмента (chunk_size) для улучшения охвата информации.

  • Увеличение числа извлекаемых контекстов (search_kwargs = {"k": 10}) для усиления релевантности выдачи FAISS.

• Сравнительный анализ фактических и эталонных ответов.

Путь-то у самурая есть, но уже начинается появляться смысл

Шаг 1. Описал проблему и сформировал запрос к чат-боту: 

«При тестировании реализованного чат-бота на базе LLM с RAG обнаружил проблему. 

Пользовательский промпт: 

Кто герой книги The Girl on the Train и что он делал в Москве в 1861 году 31 декабря в 25 часов ночи? 

Ожидаемый (эталонный) ответ LLM: 

Герой книги The Girl on the Train — Rachel Watson. В контексте, который вы предоставили, нет упоминания о событиях в Москве. Обратите внимание: 25 часов ночи — неверный временной формат. 

Фактический ответ LLM: 

В контексте, который вы предоставили, нет упоминания о событиях в Москве. Книга "The Girl on the Train" Паулы Хокинс рассказывает о современных событиях и не связана с Москвой.

Проблемы:

1. Модель не извлекла героя книги явно.

2. Модель проигнорировала странность "25 часов ночи".

Предложи варианты решения проблемы»

Шаг 2. Чат-бот предложил следующие решения:

1. Улучшить промпт для QA (qa_system_prompt).

2. Усилить контекстный ретривер.

3. Изменить chunk_size.

Шаг 3. Последовательно реализовал предложенные варианты тем же способом, что и на этапе 1, и на третьем пункте был получен нужный результат.

Результаты

• На первом этапе улучшенный промпт позволил модели указывать на логические ошибки в запросе, но не был достаточно близок к эталонному.

• Изменение chunk_size с 350 до 500 не дало значимого улучшения.

• Увеличение search_kwargs до 10 обеспечило попадание нужного фрагмента текста в контекст и позволило LLM сформулировать полный, логичный и точный ответ.

Выводы

• Качество ответа LLM в RAG-системе существенно зависит от качества извлеченного контекста.

• Промпт играет ключевую роль в корректной интерпретации сложных запросов.

• Увеличение параметра search_kwargs до 10 оказалось ключевым для достижения точности.

• Модель при правильной настройке способна адекватно обрабатывать запросы с нелогичными элементами без генерации вымышленных фактов.

• Рекомендуется провести оценку влияния размера чанков и количества k-чанков на точность и полноту ответов чат-бота.

Этап 3. Оценка влияния размера чанков и количества k-чанков на точность и полноту ответов чат-бота в широком диапазоне значений

Цель: за очередные 8 часов оценить влияние параметров chunk_size и search_kwargs={"k": n} на полноту и качество ответа LLM при заданном сложном пользовательском запросе в широком диапазоне значений.

Задачи:

• Сформулировать сложный тестовый запрос (test_prompt) с фактологическими ловушками.

• Реализовать автоматический перебор всех комбинаций значений chunk_size в диапазоне min=100, max = 500, шаг = 50 и n (search_kwargs={"k": n}) в диапазоне min=5, max = 25, шаг = 5.

• Обеспечить пустой контекст при каждом запуске (test_prompt + релевантные чанки).

• Собрать и сохранить результаты в формате таблицы (.xlsx и .csv).

• Провести анализ ответов по двум критериям: полнота и детализация.

Способ реализации:

1. Реализован алгоритм перебора комбинаций значений параметров в Google Colab с доступом к deepseek/distilled-llama-70b через API Groq и OpenRouter, каждый из которых:

   • подает на вход фиксированный test_prompt;

   • использует уникальную комбинацию chunk_size и n;

   • сохраняет полученный ответ LLM и параметры запуска.

2. Обработка ограничений Google Colab и API-сервисов с помощью параллельных запусков.

Думал свет в конце тоннеля, а оказалось — светлячок заблудший

Шаг 1. Описал проблему и сформировал запрос к чат-боту (в контексте кода ранее реализованного чат-бота): 

«Напиши код программы, которая проводит 25 запусков вышеуказанного кода в блокноте Google Colab (автоматический перебор всех 25 комбинаций в одном Colab-блоке) со следующими параметрами:

1 для всех запусков — первым инициирующим сообщением диалога (история сообщений должна быть пустая, т. е. контекст пустой, финальный промпт qa_prompt содержит только пользовательский промпт и релевантные чанки, если они есть) вставляет пользовательский промпт: "Тут будет крутой пользовательский промпт".

Шаг 2. Сделал еще один запрос:

«Для каждого нового запуска изменяют значения:

а) chunk_size=x, где первое значение x = 100, а каждый последующий запуск добавляет x+100 (т.е. 100, 200, 300, 400, 500)

б) search_kwargs={"k": n}, где первое значение n = 5, а каждый последующий запуск добавляет n+5 (т.е. 5, 10, 15, 20, 25)

То есть должна получиться матрица 5 на 5 = 25 комбинаций chunk_size и search_kwargs={"k": n}.

Результатом работы должны стать таблица, содержащая следующие столбцы:

№ запуска | chunk_size=x | search_kwargs={"k": n} | Финальный сгенерированный ответ 

Например:

№ 1 | chunk_size=100 | search_kwargs={"k": 10} | "Прекрасный понятный детальный ответ от LLM"

Задача программы — автоматизация оценки полноты и детализации ответа LLM на одинаковый пользовательский запрос с пустым контекстом, но с разными значениями chunk_size и search_kwargs={"k": n}.

Пожалуйста, задавай мне уточняющие вопросы, если что-то непонятно»

Шаг 3. Перенес предложенный код в отдельный блок основного блокнота с кодом чат-бота. Код перебирает все комбинации chunk_size × k, пересобирает splitter, FAISS, retriever и QA-цепь, потом выполняет запрос "test_prompt без истории чата и сохраняет ответ LLM в файл.

Шаг 4. Провел тестирование реализованного функционала. 

Шаг 5. Исправил возникающие ошибки:

• Ошибка HTTP 413 (Request Too Large) Groq API — лимит по количеству токенов в минуту для выбранной модели deepseek-r1-distill-llama-70b (не более 6000). 

  Решение: переход на OpenRouter API с такой же моделью deepseek-distill-llama-70b и большим контекстным окном.

• Устаревшая версия ChatOpenAI из langchain.

• Реализовал безопасную передачу API-ключа через .env.

Результаты

• Сформированы тестовый промпт и эталонный ответ.

• Реализован работающий код для реализации цикла перебора комбинаций значений chunk_size и n (search_kwargs={"k": n}) в Google Colab (ссылка на блокнот).

• Разработана методология оценки полноты и детализация ответов.

• Собрана таблица с результатами отработки циклов: № запуска, chunk_size, k, ответ LLM (answer).

• Проведена автоматическая оценка каждого ответа по шкале от 1 до 5 по двум критериям: полнота ответа и детализация ответа.

• Проведена ручная оценка каждого ответа по шкале от 1 до 5 по двум критериям: полнота ответа и детализация ответа.

Приложения к этапу 3

Тестовый промпт и эталонный ответ:

Таблица с результатами оценки ответов LLM:

Выводы

• Автоматизация перебора параметров позволила стабильно и быстро провести серию тестов.

• На качество ответа влияют оба параметра (chunk_size и k).

• Наиболее точные и полные ответы LLM получаются при комбинации значений chunk_size в диапазоне 300–400 и n (search_kwargs={"k": n}) в диапазоне 10–20.

• Выбор оптимального сочетания параметров помогает улучшить полноту и точность ответов LLM при экономии ресурсов.

• Требуется провести оценку влияния размера чанков и количества k-чанков на точность и полноту ответов чат-бота в уточненном диапазоне значений.

Этап 4. Оценка влияния размера чанков и количества k-чанков на точность и полноту ответов чат-бота в уточненном диапазоне значений

Цель: за очередные 8 часов года оценить влияние параметров chunk_size и search_kwargs={"k": n} на полноту и качество ответа LLM при заданном сложном пользовательском запросе в уточненном диапазоне значений.

Задачи:

• Реализовать автоматический перебор всех комбинаций значений chunk_size в диапазоне min=350, max = 450, шаг = 10 и n (search_kwargs={"k": n}) в диапазоне min=10, max = 20, шаг = 1.

• Обеспечить пустой контекст при каждом запуске (test_prompt + релевантные чанки).

• Собрать и сохранить результаты в формате таблицы (.xlsx и .csv).

• Провести анализ ответов по двум критериям: полнота и детализация.

Способ реализации:

1. Доработан алгоритм перебора комбинаций значений параметров в Google Colab с доступом к deepseek/distilled-llama-70b через API Groq и OpenRouter, каждый из которых:

   • подает на вход фиксированный test_prompt;

   • использует уникальную комбинацию chunk_size и n;

   • сохраняет полученный ответ LLM и параметры запуска.

2. Обработка ограничений Google Colab и API-сервисов с помощью параллельных запусков.

Понятно, что ничего не понятно. И что теперь с этим делать?

Шаг 1. Описал проблему и сформировал запрос к чат-боту (в контексте ранее реализованного кода): 

«Измени код так, чтобы перебирались комбинации chunk_sizes от 350 до 450 с шагом 10 (350, 360, 370 … 450) и k_values от 10 до 20 с шагом 1 (10, 11, 12 … 20)»

Шаг 2. Добавил функционал RAG-доступа до файлов в облаке (чтобы не перезаливать файлы каждый раз, когда сессия заканчивается):

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

Шаг 3. Добавил функционал постоянной записи результатов в облаке (чтобы не терять результаты по окончании сессии):

«Измени код так, чтобы результаты записывались в файлы после каждой итерации, а сами файлы с результатами хранились в моем Google Drive. 

Пример файла: RAG_результаты_2025-05-22_14-03-12.xlsx»

Шаг 4. Реализовал код для параллельного запуска X сессий перебора комбинации значений:

«Хочу распараллелить выполнение на несколько сессий и покрыть все 121 комбинацию (11 chunk_sizes × 11 k_values) в X параллельных инстансах Colab, чтобы существенно ускорить прогон. Как это можно сделать наиболее просто? С учетом ограничения Colab на количество сессий от одного пользователя»

Шаг 5. Реализовал быстрый опрос 121 комбинаций параметров. Распараллелил 121 итерацию с учетом того, что надо было уложиться в 2 часа, а расчет одной комбинации занимает 17 минут. То есть за 2 часа я смог просчитать 7 комбинаций: использовал 6 аккаунтов Google (каждый аккаунт может создать 3 сессии Google Colab). Таким образом, за 2 часа один аккаунт сможет просчитать 3 * 7 = 21 комбинацию, и я должен покрыть все 121 вариантов за 2 часа.

Столкнулся с ограничением OpenRouter API на 30 запросов в день к LLM с одного аккаунта. Завел для каждой сессии (21 запросов) свой аккаунт.

Каждое внесение изменений в код проходило тестирование. Все ошибки исправлялись.

Результаты

• Доработан работающий код для реализации цикла перебора комбинаций значений chunk_size и n (search_kwargs={"k": n}) в Google Colab (ссылка на блокнот).

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

• Собрана таблица с результатами отработки циклов: № запуска, chunk_size, k, ответ LLM (answer).

Приложение к этапу 4

Таблица с результатами отработки циклов перебора комбинаций значений параметров:

Вывод

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

Этап 5. Оценка качества ответов LLM с использованием метрик F1 и ROC-AUC 

Цель: за заключительные 8 часов провести оценку применимости метрик F1 и ROC-AUC для объективного измерения качества ответов модели LLM c RAG.

Задачи:

• Рассчитать F1-метрики (Precision, Recall, F1) для всех ответов модели по отношению к эталонному.

• Интерпретировать результаты.

• Бинаризовать ответы по признаку релевантности на основе на основе косинусной схожести эталонного ответа (reference) и фактического ответа (answer).

• Вычислить ROC-AUC на основе F1 и бинарной релевантности.

• Построить ROC-кривую и рассчитать AUC.

• Интерпретировать результаты.

Способ реализации:

• Для каждого ответа модели рассчитаны: Precision, Recall, F1 — с использованием sklearn.metrics.

• Релевантность (relevance) определялась автоматически: ответ считается релевантным, если cosine similarity ≥ 0.285 (выбора адекватного порога для вычисления косинусной схожести на основе гистограммы).

• ROC-AUC рассчитывался по оси: y_score = F1, y_true = relevance.

• Построена ROC-кривая, отображающая соотношение TPR и FPR при различных порогах.

Этот запах напалма по утрам! Гори, крошка, гори!

Шаг 1. Описал проблему и сформировал запрос к чат-боту: 

«Цель моего проекта: оценить влияние параметров chunk_size и search_kwargs={"k": n} на полноту и качество ответа LLM с RAG при заданном сложном пользовательском запросе. Я получил Excel-таблицу со столбцами chunk_size - k - Финальный сгенерированный ответ. Теперь мне надо провести скоринг и оценить: 1. Точность и 2. Полноту ответов LLM. Для этого я хочу использовать метрику F1 score. Как это реализовать в Google Colab?»

Шаг 2. Подготовил эталонный (правильный) ответ.

Шаг 3. Подготовил CSV-файл с таблицей параметров для расчета F1-метрик.

Шаг 4. Произвел замену на простую токенизацию. Google Colab отказался работать с популярной библиотекой NLTK и после множества попыток это исправить, было решено отказаться от NLTK и заменить его на простую токенизацию.

Шаг 5. Попросил чат-бот проанализировать полученные данные и построить тепловую карту.

Шаг 6. Описал проблему и сформировал запрос к чат-боту: 

«Цель моего проекта: оценить влияние параметров chunk_size и search_kwargs={"k": n} на полноту и качество ответа LLM с RAG при заданном сложном пользовательском запросе. Я работаю в Google Colab. У меня имеются следующие артефакты:

- csv-таблица input_score.csv со столбцами chunk_size (цифры), k (цифры), answer (текст — финальный сгенерированный ответ LLM) 

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

- csv-таблица f1_score.csv – это таблица input_score.csv, обогащенная F1-метриками качества ответа LLM Precision, Recall, F1

Мне нужно:

1. Провести скоринг данных по ROC-AUC метрике; 

2. Объединить данные скоринга метрик F1 и ROC-AUC.

Результаты должны быть представлены как в виде таблиц с данными анализа, так и в визуальном виде – графики, карты. Как это реализовать в Google Colab?»

Шаг 6. Исправил ошибку «Only one class is present in y_true. ROC AUC score is not defined in that case». В массиве истинных меток (relevance) присутствует только один класс — все 1. Решение: выбор выбора адекватного порога для вычисления косинусной схожести на основе гистограммы: cosine similarity ≥ 0.285.

Шаг 7. Описал проблему и сформировал запрос к чат-боту: 

«Пожалуйста, рассчитай TPR и FPR построй ROC-кривую и вычисли площадь (AUC) для приложенной csv-таблицы с chunk_size, k, answer, Precision, Recall, F1, relevance, ROC_AUC. А также предложи вариант интерпретации полученных данных»

Результаты

• Разработан код для расчета F1-метрики (ссылка на блокнот).

• Разработан код для расчета ROC-AUC-метрики (ссылка на блокнот).

• Составлено заключение по результатам анализа расчетов метрик.

Приложения к этапу 5

Тепловая карта зависимости F1 от chunk_size и k:

ROC-кривая для метрики F1:

Таблица с результатами отработки циклов перебора комбинаций значений параметров, обогащенная F1 и ROC-AUC-метриками:

Выводы

1. F1-метрика надежно коррелирует с качеством ответов и может использоваться как прокси-показатель релевантности.

2. Методика позволяет сравнивать конфигурации генерации ответов и выбрать оптимальные параметры RAG-системы на основании объективной оценки.

3. Полученное значение ROC-AUC = 0.786 — хороший уровень качества модели:

• Модель хорошо различает классы.

• Качество ответом модели выше среднего.

• Модель можно использовать в реальной задаче.

Вместо заключения

Итого, за 40 часов я постарался пройти путь от «вот проблема, что делать?» до осознанного применения инструментов и их практической реализации инструментами «ноу-код» (ну или как еще назвать ситуацию, когда код переносится в редактор через копипаст, не вчитываясь в детали?)

Оценивания конкретную реализацию могу сказать, что ROC-AUC значение — 0.76, и это приемлемая точность модели. Сравнивали relevance, рассчитанный как косинусная схожесть между эталоном и реальным ответом, и значение F1. Модель можно использовать, качество ответов в среднем выше среднего. 

Это получился довольно интересный практический опыт реализации небольшого прикладного проекта в режиме ноу-код, с практически нулевого уровня знаний. Дотошный читатель может сказать, что не пахнет в проекте 40 часами, и будет прав. Большая часть времени уходила на ожидание результатов (до 12 часов длились некоторые сессии запросов/ответов моделей) и подходы к решению реальных задач. 

Остальную оценку оставляю на вас, уважаемые читатели. 

---

Автор: Пчелинцев Антон Сергеевич — специалист в стратегическом управлении на основе данных, руководитель проекта индекса цифровой зрелости БРИКС при ИМАШ РАН, эксперт онлайн-магистратур МФТИ, Центр «Пуск»