Проблемы
1. Плохо считается близость
Если посмотреть на то, какие вопросы подливаются в контекст mistral, то мне кажется, что близости (косинусные расстояния) считаются не точно, а раз так, то какой алгоритм по выбору похожих элементов из БЗ не выбирай, лучше не будет.
Пример:
cos(b[i], target) = 0.2
cos(b[j], target) = 0.4
cos(b[k], target) = 0.5
Оптимально брать b[k] с косинусной близостью 0.5, но кто сказал, что этот элемент, реально похож на target? Вдруг target = «Дик автомат», b[k] = «ДКА (детерминированный конечный автомат)», b[i] = «является ли язык Дика регулярным?», b[j] = «виды автоматов»?
Вывод: коммититься надо в подсчёт близких
2. Нет метрик качества
Относительно чего мы смотрим, что то или иное улучшение работает? Субъективное мнение, что «моделька выдаёт что-то похожее на правду»? А кто сказал, что это не случайность?
Метрика оценки качества нужна, причём их должно быть две:
- Метрика качества для поиска близких (здесь много чего можно попробовать улучшить, тут я потыкаюсь, когда будет хоть капля времени)
- Метрика по ответам mistral (можем улучшить только контекст / промт)
Вывод: надо ввести метрики (сейчас формулирую)
3. Версия модели не фиксирована
Каждый раз используется latest модель, зачем? Я считаю, что лучше зафиксировать одну модель, так будет проще отслеживать прогресс и получим хоть какой-то детерминизм (например: latest_prev имеет одну архитектуру, которая обращает внимание на первую часть предложения, а latest — другую, которая обращает внимание на вторую часть предложения, пример нереалистичный, но показательный)
Вывод: фиксируем версию mistral
4. Не оцениваем влияние новых вопросов
Сейчас мы просто вливаем вопросы, не трекая явно как какой вопрос влияет на работу системы. Кажется, что нужно это отслеживать, причём с двух строн:
- Не портится ли метрика поиска близких
- Не портится ли метрика ответов
mistral
Это может помочь в определение того, что делает вопрос «плохим»
Вывод: нужны автотесты
Лёша писал про них и делает их, метрику можно взять как количество вхождений важных слов и терминов в правильном и проверяемом предложении (допишу нормально)
Идея как получить больше юзер подобных вопросов тут (просто я при составлении датасета сама переформулировала без нейронки)
5. Не работаем с промтами к mistral
Вообще не работаем с промтами, а это ещё одна возможность улучшить ответы, задали один (вроде как) и всё.
Было написано по крайней мере две классные идеи, но почему-то забыты: про неуверенность и уточняющий вопрос
Вывод: после создания бейзлайна, надо двигаться в нескольких направлениях, включая промты
6. Нет проверки гипотез
Из-за того, что нет бейзлайна и метрик качества, которые давали бы понимание, какие действия ведут к успеху, а какие нет, нельзя проводить эксперименты / проверять гипотезы
Вывод: строим базу:
- Метод подбора близких (у меня есть идея на этот счёт: дообучить модель на текстах про тфя, чтобы улучшить поиск семантически близких)
- Метрика качества для близости
- Метрика качества для ответов
mistral
- Одна
mistral фиксированной версии
- Автотесты
Проблемы
1. Плохо считается близость
Если посмотреть на то, какие вопросы подливаются в контекст
mistral, то мне кажется, что близости (косинусные расстояния) считаются не точно, а раз так, то какой алгоритм по выбору похожих элементов из БЗ не выбирай, лучше не будет.Пример:
Оптимально брать
b[k]с косинусной близостью0.5, но кто сказал, что этот элемент, реально похож наtarget? Вдругtarget = «Дик автомат»,b[k] = «ДКА (детерминированный конечный автомат)»,b[i] = «является ли язык Дика регулярным?»,b[j] = «виды автоматов»?Вывод: коммититься надо в подсчёт близких
2. Нет метрик качества
Относительно чего мы смотрим, что то или иное улучшение работает? Субъективное мнение, что «моделька выдаёт что-то похожее на правду»? А кто сказал, что это не случайность?
Метрика оценки качества нужна, причём их должно быть две:
Вывод: надо ввести метрики (сейчас формулирую)
3. Версия модели не фиксирована
Каждый раз используется
latestмодель, зачем? Я считаю, что лучше зафиксировать одну модель, так будет проще отслеживать прогресс и получим хоть какой-то детерминизм (например:latest_prevимеет одну архитектуру, которая обращает внимание на первую часть предложения, аlatest— другую, которая обращает внимание на вторую часть предложения, пример нереалистичный, но показательный)Вывод: фиксируем версию mistral
4. Не оцениваем влияние новых вопросов
Сейчас мы просто вливаем вопросы, не трекая явно как какой вопрос влияет на работу системы. Кажется, что нужно это отслеживать, причём с двух строн:
mistralЭто может помочь в определение того, что делает вопрос «плохим»
Вывод: нужны автотесты
Лёша писал про них и делает их, метрику можно взять как количество вхождений важных слов и терминов в правильном и проверяемом предложении (допишу нормально)
Идея как получить больше юзер подобных вопросов тут (просто я при составлении датасета сама переформулировала без нейронки)
5. Не работаем с промтами к
mistralВообще не работаем с промтами, а это ещё одна возможность улучшить ответы, задали один (вроде как) и всё.
Было написано по крайней мере две классные идеи, но почему-то забыты: про неуверенность и уточняющий вопрос
Вывод: после создания бейзлайна, надо двигаться в нескольких направлениях, включая промты
6. Нет проверки гипотез
Из-за того, что нет бейзлайна и метрик качества, которые давали бы понимание, какие действия ведут к успеху, а какие нет, нельзя проводить эксперименты / проверять гипотезы
Вывод: строим базу:
mistralmistralфиксированной версии