Меня зовут Антон, сейчас занимаюсь прикладными проектами индекса цифровой зрелости БРИКС. Пробую за счет инструментов ИИ собирать каскады моделей ИИ для выявления неочевидных зависимостей в разных экономических и культурных процессах на основе данных извлекаемых из открытых источников.
В рамках эксперимента я поставил себе задачу применить ИИ в прикладной задаче, при этом использовать только доступные всем инструменты и понятные нарративы. Одним словом, решил примерить на себя роль «Сделай там что-то с ИИ-шечкой, только быстро!» Рассказываю, что из этого поучилось (ссылки на рабочие блокноты, промпты и скриншоты прилагаются).
Для честности эксперимента отмечу, что с ИИ опыт имею, поэтому эксперимент не совсем чистый, но тем не менее позволяет понять: что, как и куда вкручивать для получения приемлемого результата. Я старался действовать так, если бы мой уровень знаний предметной области был на начальном пользовательском уровне, а опыт практической работы с ИИ-инструментами заключался в использовании пользовательских промптов. Обязательным условием было то, что можно использовать только знания, «добытые в бою», т. е. полученные в процессе реализации текущего проекта. Базовые знания, которыми обладает условный пользователь, я определил способностью заходить в интерфейс DeepSeek/Perplexity и запускать Google Colab.
Целью эксперимента я выбрал попытку реализации такой схемы работы с LLM:
Весь эксперимент был разделен на 5 этапов, каждый по 8 часов.
Этап 1. Разработка прототипа чат-бота на базе LLM с RAG
Цель: реализовать в Google Colab прототип чат-бота на базе LLM с RAG, используя доступные библиотеки (Hugging Face, LangChain и др.), который не менее чем на 70% соответствует представленной выше схеме.
Задачи:
Освоить работу в Google Colab.
Реализовать RAG-архитектуру.
Интегрировать LLM.
Реализовать механизм хранения контекста диалога.
Способ реализации:
Поэтапная разработка с использованием:
Deepseek и ChatGPT для генерации шаблонного кода.
Готовых решений с GitHub, Habr и Medium.
Документации LangChain и Hugging Face.
Тестирование отдельных компонентов:
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 (ссылка на блокнот) со следующими характеристиками:
Основной функционал:
Загружает и обрабатывает PDF-документы, извлекая текст по страницам.
Разбивает текст на чанки (фрагменты) для индексации.
Создает векторное хранилище (FAISS) с эмбеддингами для поиска по смыслу.
Получает пользовательский запрос и формирует уточненный вопрос с учетом истории.
Извлекает релевантный контекст из FAISS и подает его в LLM (Groq API).
Модель генерирует ответ с опциональным блоком thinking (размышления).
Выводит интерактивный UI с диалогом.
Технические параметры:
Используется модель 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. Чат-бот предложил следующие решения:
Улучшить промпт для QA (qa_system_prompt).
Усилить контекстный ретривер.
Изменить 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).
Провести анализ ответов по двум критериям: полнота и детализация.
Способ реализации:
Реализован алгоритм перебора комбинаций значений параметров в Google Colab с доступом к deepseek/distilled-llama-70b через API Groq и OpenRouter, каждый из которых:
подает на вход фиксированный test_prompt;
использует уникальную комбинацию chunk_size и n;
сохраняет полученный ответ LLM и параметры запуска.
Обработка ограничений 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).
Провести анализ ответов по двум критериям: полнота и детализация.
Способ реализации:
Доработан алгоритм перебора комбинаций значений параметров в Google Colab с доступом к deepseek/distilled-llama-70b через API Groq и OpenRouter, каждый из которых:
подает на вход фиксированный test_prompt;
использует уникальную комбинацию chunk_size и n;
сохраняет полученный ответ LLM и параметры запуска.
Обработка ограничений 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-метриками:
Выводы
F1-метрика надежно коррелирует с качеством ответов и может использоваться как прокси-показатель релевантности.
Методика позволяет сравнивать конфигурации генерации ответов и выбрать оптимальные параметры RAG-системы на основании объективной оценки.
Полученное значение ROC-AUC = 0.786 — хороший уровень качества модели:
Модель хорошо различает классы.
Качество ответом модели выше среднего.
Модель можно использовать в реальной задаче.
Вместо заключения
Итого, за 40 часов я постарался пройти путь от «вот проблема, что делать?» до осознанного применения инструментов и их практической реализации инструментами «ноу-код» (ну или как еще назвать ситуацию, когда код переносится в редактор через копипаст, не вчитываясь в детали?)
Оценивания конкретную реализацию могу сказать, что ROC-AUC значение — 0.76, и это приемлемая точность модели. Сравнивали relevance, рассчитанный как косинусная схожесть между эталоном и реальным ответом, и значение F1. Модель можно использовать, качество ответов в среднем выше среднего.
Это получился довольно интересный практический опыт реализации небольшого прикладного проекта в режиме ноу-код, с практически нулевого уровня знаний. Дотошный читатель может сказать, что не пахнет в проекте 40 часами, и будет прав. Большая часть времени уходила на ожидание результатов (до 12 часов длились некоторые сессии запросов/ответов моделей) и подходы к решению реальных задач.
Остальную оценку оставляю на вас, уважаемые читатели.
Автор: Пчелинцев Антон Сергеевич — специалист в стратегическом управлении на основе данных, руководитель проекта индекса цифровой зрелости БРИКС при ИМАШ РАН, эксперт онлайн-магистратур МФТИ, Центр «Пуск»
