mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-04-26 08:56:21 +02:00
Structure the tech specs directory (#836)
Tech spec some subdirectories for different languages
This commit is contained in:
parent
48da6c5f8b
commit
e7efb673ef
423 changed files with 0 additions and 0 deletions
113
docs/tech-specs/ru/architecture-principles.ru.md
Normal file
113
docs/tech-specs/ru/architecture-principles.ru.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Основы архитектуры графа знаний"
|
||||
parent: "Russian (Beta)"
|
||||
---
|
||||
|
||||
# Основы архитектуры графа знаний
|
||||
|
||||
> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
|
||||
|
||||
## Основа 1: Модель графа "Субъект-Предикат-Объект" (SPO)
|
||||
**Решение**: Принять SPO/RDF в качестве основной модели представления знаний.
|
||||
|
||||
**Обоснование**:
|
||||
Обеспечивает максимальную гибкость и совместимость с существующими технологиями графов.
|
||||
Позволяет беспрепятственно переводить в другие языки запросов к графам (например, SPO → Cypher, но не наоборот).
|
||||
Создает основу, которая "открывает множество" возможностей для дальнейшей разработки.
|
||||
Поддерживает как отношения между узлами (SPO), так и отношения между узлами и литералами (RDF).
|
||||
|
||||
**Реализация**:
|
||||
Основная структура данных: `node → edge → {node | literal}`
|
||||
Поддерживать совместимость со стандартами RDF, одновременно поддерживая расширенные операции SPO.
|
||||
|
||||
## Основа 2: Интеграция графа знаний, оптимизированная для LLM
|
||||
**Решение**: Оптимизировать структуру и операции графа знаний для взаимодействия с LLM.
|
||||
|
||||
**Обоснование**:
|
||||
Основной сценарий использования включает взаимодействие LLM с графами знаний.
|
||||
Выбор технологий графов должен отдавать приоритет совместимости с LLM, а не другим соображениям.
|
||||
Обеспечивает потоки обработки естественного языка, использующие структурированные знания.
|
||||
|
||||
**Реализация**:
|
||||
Разрабатывать схемы графов, которые LLM могут эффективно использовать для рассуждений.
|
||||
Оптимизировать для распространенных шаблонов взаимодействия LLM.
|
||||
|
||||
## Основа 3: Навигация по графу на основе встраиваний
|
||||
**Решение**: Реализовать прямое сопоставление между запросами на естественном языке и узлами графа с помощью встраиваний.
|
||||
|
||||
**Обоснование**:
|
||||
Обеспечивает самый простой путь от запроса на естественном языке к навигации по графу.
|
||||
Избегает сложных промежуточных этапов генерации запросов.
|
||||
Предоставляет возможности семантического поиска в структуре графа.
|
||||
|
||||
**Реализация**:
|
||||
`NLP Query → Graph Embeddings → Graph Nodes`
|
||||
Поддерживать представления встраиваний для всех сущностей графа.
|
||||
Поддерживать прямое семантическое сопоставление сходства для разрешения запросов.
|
||||
|
||||
## Основа 4: Распределенное разрешение сущностей с детерминированными идентификаторами
|
||||
**Решение**: Поддерживать параллельное извлечение знаний с детерминированной идентификацией сущностей (правило 80%).
|
||||
|
||||
**Обоснование**:
|
||||
**Идеально**: Извлечение в одном процессе с полной видимостью состояния обеспечивает идеальное разрешение сущностей.
|
||||
**Реальность**: Требования к масштабируемости требуют возможностей параллельной обработки.
|
||||
**Компромисс**: Разработать для детерминированной идентификации сущностей в распределенных процессах.
|
||||
|
||||
**Реализация**:
|
||||
Разработать механизмы для генерации согласованных, уникальных идентификаторов в различных инструментах извлечения знаний.
|
||||
Одна и та же сущность, упомянутая в разных процессах, должна разрешаться в один и тот же идентификатор.
|
||||
Признать, что ~20% крайних случаев могут потребовать альтернативных моделей обработки.
|
||||
Разработать механизмы отката для сложных сценариев разрешения сущностей.
|
||||
|
||||
## Основа 5: Архитектура, управляемая событиями, с публикацией и подпиской
|
||||
**Решение**: Реализовать систему обмена сообщениями pub-sub для координации системы.
|
||||
|
||||
**Обоснование**:
|
||||
Обеспечивает слабую связанность между компонентами извлечения знаний, хранения и запросов.
|
||||
Поддерживает обновления в режиме реального времени и уведомления по всей системе.
|
||||
Облегчает масштабируемые, распределенные рабочие процессы.
|
||||
|
||||
**Реализация**:
|
||||
Координация между компонентами системы с помощью управляемых сообщениями.
|
||||
Потоки событий для обновлений знаний, завершения извлечения и результатов запросов.
|
||||
|
||||
## Основа 6: Взаимодействие агентов с возможностью повторного входа
|
||||
**Решение**: Поддерживать операции pub-sub с возможностью повторного входа для обработки на основе агентов.
|
||||
|
||||
**Обоснование**:
|
||||
Позволяет создавать сложные рабочие процессы агентов, в которых агенты могут инициировать и реагировать друг на друга.
|
||||
Поддерживает сложные, многоступенчатые конвейеры обработки знаний.
|
||||
Позволяет использовать рекурсивные и итеративные шаблоны обработки.
|
||||
|
||||
**Реализация**:
|
||||
Система pub-sub должна безопасно обрабатывать вызовы с повторным входом.
|
||||
Механизмы координации агентов, предотвращающие бесконечные циклы.
|
||||
Поддержка оркестровки рабочих процессов агентов.
|
||||
|
||||
## Основа 7: Интеграция с хранилищем данных в столбцовом формате
|
||||
**Решение**: Обеспечить совместимость запросов с системами хранения данных в столбцовом формате.
|
||||
|
||||
**Обоснование**:
|
||||
Обеспечивает эффективные аналитические запросы к большим наборам данных знаний.
|
||||
Поддерживает сценарии бизнес-аналитики и отчетности.
|
||||
Объединяет представление знаний на основе графов с традиционными аналитическими рабочими процессами.
|
||||
|
||||
**Реализация**:
|
||||
Слой перевода запросов: Запросы графов → Запросы в столбцовом формате.
|
||||
Гибридная стратегия хранения, поддерживающая как операции графов, так и аналитические рабочие нагрузки.
|
||||
Поддерживать производительность запросов в обеих парадигмах.
|
||||
|
||||
--
|
||||
|
||||
## Краткое изложение принципов архитектуры
|
||||
|
||||
1. **Гибкость прежде всего**: Модель SPO/RDF обеспечивает максимальную адаптируемость.
|
||||
2. **Оптимизация для LLM**: Все решения в области проектирования учитывают требования взаимодействия с LLM.
|
||||
3. **Семантическая эффективность**: Прямое сопоставление встраиваний с узлами для оптимальной производительности запросов.
|
||||
4. **Прагматическая масштабируемость**: Баланс между идеальной точностью и практическими возможностями распределенной обработки.
|
||||
5. **Координация, управляемая событиями**: Pub-sub обеспечивает слабую связанность и масштабируемость.
|
||||
6. **Поддержка агентов**: Поддержка сложных рабочих процессов, основанных на нескольких агентах.
|
||||
7. **Совместимость с аналитикой**: Объединение парадигм графов и столбцов для всестороннего запроса.
|
||||
|
||||
Эта архитектура графа знаний сочетает теоретическую строгость с практическими требованиями масштабируемости, оптимизированная для интеграции с LLM и распределенной обработки.
|
||||
Loading…
Add table
Add a link
Reference in a new issue