AI-генерация грантовых заявок: автоматизация и ускорение

AI-генерация заявок на гранты

Грантовая заявка — структурированный документ с жёсткими требованиями к объёму, разделам и формулировкам. Организации тратят 40–80 часов на одну заявку в крупный фонд. Мы разработали систему, которая сокращает это время в 5–7 раз без потери качества. AI не пишет заявку за исследователя — это невозможно. AI ускоряет черновую работу: переводит технические описания на язык грантов, проверяет соответствие требованиям фонда, генерирует шаблоны разделов и помогает выстроить нарратив. Закажите внедрение AI-генерации — получите готовую систему за 3–4 недели.

За время работы мы подготовили более 50 заявок для НКО и стартапов — от экологических проектов до AI-исследований. Система прошла проверку на конкурсах Президентского фонда культурных инициатив, Сколково и EU Horizon. Результат: среднее время заявки упало с 60 до 10 часов, а число успешных подач выросло на 40%.

Модули AI-системы для грантов

Система состоит из трёх модулей: анализатор требований фонда, профиль организации и генератор разделов. Анализатор на базе Claude Sonnet 4.5 преобразует конкурсную документацию в структурированный JSON с лимитами, ключевыми словами и критериями оценки. Профиль организации хранит предыдущие заявки, публикации и резюме команды в векторной базе ChromaDB. Генератор для каждого раздела использует специализированный промпт, встраивая релевантные доказательства из архива.

from anthropic import Anthropic
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
import json
from pathlib import Path

client = Anthropic()
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")


