Skip to content

Расследование (LLM-research) #120

@molivka

Description

@molivka

Проблемы

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. Нет метрик качества

Относительно чего мы смотрим, что то или иное улучшение работает? Субъективное мнение, что «моделька выдаёт что-то похожее на правду»? А кто сказал, что это не случайность?

Метрика оценки качества нужна, причём их должно быть две:

  1. Метрика качества для поиска близких (здесь много чего можно попробовать улучшить, тут я потыкаюсь, когда будет хоть капля времени)
  2. Метрика по ответам mistral (можем улучшить только контекст / промт)

Вывод: надо ввести метрики (сейчас формулирую)

3. Версия модели не фиксирована

Каждый раз используется latest модель, зачем? Я считаю, что лучше зафиксировать одну модель, так будет проще отслеживать прогресс и получим хоть какой-то детерминизм (например: latest_prev имеет одну архитектуру, которая обращает внимание на первую часть предложения, а latest — другую, которая обращает внимание на вторую часть предложения, пример нереалистичный, но показательный)

Вывод: фиксируем версию mistral

4. Не оцениваем влияние новых вопросов

Сейчас мы просто вливаем вопросы, не трекая явно как какой вопрос влияет на работу системы. Кажется, что нужно это отслеживать, причём с двух строн:

  1. Не портится ли метрика поиска близких
  2. Не портится ли метрика ответов mistral

Это может помочь в определение того, что делает вопрос «плохим»

Вывод: нужны автотесты
Лёша писал про них и делает их, метрику можно взять как количество вхождений важных слов и терминов в правильном и проверяемом предложении (допишу нормально)
Идея как получить больше юзер подобных вопросов тут (просто я при составлении датасета сама переформулировала без нейронки)

5. Не работаем с промтами к mistral

Вообще не работаем с промтами, а это ещё одна возможность улучшить ответы, задали один (вроде как) и всё.
Было написано по крайней мере две классные идеи, но почему-то забыты: про неуверенность и уточняющий вопрос

Вывод: после создания бейзлайна, надо двигаться в нескольких направлениях, включая промты

6. Нет проверки гипотез

Из-за того, что нет бейзлайна и метрик качества, которые давали бы понимание, какие действия ведут к успеху, а какие нет, нельзя проводить эксперименты / проверять гипотезы

Вывод: строим базу:

  1. Метод подбора близких (у меня есть идея на этот счёт: дообучить модель на текстах про тфя, чтобы улучшить поиск семантически близких)
  2. Метрика качества для близости
  3. Метрика качества для ответов mistral
  4. Одна mistral фиксированной версии
  5. Автотесты

Metadata

Metadata

Assignees

Labels

Projects

Status

Ready

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions