LLM обучены на огромных массивах открытых данных. Поэтому они уверенно ориентируются во всём, что существует в публичном технологическом пространстве: - железо - сетевая инфраструктура - операционные системы - приложения, их установка и настройка - облачные сервисы - распространённые open-source проекты - языки программирования и фреймворки - типовые архитектурные подходы - популярные базы данных Это сильная сторона LLM: быстрый доступ к обобщённым знаниям без переключения контекста. А вот чего LLM не знают - ваш проект (если он не open-source) - внутренние фреймворки, паттерны и костыли - командный code style и договорённости - внутреннюю документацию и терминологию - бизнес-логику и «неформальные правила» То есть всё, что живёт внутри конкретной команды или компании. Почему нельзя просто «скормить всё сразу» Идея прикрепить к чату весь архив кодовой базы и документации приходит многим. На практике это почти всегда не работает. Основные причины: - ограниченный размер контекстного окна; - отсутствие структуры и навигации; - невозможность отличить актуальное от устаревшего. Даже если формально данные «поместились», это ещё не значит, что модель сможет с ними корректно работать. Как с этим работать на практике Если нужен адекватный результат: - ключевые инструкции и требования — прямо в запросе; - данные и фрагменты — в приложенных файлах; - только то, что относится к текущей задаче. Ссылки на локалхосты, внутренние Jira/Confluence/Swagger бесполезны — модель их просто не видит. Вывод: LLM сильны в открытом мире и слабы в закрытом. Вся инженерная работа с ними начинается с признания этого факта. #LLM