Самостоятельное размещение Cognee: тесты производительности LLM

Тестирование Cognee с локальными ЛСМ — реальные результаты

Содержимое страницы

Cognee — это фреймворк на Python для создания знаний из документов с использованием LLMs. Но работает ли он с локальными моделями?

Я протестировал его с несколькими локальными LLMs, чтобы выяснить.

cognee processing pdf with procelist

Это страница PDF с прайс-листом, которую я пытался обработать.

TL;DR

Cognee вероятно хорошо работает с умными LLM с сотнями миллиардов параметров, но для RAG, которые должны автоматически извлекать данные из PDF (например, прайс-листов), он не справился на моём оборудовании. Сильная зависимость фреймворка от структурированного вывода делает его использование сложным для небольших локальных моделей.

Что такое Cognee?

Cognee — это открытый фреймворк на Python, предназначенный для создания знаний из неструктурированных документов с использованием LLMs. В отличие от традиционных систем RAG, которые просто разбивают и встраивают документы, Cognee пытается создать семантическое понимание, извлекая сущности, отношения и концепции в базу данных графов. Этот подход соответствует продвинутым архитектурам RAG, таким как GraphRAG, которые обещают лучшее контекстное извлечение.

Фреймворк поддерживает несколько бэкендов:

  • Базы данных векторов: LanceDB (по умолчанию), с поддержкой других векторных хранилищ
  • Базы данных графов: Kuzu (по умолчанию), позволяющие выполнять сложные запросы к отношениям
  • Поставщики LLM: OpenAI, Anthropic, Ollama и другие
  • Фреймворки структурированного вывода: BAML и Instructor для ограниченного генерации

Для энтузиастов самонастройки совместимость Cognee с Ollama делает его привлекательным для локальных развертываний. Однако дьявол кроется в деталях — как мы увидим, требования к структурированному выводу создают значительные трудности для небольших моделей.

Почему структурированный вывод важен

Cognee сильно полагается на структурированный вывод для извлечения информации из документов в едином формате. При обработке документа LLM должен возвращать правильно отформатированный JSON, содержащий сущности, отношения и метаданные. Именно здесь многие небольшие модели испытывают затруднения.

Если вы работаете со структурированным выводом в своих проектах, понимание этих ограничений является критически важным. Проблемы, с которыми я столкнулся с Cognee, отражают более широкие проблемы в экосистеме LLM при работе с локальными моделями.

Настройка конфигурации

Вот моя рабочая конфигурация для Cognee с Ollama. Обратите внимание на ключевые настройки, которые позволяют локальную работу:

TELEMETRY_DISABLED=1

# STRUCTURED_OUTPUT_FRAMEWORK="instructor"
STRUCTURED_OUTPUT_FRAMEWORK="BAML"

# LLM Configuration
LLM_API_KEY="ollama"
LLM_MODEL="gpt-oss:20b"
LLM_PROVIDER="ollama"
LLM_ENDPOINT="http://localhost:11434/v1"
# LLM_MAX_TOKENS="25000"

# Embedding Configuration
EMBEDDING_PROVIDER="ollama"
EMBEDDING_MODEL="avr/sfr-embedding-mistral:latest"
EMBEDDING_ENDPOINT="http://localhost:11434/api/embeddings"
EMBEDDING_DIMENSIONS=4096
HUGGINGFACE_TOKENIZER="Salesforce/SFR-Embedding-Mistral"

# BAML Configuration
BAML_LLM_PROVIDER="ollama"
BAML_LLM_MODEL="gpt-oss:20b"

BAML_LLM_ENDPOINT="http://localhost:11434/v1"

# Database Settings (defaults)
DB_PROVIDER="sqlite"
VECTOR_DB_PROVIDER="lancedb"
GRAPH_DATABASE_PROVIDER="kuzu"

# Auth
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False

Ключевые выборы конфигурации

Фреймворк структурированного вывода: Я тестировал BAML, который обеспечивает лучший контроль над схемами вывода по сравнению с базовым промптингом. BAML специально разработан для структурированных выходов LLM, что делает его естественным выбором для задач извлечения знаний.

Поставщик LLM: Использование API-эндпоинта Ollama, совместимого с OpenAI (/v1), позволяет Cognee обрабатывать его как любой другой сервис в стиле OpenAI.

Модель встраивания: Модель SFR-Embedding-Mistral (4096 измерений) обеспечивает высококачественные встраивания. Для более подробной информации о выборе и производительности моделей встраивания модели Qwen3 предлагают отличные альтернативы с сильными мультиязычными возможностями.

Базы данных: SQLite для метаданных, LanceDB для векторов и Kuzu для знаний сохраняют все локально без внешних зависимостей.

Установка Cognee

Установка проста с использованием uv (или pip). Я рекомендую использовать uv для более быстрого разрешения зависимостей:

uv venv && source .venv/bin/activate
uv pip install cognee[ollama]
uv pip install cognee[baml]
uv pip install cognee[instructor]

uv sync --extra scraping
uv run playwright install
sudo apt-get install libavif16

Дополнения [ollama], [baml] и [instructor] устанавливают необходимые зависимости для локальной работы LLM и структурированного вывода. Дополнение scraping добавляет возможности веб-скрейпинга, а Playwright позволяет обрабатывать страницы с JavaScript-рендерингом.

Пример кода и использования

Вот базовый рабочий процесс для обработки документов с Cognee. Сначала мы добавляем документы и строим граф знаний:

msy-add.py:

import cognee
import asyncio

async def main():

    # Создаем чистый лист для cognee -- сброс данных и системного состояния
    await cognee.prune.prune_data()
    await cognee.prune.prune_system(metadata=True)

    # Добавляем образцовый контент
    await cognee.add(
        "/home/rg/prj/prices/msy_parts_price_20251224.pdf",
        node_set=["price_list", "computer_parts", "2025-12-24", "aud"]
    )

    # Обрабатываем с помощью LLMs для построения графа знаний
    await cognee.cognify()

if __name__ == '__main__':
    asyncio.run(main())

Параметр node_set предоставляет семантические теги, которые помогают категоризировать документ в графе знаний. Метод cognify() — это место, где происходит магия (или проблемы) — он отправляет фрагменты документа в LLM для извлечения сущностей и отношений.

msy-search.py:

import cognee
import asyncio

async def main():

    # Поиск в графе знаний
    results = await cognee.search(
        query_text="Какие продукты есть в прайс-листе?"
#       query_text="Какова средняя цена для 32GB RAM (2x16GB модули)?"
    )

    # Печать
    for result in results:
        print(result)

if __name__ == '__main__':
    asyncio.run(main())

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

Результаты тестов: производительность LLMs

Я протестировал Cognee с реальным сценарием использования: извлечение информации о продуктах из PDF с прайс-листом на компьютерные запчасти. Это казалось идеальным сценарием — структурированные данные в табличном формате. Вот что произошло с каждой моделью:

Протестированные модели

1. gpt-oss:20b (20 миллиардов параметров)

  • Результат: Неудача с ошибками кодировки символов
  • Проблема: Возвращал некорректно отформатированный структурированный вывод с неправильными кодами символов
  • Примечание: Несмотря на то, что он специально разработан для совместимости с открытым исходным кодом, он не мог поддерживать последовательное форматирование JSON

2. qwen3:14b (14 миллиардов параметров)

  • Результат: Не смог создать структурированный вывод
  • Проблема: Модель генерировала текст, но не в требуемой схеме JSON
  • Примечание: Модели Qwen обычно показывают хорошие результаты, но эта задача превысила их возможности структурированного вывода

3. deepseek-r1:14b (14 миллиардов параметров)

  • Результат: Не смог создать структурированный вывод
  • Проблема: Похоже на qwen3, не мог соответствовать требованиям схемы BAML
  • Примечание: Способности к логическому мышлению не помогли с соблюдением формата

4. devstral:24b (24 миллиарда параметров)

  • Результат: Не смог создать структурированный вывод
  • Проблема: Даже с большим количеством параметров не мог последовательно генерировать корректный JSON
  • Примечание: Специализированная модель кодирования все равно испытывала трудности с строгим соблюдением схемы

5. ministral-3:14b (14 миллиардов параметров)

  • Результат: Не смог создать структурированный вывод
  • Проблема: Меньшая модель Mistral не смогла справиться с требованиями структурированного вывода

6. qwen3-vl:30b-a3b-instruct (30 миллиардов параметров)

  • Результат: Не смог создать структурированный вывод
  • Проблема: Возможности зрения не помогли с извлечением таблиц PDF в этом контексте

7. gpt-oss:120b (120 миллиардов параметров)

  • Результат: Не завершил обработку после 2+ часов
  • Оборудование: Настройка с потребительским GPU
  • Проблема: Модель была слишком большой для практического самонастройки, даже если бы она в конечном итоге сработала

Ключевые выводы

Ограничение размера фрагментов: Cognee использует фрагменты размером 4k токенов при обработке документов с Ollama. Для сложных документов или моделей с большими окнами контекста это кажется излишне ограничивающим. Фреймворк не предоставляет простого способа изменить этот параметр.

