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

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

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

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

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

Claude Projects

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

Это удобно, когда длинная задача/продукт, где важно помнить договоренности; много документации и повторяющихся вводных.

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

В справке Anthropic ^[1] отдельно говорится, что при приближении к лимитам контекстного окна Claude может автоматически включить RAG и увеличить емкость проекта (указано “до 10×” при сохранении качества).

Cursor /Copilot в IDE

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

Это удобно, когда ежедневные правки по месту: багфиксы, рефакторинг, добавление функций + важно попадать в стиль и паттерны текущей кодовой базы.

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

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

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

gitingest

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

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

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

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

Удобно, когда нужно быстро дать модели общую картину проекта, хотите, чтобы LLM посмотрела всю структуру и ключевые файлы перед рефакторингом. Или вы готовите анализ чужого репозитория: ревью, аудит, разбор архитектуры.

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

repo2txt

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

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

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

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

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

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

Вы дочитали до середины статьи, а значит, статья, вероятнее всего, вам понравилась, как и моя подача и стиль письма, так что вы можете поддержать меня в моем телеграм канале ^[8], где уже собрано много полезного и проверенного.

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

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

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

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

MCP-серверы сами выбирают, какой кусок информации передать модели под конкретный запрос. Вам не нужно вручную копировать документацию.

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

Context7

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

Так меньше галлюцинаций про устаревшие API. Разработчику это дает советы и примеры, опирающиеся на реальную текущую версию библиотеки, а не на тренинг-датасет, плюсом еще возможность добавить свои доки (через Add Docs) и подключить их к стеку.

OpenAI Developer Docs MCP

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

Например, вы пишете бота или сервис поверх 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 ^[8] – там я пишу о том, в чем разбираюсь или пытаюсь разобраться сама, тестирую полезные ИИ-сервисы, инструменты для офиса, бизнеса, маркетинга и видео.