Как уменьшить галлюцинации LLM: 3 способа дать контекст

Большие языковые модели по-прежнему часто выдумывают детали, если им не хватает контекста. Чем сложнее проект, тем сильнее это ощущается: ИИ не знает структуру вашего репозитория, не видел свежую документацию библиотеки, не понимает бизнес-ограничения продукта.

В статье разберем, как аккуратно подложить модели нужный контекст: от встроенных механизмов в IDE и Claude до утилит для выгрузки репозитория и MCP-серверов, которые подтягивают актуальные документы и данные. Ниже - 3 практичных способа дать модели контекст без бесконечной копипасты.

1) Автоконтекст: когда система подмешивает контекст сама

Если вы работаете в Claude Projects или в Cursor/Copilot - часть контекста система может добавлять сама.

Claude Projects

Если вы используете Claude Projects, можно собрать “папку знаний” под проект: ТЗ, заметки, фрагменты кода, внутренние гайды, спецификации. Вы кладете материалы/файлы/контекст в “проект”, и Claude использует их как базу. Дальше вы общаетесь внутри проекта, и модель использует эти материалы как базу.

Если материалов становится много, Projects могут включать режим RAG: система хранит больше знаний и подбирает релевантные фрагменты под запрос.

Cursor /Copilot в IDE

Если вы работаете в IDE, типа Cursor или GitHub Copilot, часть контекста подтягивается из проекта автоматически. Ассистент видит структуру репозитория, файлы и папки. Можно явно указать, с чем работать: отдельные файлы, директории, символы, куски кода. Так модель понимает, где вы находитесь, в каком модуле, компоненте, слое архитектуры.

2) Когда у модели нет доступа к файлам: упаковываем репозиторий в текст

Бывает обратная ситуация: вы работаете в LLM без доступа к репо/файлам, но хотите, чтобы модель увидела контекст (структуру проекта, ключевые исходники).

Тогда вы можете собрать важные части репозитория в один текстовый файл (например, output.txt) и уже его скормить модели. Здесь помогают специальные утилиты.

gitingest

gitingest - делает текстовую версию Git-репозитория, которую удобно скармливать LLM. Полезно, когда нужно быстро показать структуру и ключевой код (а не по одному файлу).

• Для GitHub-репо достаточно заменить github.com на gitingest.com в URL: https://github.com/user/repo → https://gitingest.com/user/repo

• Можно включать или исключать определенные файлы и папки: по расширению (*.md, .ts, .py и т.п.); по путям (src/, docs/, config/ и т.д.)

• Так же есть фильтр по размеру файлов.

Как работает: выгрузили output.txt → залили в LLM → дальше работаете с этим текстом как с контекстом.

repo2txt

repo2txt решает похожую задачу, но с дополнительными возможностями:

• конвертирует как GitHub-репозитории, так и локальные директории на вашем компьютере в единый текстовый файл;

• поддерживает публичные и приватные репо GitHub;

• позволяет выбирать конкретные файлы и папки для включения, фильтровать по расширениям, собрать аккуратный «срез» проекта под конкретную задачу.

• Работает полностью в браузере, так что код не отправляется на сторонние серверы

Как работает: Выбираете, какие части проекта реально нужны модели → Выгружаете их в один файл (output.txt) → Передаете его LLM как большой контекст: «Вот структура и ключевой код, а теперь помоги…».

3) MCP: когда нужны живые доки и актуальные данные

Даже если вы хорошо подложили контекст из кода, остается другая проблема: документация библиотек и сервисов.

LLM часто опираются на знания, которые были актуальны на момент обучения, а API и фреймворки за это время спокойно успевают поменяться.

Model Context Protocol (MCP) решает эту задачу: он дает моделям структурированный доступ к внешним источникам - документации, БД, логам, облачным ресурсам, внутренним сервисам.

Ниже два примера MCP-серверов, полезных именно для документации и девелоперских задач.

Context7

Context7 - MCP-сервер, который подтягивает актуальную документацию по популярным библиотекам (Next.js, React, Tailwind и др.); подмешивает ее в запрос к LLM или ИИ-редактору кода. Дает возможность общаться с документацией в форме чата: задавать вопросы, уточнять примеры, просить сравнить подходы.

OpenAI Developer Docs MCP

Если вы работаете с OpenAI SDK/инструментами, есть публичный сервер документации, который можно подключать как источник контекста - OpenAI Developer Docs MCP. Он дает модели доступ к документации по OpenAI API, примерам использования, описаниям моделей и параметров.

С этим MCP-сервером модель может спросить свежие доки во время работы и уже на их основе предложить корректный пример запроса, настройки или архитектурное решение.

Какой способ работы с контекстом выбрать для ваших задач

• Если вы работаете в IDE над проектом, то лучше использовать Cursor или Copilot и их доступ к файлам, папкам, символам. Явно указывайте ассистенту, с какими модулями он сейчас работает. Для сложных задач можно дополнительно выгружать срез проекта через gitingest или repo2txt и давать его как глобальный контекст.

• Если у вас продуктовые задачи, много описаний и документации, то создавайте Claude Projects и складывайте туда ТЗ, продуктовые и UX-документы, внутренние гайды, FAQ и служебные регламенты. Дальше общайтесь с Claude внутри проекта — он будет использовать эти материалы как базу знаний.

• Если у ИИ нет доступа к репозиторию, но нужен большой контекст, возьмите gitingest, если работаете с GitHub-репо. Или возьмите repo2txt, если нужно работать с локальными папками, есть приватные репо, важна приватность и вы не хотите отправлять код на сторонний сервер. Соберите минимальный, но достаточный output.txt из ключевых частей проекта и передайте его LLM.

• Если нужны актуальная документация и живые данные, то подключайте MCP, когда важно опираться на свежие версии библиотек, есть внутренние источники (БД, логи, BI-отчеты), которые нужно безопасно подмешивать к запросам. Для фронтенд-стека и популярных библиотек — Context7. Для работы с OpenAI API — OpenAI Developer Docs MCP.

Вы можете поддержать меня в моем канале НейроProfit - там я пишу о том, в чем разбираюсь или пытаюсь разобраться сама, тестирую полезные ИИ-сервисы, инструменты для офиса, бизнеса, маркетинга и видео.