Не так давно пытался получше понять как стоит вести исследование с LLM чтобы не потерять контроль, и не потерять в качестве.
Кажется одна из стандартных схем "как улучшить алгоритм до максимально крутого" примерно такая:
1) поиск слабого места (что сейчас хочется улучшить? где результат особенно остро плохой? конкретный пример и конкретное место в примере)
2) тщательный анализ причины проблемы - до полного понимания
3.1) если это баг - то исправить баг и перейти к шагу 4
3.2) если это идейная слабость - понять какие тезисы и базовые идеи/предположения заложенные в алгоритм здесь не оправдались/сломались/оказались слишком простыми
3.3) придумать как эти тезисы минимально обновить/расширить/усилить с учетом новой информации, минимальность - это способ с одной стороны стараться поддерживать тезисы максимально простыми => проще о них думать => проще делать будущие шаги и меньше переобучения и заточки под конкретные примеры, т.к. простое - чаще более общо (как и с легковесными нейросетями)
4) анализ получившихся изменений:
4.1) сначала локально - в идеале анализировать не целиком результат алгоритма, а его конкретный подэтап - его вход и его выход, сравнивая с входом и выходом прошлой версии
4.2) затем глобально результат - опять же сравнивая результат с результатом прошлой версии
4.3) найти где результаты ухудшились (в сложных задачах почти всегда любое улучшение где-то вредит, поэтому чтобы оценить готовы ли мы на улучшение ценой этого ухудшения - нужно оценить ухудшения)
4.4) если улучшения слабые - может даже откатить, т.к. возможно мы придумали слабое улучшение (и оно не стоит усложнения тезисов), а если мы застряли - возможно мы неправильно поняли причину проблемы на шаге 2
И как с проектированием чистой архитектуры больших приложений многие не готовы делегировать это LLM - т.к. дольше разбираться в ее идеи и формировать мысленную модель у себя в голове по ее чертежам, и затем искать упущения, улучшать и т.п.. Чем придумать самому сразу хорошо. И понятно что при желании можно накидать общий скелет и попросить LLM проработать дальше.
Вобщем кажется что эти условные тезисы - или ментальная модель алгоритма - это то что нужно знать, иначе невозможно улучшать алгоритм и невозможно развивать свое экспертное знание. Т.к. не придумывая тезисы и не проверяя их на практике - не получить обратной связи чтобы научиться придумывать тезисы лучше.
Любопытно что некий блоггер Антонов (все это время я создавал иллюзию поста, но на самом деле это была она - нативная реклама) в своих рекомендациях про то как торговать акциями - рекомендует как раз торговать долгосрочные тезисы (условно "нефть будет нужна все больше"), записывать их в табличку, и со временем сверять с реальностью чтобы была возможность обучаться.
Post #240
556
- 👍 2