Требования к структурированному выводу: Основная проблема не в интеллекте модели, а в соблюдении формата. Эти модели могут понимать контент, но поддержание последовательной схемы JSON на протяжении всего процесса извлечения оказывается сложной задачей. Это соответствует более широким проблемам получения локальных моделей для соблюдения ограничений вывода.

Рассмотрение оборудования: Даже когда достаточно большая модель могла бы работать (например, gpt-oss:120b), требования к оборудованию делают ее непрактичной для большинства сценариев самонастройки. Вам понадобится значительная память GPU и вычислительная мощность.

Сравнение с лучшими практиками структурированного вывода

Этот опыт подкрепляет уроки, извлеченные из работы со структурированным выводом в различных поставщиках LLM. Коммерческие API от OpenAI, Anthropic и Google часто имеют встроенные механизмы для обеспечения соблюдения схем вывода, в то время как локальные модели требуют более сложных подходов, таких как выборка на основе грамматики или несколько этапов проверки.

Для более глубокого анализа выбора правильного LLM для Cognee на Ollama, включая подробные сравнения различных размеров моделей и их характеристик производительности, доступны всеобъемлющие руководства, которые помогут вам принять обоснованное решение.

Альтернативные подходы для саморазмещаемого RAG

Если вы настроены на саморазмещение и вам нужно извлекать структурированные данные из документов, рассмотрите эти альтернативы:

1. Традиционный RAG с упрощенным извлечением

Вместо создания сложного знания графа заранее используйте традиционный RAG с разбиением документов на части и векторным поиском. Для извлечения структурированных данных:

  • Парсите таблицы напрямую с помощью библиотек вроде pdfplumber или tabula-py
  • Используйте более простые запросы, которые не требуют строгого соответствия схеме
  • Реализуйте постобработку и валидацию в Python, а не полагайтесь на формат вывода LLM

2. Специализированные модели встраивания

Качество ваших встраиваний значительно влияет на производительность извлечения. Рассмотрите использование высокопроизводительных моделей встраиваний, которые хорошо работают локально. Современные модели встраиваний вроде предложений Qwen3 обеспечивают отличную многозначную поддержку и могут значительно улучшить точность вашей системы RAG.

3. Переранжирование для лучших результатов

Даже с более простыми архитектурами RAG добавление этапа переранжирования может значительно улучшить результаты. После первоначального извлечения с помощью векторного поиска модель переранжирования может лучше оценить релевантность. Этот двухэтапный подход часто превосходит более сложные одноэтапные системы, особенно при работе с ограниченным оборудованием.

4. Гибридные стратегии поиска

Комбинирование векторного поиска с традиционным поиском по ключевым словам (BM25) часто дает лучшие результаты, чем любой из них по отдельности. Многие современные векторные базы данных поддерживают гибридный поиск из коробки.

5. Рассмотрите альтернативы векторных хранилищ

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

Рассмотрения развертывания в Docker

Для промышленного саморазмещения контейнеризация вашей установки RAG упрощает развертывание и масштабирование. При запуске Cognee или аналогичных фреймворков с Ollama:

# Запуск Ollama в контейнере
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

# Загрузка ваших моделей
docker exec -it ollama ollama pull gpt-oss:20b

# Настройка Cognee для подключения к конечной точке контейнера

Убедитесь, что правильно настроены передача GPU и монтирование томов для сохранения моделей.

Уроки, извлеченные из опыта

1. Подбор инструментов под оборудование: Cognee разработан для облачных масштабов LLM. Если вы саморазмещаетесь на потребительском оборудовании, более простые архитектуры могут быть более практичными.

2. Структурированный вывод сложен: Получение последовательного соответствия схеме от локальных LLM остается сложной задачей. Если ваше приложение критически зависит от структурированного вывода, либо используйте коммерческие API, либо реализуйте надежную валидацию и логику повторных попыток.

3. Тестируйте рано: Прежде чем привязываться к фреймворку, протестируйте его с вашим конкретным случаем использования и оборудованием. То, что работает в демонстрациях, может не работать в масштабе или с вашими документами.

4. Рассмотрите гибридные подходы: Используйте коммерческие API для сложных задач извлечения и локальные модели для более простых запросов, чтобы сбалансировать стоимость и возможности.

Связанные материалы для чтения

Структурированный вывод с LLM

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

Архитектура и реализация RAG

Для альтернативных или дополняющих подходов к извлечению знаний и поиску:

Встраивание и переранжирование

Улучшение качества извлечения за счет лучших встраиваний и переранжирования:

Инструменты и ресурсы

Внешние ресурсы