Концентрация контекста
Современные LLM давно уже вышли за предел «галлюционнирующей генерации» и дают устойчивую точную генерацию практически на всех популярных языках, фреймворках и библиотеках... При наличии правильного контекста. В большинстве случаев контекст, который вы скармливаете LLM имеет высокую избыточность и низкую концентрацию полезной информации. При нехватке контекстного окна вы практически гарантированно получите низкокачественную галлюцинацию. Что можно сделать в таком случае: обрезается весь ненужный контекст, добавляется весь необходимый. Как это выглядит: вы подготавливаете свой проект в IDE, убирая всё лишнее, и оставляете только самое необходимое, что бы LLM получила весь необходимый контекст и не байтом больше, то есть контекст должен на 100% состоять из полезной информационной нагрузки.
Если есть объёмная база данных — оставьте в ней всего несколько значений для примера.
Неиспользуемые в данной конкретной ситуации зависимости так же удаляете из контекста. Если речь о текстовой работе с LLM — то делаете тоже самое в форме промпта или загружаемого текстового файла‑инструкции, подготавливая всё необходимое, т. е., в промпте должно быть описание кодовой базы и окружения, файловая структура, ипользуемый стек, назначение кодовой базы, весь необходимый код всех задействованных файлов, выдаваемые ошибки и прочее. То есть вы должны своими руками построить 100% удобный для работы LLM контекст. Фактически, при данном подходе, вероятность генерации неправильно ответа — околонулевая. Простыми словами — воспринимайте контекстное окно как бутылочное горлышко, через которое необходимо достать информацию из бутылки, то есть из модели.
Сегментация задач
Хорошим тоном при работе с LLM будет никогда не давать ей больше одной задачи. При небольших задачах мультизапрос может сработать, а последние мощные LLM умеют качественно работать с объемными мультизапросами, но зачем — когда можно попросту сегментировать процесс, и с вашей задачей справится любая локальная бесплатная опенсоурсная LLM с мизерным контекстным окном. Фактически, сегментируя задачи и повышая концентрацию контекста, можно заставить даже самые базовые модели работать на уровне мощнейших и лучших.
В корне их генеративного процесса — всё те же принципы, что и многие годы назад, поэтому при достаточной для ваших потребностей «свежести» базы знаний — не вижу смысла гнаться за мощностью и качеством LLM, когда все задачи могут быть конвертированы в удобоваримые, легко усваиваемые движком LLM, запросы. На самом деле все самые мощные и современные модели просто делаеют это за вас, обрабатывая ваш запрос пользуясь похожими принципами. Зачем делигировать LLM то, что вы можете сделать лучше неё сами, вручную?
Повышение качества запроса
LLM это простая абстракция, созданная на базовых принципах информатики. Попросту следующее поколение информационных провайдеров после классических поисковиков. Этакий «гугл на флешке» — стандартная опенсоурсная LLM весит около гигабайта. Можно ещё, как часто говорят, назвать LLM следующим уровнем абстракции после фреймворков. В принципе подобная метафора так же уместна. Что бы эффективно работать с LLM нужно понимать — если вы работаете с популярными языками, фреймворками и библиотеками, то практически любая актуальная LLM содержит в себе нужную вам информацию. Нужно только уметь её из LLM получать, как получают шёлк из паука шелкопряда. Здесь приходят на помощь простые хитрости.
LLM прекрасно понимает базовую человеческую речь, при условии правильного структурирования речи. Отсюда простой и понятный подход: создайте в вашем запросе некий крюк, который вытягивает необходимую информацию из базы. Это должно быть предельно точное и предельно лаконичное описание задачи, с максимальным количеством необходимых подробностей, запрос должен быть составлен с прицелом на максимально точное попадание в базу знаний LLM, так что бы она не сомневалась что в базе искать, сразу предоставляя вам необходимую информацию.
Повышение качества генерации
Качество кода выдаваемого LLM можно разделить на три характеристики: устойчивая генерация, высококачественная галлюцинация, низкокачественная галлюцинация. Комбинируя вышеприведённые методы можно крайне высоко поднять качество генерации кодовой базы, фактически сделав LLM 100% достоверным ассистентом. В случае даже если в вашем конкретном случае создать точную генерацию невозможно ввиду, например, отсутствия в базе знаний LLM необходимой информации — можно создать максимально качественную галлюцинацию, которая гарантированно подскажет куда копать. А учитывая, что все LLM, по большому счёту — форки друг друга, примерно как с дистрибутивами linux, то плюс‑минус в них имеется вся актуальная и необходимая информация, в большинстве случаев, естественно при условии достаточной свежести модели. То есть даже в случае высококачественной галлюцинации — вы гарантированно получите ответ на свой запрос, пусть и в форме: «куда посмотреть и где искать», который практически всегда будет верным.
P.S.: Ещё один, немного необычный совет для работы с LLM — купите хорошую игровую мышку. Копировать и удалять текст придётся очень много.
Из моего личного опыта: при применении вышеприведённых методов — практически любая современная LLM абсолютно безошибочно генерирует код любой сложности на JavaScript, Node.JS (Fastify) и SQLite на любой поставленной задаче. Фактически LLM может выдать вам всё, вплоть до готового фреймворка, SPA или CMS, при наличии достаточного контекстного окна. Если хорошо понимать архитектуру LLM, то очевидно, что при достаточной базе знаний и достаточном контекстном окне — вероятность ошибки практически отсутствует.
В планах собственный сервер с дообученной моделью (большая тема для отдельной статьи), ибо прыгать через три забора до недоступных в РФ LLM‑провайдеров просто в лом, когда всё прекрасно и без них.