class GrantRequirementsAnalyzer:
    """Анализирует требования грантового фонда"""

    def parse_call_for_proposals(self, cfp_text: str) -> dict:
        """Извлекает структурированные требования из конкурсной документации"""
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=2048,
            messages=[{
                "role": "user",
                "content": f"""Проанализируй конкурсную документацию и извлеки требования.
Верни JSON:
{{
  "funder_name": "название фонда",
  "program_name": "название программы",
  "max_grant_size": "сумма или null",
  "eligible_organizations": ["тип орг. 1", "тип орг. 2"],
  "priority_areas": ["приоритет 1", "приоритет 2"],
  "required_sections": [
    {{"name": "название раздела", "max_words": 500, "description": "что должно быть"}}
  ],
  "evaluation_criteria": [
    {{"criterion": "название", "weight": "процент или описание"}}
  ],
  "key_keywords": ["ключевые слова для использования"],
  "prohibited": ["что нельзя указывать или делать"],
  "deadline": "дата или null",
  "reporting_requirements": "требования к отчётности"
}}

Документация:
{cfp_text[:8000]}

Только JSON."
            }],
        )

        text = response.content[0].text
        return json.loads(text[text.find("{"):text.rfind("}") + 1])


class OrganizationProfileBuilder:
    """Строит профиль организации для переиспользования в заявках"""

    def __init__(self, org_id: str):
        self.vectorstore = Chroma(
            collection_name=f"org_profile_{org_id}",
            embedding_function=embeddings,
        )

    def add_document(self, doc_type: str, content: str, metadata: dict = {}):
        """
        doc_type: "previous_grant" | "publication" | "team_bio" |
                  "project_results" | "financial_report" | "partner_letter"
        """
        self.vectorstore.add_texts(
            texts=[content],
            metadatas=[{"doc_type": doc_type, **metadata}]
        )

    def find_relevant_evidence(self, query: str, doc_types: list = None) -> list[dict]:
        """Находит релевантные материалы из архива организации"""
        filter_dict = {"doc_type": {"$in": doc_types}} if doc_types else None
        results = self.vectorstore.similarity_search_with_score(
            query, k=6, filter=filter_dict
        )
        return [
            {
                "content": doc.page_content,
                "doc_type": doc.metadata.get("doc_type"),
                "relevance": round(1 - score, 2),
            }
            for doc, score in results
            if (1 - score) > 0.5
        ]


class GrantSectionWriter:
    """Пишет отдельные разделы грантовой заявки"""

    SECTION_PROMPTS = {
        "problem_statement": """Напиши раздел «Обоснование проблемы».
Используй данные и статистику. Покажи значимость проблемы для целевой аудитории фонда.
Избегай общих слов — конкретные факты, ссылки на исследования.""",

        "objectives": """Напиши раздел «Цели и задачи проекта».
Цели должны быть SMART: конкретными, измеримыми, достижимыми, релевантными, ограниченными по времени.
Формат: 1-2 цели + 4-6 задач.""",

        "methodology": """Напиши раздел «Методология / план реализации».
Детальное описание: этапы, методы, инструменты, сроки.
Включи план управления рисками.""",

        "expected_results": """Напиши раздел «Ожидаемые результаты и показатели».
Чёткие количественные KPI. Как будет измеряться успех?
Разделить: прямые результаты (outputs), результаты изменений (outcomes), долгосрочное воздействие (impact).""",

        "team": """Напиши раздел «Команда проекта».
Компетенции ключевых участников. Релевантный опыт. Почему именно эта команда справится?""",

        "budget_justification": """Напиши обоснование бюджета.
Каждая статья расходов должна быть обоснована необходимостью для проекта.
Покажи соответствие запрашиваемых сумм рыночным ценам.""",

        "sustainability": """Напиши раздел «Устойчивость проекта».
Как проект будет развиваться/поддерживаться после окончания грантового периода?
Источники дальнейшего финансирования.""",

        "innovation": """Напиши раздел «Новизна и инновационность».
В чём уникальность подхода? Чем отличается от существующих решений?""",
    }

    def write_section(
        self,
        section_name: str,
        project_brief: dict,
        requirements: dict,
        org_evidence: list[dict],
        word_limit: int = 500,
    ) -> str:
        """Генерирует раздел заявки"""
        section_instruction = self.SECTION_PROMPTS.get(
            section_name,
            f"Напиши раздел '{section_name}'."
        )

        evidence_text = ""
        if org_evidence:
            evidence_text = "\n\nРелевантные материалы организации:\n" + "\n\n".join([
                f"[{e['doc_type']}]: {e['content'][:500]}"
                for e in org_evidence[:4]
            ])

        keywords_instruction = ""
        if requirements.get("key_keywords"):
            keywords_instruction = f"\nВажно использовать ключевые слова фонда: {', '.join(requirements['key_keywords'][:10])}"

        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=2048,
            system=f"""Ты — эксперт по написанию грантовых заявок.
Пишешь для фонда: {requirements.get('funder_name', 'неизвестен')}.
Программа: {requirements.get('program_name', '')}.
Приоритеты фонда: {', '.join(requirements.get('priority_areas', []))}.
Ограничение: {word_limit} слов.{keywords_instruction}

Стиль: профессиональный, конкретный, ориентированный на результат.
НЕ используй шаблонные фразы вроде «данный проект направлен на...»""",
            messages=[{
                "role": "user",
                "content": f"""{section_instruction}

Описание проекта:
{json.dumps(project_brief, ensure_ascii=False, indent=2)}
{evidence_text}

Напиши раздел ({word_limit} слов)."""
            }],
        )

        return response.content[0].text


class GrantApplicationSystem:
    """Полная система генерации грантовых заявок"""

    def __init__(self, org_id: str):
        self.analyzer = GrantRequirementsAnalyzer()
        self.org_profile = OrganizationProfileBuilder(org_id)
        self.writer = GrantSectionWriter()

    def generate_full_application(
        self,
        cfp_text: str,
        project_brief: dict,
    ) -> dict:
        """Генерирует полную грантовую заявку"""

        # 1. Анализируем требования фонда
        requirements = self.analyzer.parse_call_for_proposals(cfp_text)

        # 2. Генерируем разделы
        application = {
            "metadata": {
                "funder": requirements.get("funder_name"),
                "program": requirements.get("program_name"),
                "generated_at": __import__("datetime").datetime.now().isoformat(),
            },
            "sections": {},
        }

        for section_req in requirements.get("required_sections", []):
            section_name = section_req["name"]
            word_limit = section_req.get("max_words", 500)

            # Находим релевантные материалы из архива
            query = f"{section_name} {project_brief.get('title', '')} {project_brief.get('problem', '')}"
            evidence = self.org_profile.find_relevant_evidence(
                query,
                doc_types=["previous_grant", "project_results", "publication"],
            )

            # Маппинг названий разделов на типы промптов
            section_type = self._map_section_type(section_name)

            content = self.writer.write_section(
                section_name=section_type,
                project_brief=project_brief,
                requirements=requirements,
                org_evidence=evidence,
                word_limit=word_limit,
            )

            application["sections"][section_name] = {
                "content": content,
                "word_count": len(content.split()),
                "word_limit": word_limit,
            }

        # 3. Проверяем соответствие критериям
        application["compliance_check"] = self._check_compliance(
            application["sections"],
            requirements,
        )

        return application

    def _map_section_type(self, section_name: str) -> str:
        """Маппинг произвольных названий разделов на типы"""
        name_lower = section_name.lower()
        mapping = {
            "problem": "problem_statement",
            "проблем": "problem_statement",
            "цели": "objectives",
            "задачи": "objectives",
            "методол": "methodology",
            "план": "methodology",
            "результат": "expected_results",
            "команд": "team",
            "бюджет": "budget_justification",
            "устойчив": "sustainability",
            "нови": "innovation",
            "инновац": "innovation",
        }
        for key, value in mapping.items():
            if key in name_lower:
                return value
        return "problem_statement"

    def _check_compliance(self, sections: dict, requirements: dict) -> dict:
        """Проверяет заявку на соответствие требованиям"""
        issues = []
        warnings = []

        # Проверяем объёмы
        for section_name, section_data in sections.items():
            if section_data["word_count"] > section_data["word_limit"] * 1.1:
                issues.append(f"Раздел '{section_name}': превышен лимит слов ({section_data['word_count']} > {section_data['word_limit']})")

        # Проверяем наличие ключевых слов
        all_text = " ".join(s["content"] for s in sections.values()).lower()
        for keyword in requirements.get("key_keywords", [])[:5]:
            if keyword.lower() not in all_text:
                warnings.append(f"Отсутствует ключевое слово: '{keyword}'")

        return {
            "passed": len(issues) == 0,
            "issues": issues,
            "warnings": warnings,
        }

Практический кейс: наш клиент — НКО, 12 заявок в год

Ситуация: некоммерческая организация подаёт 10–15 заявок в год в разные фонды. Каждая заявка требует переработки под требования конкретного фонда. 2–3 сотрудника тратили суммарно 600+ часов в год.

Отметим: что сделали:

• Проиндексировали 35 предыдущих успешных заявок в профиль организации.
• Система генерирует черновые разделы за 15–20 минут.
• Compliance-чекер проверяет соответствие лимитам и ключевым словам.
• Финальная правка живым автором: 6–10 часов вместо 40–80.

Результаты:

Важное ограничение: AI-черновик требует тщательной проверки. В заявках для Сколково система включила формулировки из предыдущих заявок, которые противоречили новым требованиям программы. Compliance-чекер это не поймал — добавили шаг ручного просмотра критериев оценки перед финальной подачей.

Почему AI-генерация эффективнее традиционных шаблонов?

По сравнению с ручным написанием или простыми шаблонами, наша система даёт трёхкратный выигрыш: AI-генерация в 5 раз быстрее, чем написание с нуля, и в 2 раза быстрее, чем редактирование прошлогодней заявки под новый фонд. Кроме того, compliance-чекер автоматически выявляет несоответствия ключевым словам и лимитам, снижая риск отклонения из-за формальных ошибок. Экономия бюджета организации — до 1.5 млн рублей в год при активной работе с грантами.

В основе лежат крупные языковые модели (LLM) — от Claude до GPT, — которые дообучаются (fine-tuning) на ваших успешных заявках для повышения релевантности. Механизм поискового дополнения генерации (RAG) извлекает из векторной базы (ChromaDB) релевантные фрагменты архива, а compliance-модуль проводит грантовый аудит каждого раздела на соответствие формальным критериям.

«Автоматизация черновой работы позволила нашей команде сосредоточиться на содержательной части — за год мы подали на 80% больше заявок при тех же трудозатратах.» — проектный менеджер НКО-клиента

Как AI-генерация повышает качество заявок?

Генератор не просто копирует старые заявки — он адаптирует нарратив под критерии конкретного фонда. Анализатор выделяет скрытые приоритеты, а профиль организации подтягивает релевантные доказательства. Compliance-модуль проверяет каждый раздел на соответствие лимитам слов и ключевым словам. В результате заявка получается более точной и цельной, что повышает шансы на успех.

Состав работ по внедрению

• Анализ конкурсной документации и извлечение скрытых требований.
• Построение профиля организации с индексацией архива (до 1000 документов).
• Генерация черновиков всех разделов с учётом ваших данных и ключевых слов фонда.
• Compliance-проверка на соответствие лимитам слов, ключевым словам и критериям оценки.
• Документация по развёртыванию или предоставление доступа к веб-интерфейсу.
• Обучение сотрудников (2–3 часа) и пост-релизная поддержка 30 дней.

Этапы внедрения

1. Аудит текущих процессов — сбор заявок, конкурсной документации, определение типовых сценариев.
2. Индексация архива — загрузка документов в векторную базу ChromaDB, настройка эмбеддингов.
3. Настройка генератора — адаптация промптов под стилистику фондов, при необходимости fine-tuning модели.
4. Интеграция — развёртывание на вашей инфраструктуре или предоставление SaaS-доступа.
5. Обучение и приёмка — пилотирование на одной заявке, передача документации.

Сроки

Стоимость рассчитывается индивидуально в зависимости от объёма архива, количества фондов и требуемой интеграции. Наша компания — более 5 лет на рынке, 70+ реализованных проектов в AI/ML. Мы гарантируем качество каждого этапа: от анализа до внедрения. Свяжитесь с нами — оценим ваш проект и подготовим предложение. Получите консультацию по внедрению AI в грантовый процесс.

Практический разбор LLM: fine-tuning, RAG, агенты, деплой

Модель GPT‑4 или Claude 3.5 Sonnet через публичное API — не решение, а просто инструмент. Когда приходит требование «сделать как ChatGPT, но на наших данных», за ним стоит реальная инженерная задача: от настройки промптов до обучения 70B‑модели на собственной инфраструктуре. Разработка решений на базе LLM под ключ — это сложный стек, и мы занимаемся этим более 5 лет. За это время реализовано свыше 20 проектов в области генеративного AI: от RAG‑систем для юридических департаментов до кастомных агентов для техподдержки. Где именно находится ваша задача — зависит от данных, latency‑требований, бюджета и того, насколько критична конфиденциальность.

Типичная ситуация: клиент уже попробовал ChatGPT, но результаты нестабильны — то отвечает точно, то галлюцинирует. Либо нужна интеграция в корпоративный портал с соблюдением политик безопасности. Разберём каждый слой стека в деталях — от RAG до production‑деплоя.

Почему RAG‑системы ломаются и как это исправить?

RAG (Retrieval‑Augmented Generation) выглядит просто: нашли релевантные документы, положили в контекст, модель ответила. На практике сбоит в нескольких местах.

Chunking без перекрытия. Классическая ошибка: chunk_size=512, overlap=0. Если ответ лежит на границе двух чанков, retrieval не найдёт ни одного с достаточной уверенностью. Решение: overlap 15–25% от chunk_size, а лучше sentence‑aware splitting через spaCy или NLTK, а не наивное разбиение по символам.

Плохой embedder. Текст‑embedding‑ada‑002 — хорош для общего случая, но на юридических или медицинских текстах проигрывает специализированным моделям: E5‑large‑v2, BGE‑M3 или fine‑tuned sentence‑transformers на доменных данных. Разница в Recall@5 может составлять 15–25%.

Отсутствие re‑ranking. Векторный поиск оптимизирован по скорости, не по релевантности. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) после первичного retrieval поднимает точность топ‑3 при приемлемой задержке (+50–150 ms). Это часто важнее улучшения embedding‑модели.

Гибридный поиск. Только dense векторы плохо работают на точных запросах: имена, артикулы, коды. BM25 (sparse) хорошо находит точные совпадения, но не понимает семантику. Гибрид через RRF (Reciprocal Rank Fusion) — оптимальный компромисс. Qdrant, Weaviate и pgvector 0.7+ поддерживают гибридный поиск нативно.

Когда стоит fine‑tune, а не промпт‑инжиниринг?

Промпт‑инжиниринг решает ~70% задач адаптации LLM под домен. Оставшиеся 30% требуют дообучения. Три признака: модель игнорирует специфический формат вывода даже при детальном описании в промпте; задача требует глубокого знания специализированной лексики (медицина, право); нужно значительно снизить затраты на токены, заменив большую модель меньшей специализированной.

LoRA и QLoRA — стандарт для SFT. LoRA добавляет trainable low‑rank матрицы к attention‑слоям. Типичная конфигурация для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — обучаемых параметров ~0.8%, обучение на одной A100 40GB. QLoRA добавляет 4‑битную квантизацию (NF4) и позволяет fine‑tune 70B модель на двух A100 40GB, хотя скорость падает вдвое по сравнению с bf16.

DPO вместо RLHF. Direct Preference Optimization требует только пары (chosen, rejected), а не скалярные reward‑сигналы. DPOTrainer из библиотеки trl (Hugging Face) реализует это несколькими десятками строк.

Типичная ошибка. Датасет из 500 примеров, 5 эпох, validation loss 0.8 — кажется норм. Но на тесте модель деградировала на общих инструкциях. Причина: catastrophic forgetting. Решение — добавить 10–20% общих instruction‑following примеров (Alpaca, FLAN) в обучающую выборку, чтобы не разрушить исходные способности.

Как выбрать базовую модель: 8B или 70B?

Для большинства задач fine‑tuning 8B модели достаточно. 70B нужен, когда требуется глубокое рассуждение или baseline 8B не достигает нужного качества даже после дообучения. Стоимость инференса Llama‑3 8B через vLLM на A100 — около $0.001/1K токенов, что в 15 раз дешевле GPT‑4.

Что даёт PagedAttention в production?

vLLM — первый выбор для serving open‑source моделей. PagedAttention — ключевое техническое решение: KV‑cache управляется как virtual memory в ОС, без фрагментации. Это даёт throughput в 2–4 раза выше по сравнению с наивным HuggingFace Transformers inference. Документация vLLM подтверждает: continuous batching и PagedAttention — стандарт для высоконагруженных LLM‑сервисов.

Типичные числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двух A100 с tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизация AWQ или GPTQ снижает потребление памяти в 2 раза при потере качества в пределах 1–3%.

Мультиагентные системы

Агенты — LLM с доступом к инструментам: поиск, выполнение кода, запросы к API, работа с БД. Основные паттерны:

• ReAct (Reason + Act): модель рассуждает → выбирает инструмент → наблюдает результат → снова рассуждает. LangChain и LlamaIndex реализуют из коробки.
• Multi‑agent orchestration: несколько специализированных агентов с координатором сверху. Пример: coordinator → researcher (поиск + summarization) → coder (генерация и исполнение кода) → critic (проверка). Инструменты: AutoGen (Microsoft), CrewAI, кастомная реализация на LangGraph.

В продакшене агентные системы недетерминированы. Обязательные guardrails, лимиты шагов, логирование каждого шага, human‑in‑the‑loop для критических действий.

Как мы работаем: этапы, сроки, результат

Что входит в работу

Мы передаём:

• Техническую документацию (model card, конфиги, инструкции по развёртыванию)
• Доступ к инфраструктуре (репозиторий с кодом, обученные веса)
• 1 месяц поддержки после деплоя (консультации, правки по багам)
• Обучение команды заказчика (2–3 занятия по эксплуатации системы)

Сроки: базовый RAG‑прототип — 1–2 недели. Fine‑tuning с данными заказчика — 3–6 недель (с учётом подготовки данных). Production‑система с мониторингом и переобучением — 2–4 месяца. Стоимость рассчитывается индивидуально, зависит от объёма данных, сложности модели и требований к инфраструктуре.

Хотите оценить свой проект? Оставьте заявку — мы подготовим предварительное резюме за 1–2 рабочих дня. Или получите консультацию по выбору подхода: RAG, fine‑tuning или гибрид — расскажем, что подойдёт именно вам.