ваше сообщение коммита
This commit is contained in:
801
docs/DLE_Governance_System.md
Normal file
801
docs/DLE_Governance_System.md
Normal file
@@ -0,0 +1,801 @@
|
||||
# DLE Governance System - Документация
|
||||
|
||||
## 📋 Обзор системы
|
||||
|
||||
DLE (Digital Legal Entity) - это система управления цифровым юридическим лицом с использованием смарт-контрактов и токенов управления. Система включает в себя механизмы голосования, мультиподписи и административного управления.
|
||||
|
||||
## 🏗️ Архитектура системы
|
||||
|
||||
### Текущие смарт-контракты
|
||||
|
||||
#### 1. GovernanceToken.sol
|
||||
```solidity
|
||||
contract GovernanceToken is ERC20Permit, ERC20Votes, Ownable {
|
||||
// Основные функции:
|
||||
- mintInitialSupply(address[] partners, uint256[] amounts) // Начальное распределение токенов
|
||||
- transfer() // Передача токенов
|
||||
- balanceOf() // Проверка баланса
|
||||
- getVotes() // Получение голосов на определенном блоке
|
||||
}
|
||||
```
|
||||
|
||||
#### 2. GovernanceTimelock.sol
|
||||
```solidity
|
||||
contract GovernanceTimelock is TimelockController {
|
||||
// Основные функции:
|
||||
- queue() // Постановка операции в очередь
|
||||
- execute() // Выполнение операции после задержки
|
||||
- cancel() // Отмена операции
|
||||
}
|
||||
```
|
||||
|
||||
#### 3. GovernorContract.sol
|
||||
```solidity
|
||||
contract GovernorContract is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, GovernorVotesQuorumFraction, GovernorTimelockControl {
|
||||
// Основные функции:
|
||||
- propose() // Создание предложения
|
||||
- vote() // Голосование
|
||||
- execute() // Выполнение предложения
|
||||
- cancel() // Отмена предложения
|
||||
}
|
||||
```
|
||||
|
||||
### Текущие параметры системы
|
||||
- **Порог предложения**: 100,000 GT
|
||||
- **Кворум**: 4% от общего количества токенов
|
||||
- **Задержка голосования**: 1 день
|
||||
- **Период голосования**: 7 дней
|
||||
- **Минимальная задержка Timelock**: 2 дня
|
||||
|
||||
## 🔧 Функции приложения
|
||||
|
||||
### Критические функции (требуют голосования)
|
||||
|
||||
#### 🚨 УДАЛЕНИЕ ДАННЫХ
|
||||
|
||||
##### Пользователи
|
||||
```javascript
|
||||
// Удаление пользователя
|
||||
DELETE /api/users/:id
|
||||
- Описание: Полное удаление пользователя и всех связанных данных
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Блокировка пользователя
|
||||
PATCH /api/users/:id/block
|
||||
- Описание: Блокировка пользователя в системе
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
##### Таблицы
|
||||
```javascript
|
||||
// Удаление таблицы
|
||||
DELETE /api/tables/:id
|
||||
- Описание: Удаление таблицы и всех связанных данных
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Удаление строк таблицы
|
||||
DELETE /api/tables/:id/rows
|
||||
- Описание: Массовое удаление строк
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Удаление столбцов таблицы
|
||||
DELETE /api/tables/:id/columns
|
||||
- Описание: Удаление столбцов таблицы
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
##### DLE (Digital Legal Entity)
|
||||
```javascript
|
||||
// Удаление DLE
|
||||
DELETE /api/dle/:tokenAddress
|
||||
- Описание: Удаление DLE по адресу токена
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Удаление пустого DLE
|
||||
DELETE /api/dle/empty/:fileName
|
||||
- Описание: Удаление пустого DLE по имени файла
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
##### Системные настройки
|
||||
```javascript
|
||||
// Удаление RPC провайдера
|
||||
DELETE /api/settings/rpc/:networkId
|
||||
- Описание: Удаление RPC конфигурации
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Удаление токена аутентификации
|
||||
DELETE /api/settings/auth-token/:address/:network
|
||||
- Описание: Удаление токена для аутентификации
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Удаление AI настроек
|
||||
DELETE /api/settings/ai-settings/:provider
|
||||
- Описание: Удаление настроек AI провайдера
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Удаление правил AI ассистента
|
||||
DELETE /api/settings/ai-assistant-rules/:id
|
||||
- Описание: Удаление набора правил AI
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
#### 🏗️ СОЗДАНИЕ КРИТИЧНЫХ СУЩНОСТЕЙ
|
||||
|
||||
##### DLE
|
||||
```javascript
|
||||
// Создание нового DLE
|
||||
POST /api/dle
|
||||
- Описание: Создание нового Digital Legal Entity
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
- Параметры: name, symbol, location, isicCodes, partners, amounts, network, etc.
|
||||
```
|
||||
|
||||
##### Таблицы
|
||||
```javascript
|
||||
// Создание таблицы
|
||||
POST /api/tables
|
||||
- Описание: Создание новой таблицы
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
##### Системные настройки
|
||||
```javascript
|
||||
// Добавление RPC провайдера
|
||||
POST /api/settings/rpc
|
||||
- Описание: Добавление нового RPC провайдера
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Добавление токена аутентификации
|
||||
POST /api/settings/auth-token
|
||||
- Описание: Добавление нового токена для аутентификации
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
#### ⚙️ ИЗМЕНЕНИЕ СИСТЕМНЫХ НАСТРОЕК
|
||||
|
||||
##### База данных
|
||||
```javascript
|
||||
// Изменение настроек БД
|
||||
PUT /api/settings/db-settings
|
||||
- Описание: Изменение параметров подключения к базе данных
|
||||
- Критичность: 🔴 ВЫСОКАЯ
|
||||
- Требует голосования: ДА
|
||||
- Параметры: db_host, db_port, db_name, db_user, db_password
|
||||
```
|
||||
|
||||
##### AI настройки
|
||||
```javascript
|
||||
// Изменение настроек AI ассистента
|
||||
PUT /api/settings/ai-assistant
|
||||
- Описание: Изменение глобальных настроек AI ассистента
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Изменение AI провайдера
|
||||
PUT /api/settings/ai-settings/:provider
|
||||
- Описание: Изменение настроек конкретного AI провайдера
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
##### Коммуникации
|
||||
```javascript
|
||||
// Настройки Email
|
||||
PUT /api/identities/email-settings
|
||||
- Описание: Изменение настроек SMTP/IMAP
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
|
||||
// Настройки Telegram
|
||||
PUT /api/identities/telegram-settings
|
||||
- Описание: Изменение настроек Telegram бота
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ДА
|
||||
```
|
||||
|
||||
### Умеренные функции (опциональное голосование)
|
||||
|
||||
#### 📝 РЕДАКТИРОВАНИЕ ДАННЫХ
|
||||
|
||||
```javascript
|
||||
// Редактирование пользователя
|
||||
PATCH /api/users/:id
|
||||
- Описание: Изменение данных пользователя
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ОПЦИОНАЛЬНО
|
||||
|
||||
// Редактирование таблицы
|
||||
PATCH /api/tables/:id
|
||||
- Описание: Изменение структуры таблицы
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ОПЦИОНАЛЬНО
|
||||
|
||||
// Импорт пользователей
|
||||
POST /api/users/import
|
||||
- Описание: Массовый импорт пользователей
|
||||
- Критичность: 🟡 СРЕДНЯЯ
|
||||
- Требует голосования: ОПЦИОНАЛЬНО
|
||||
```
|
||||
|
||||
### Обычные функции (не требуют голосования)
|
||||
|
||||
#### 📖 ПРОСМОТР ДАННЫХ
|
||||
|
||||
```javascript
|
||||
// Список пользователей
|
||||
GET /api/users
|
||||
- Описание: Получение списка пользователей
|
||||
- Критичность: 🟢 НИЗКАЯ
|
||||
- Требует голосования: НЕТ
|
||||
|
||||
// Список таблиц
|
||||
GET /api/tables
|
||||
- Описание: Получение списка таблиц
|
||||
- Критичность: 🟢 НИЗКАЯ
|
||||
- Требует голосования: НЕТ
|
||||
|
||||
// Список DLE
|
||||
GET /api/dle
|
||||
- Описание: Получение списка DLE
|
||||
- Критичность: 🟢 НИЗКАЯ
|
||||
- Требует голосования: НЕТ
|
||||
|
||||
// Детали пользователя
|
||||
GET /api/users/:id
|
||||
- Описание: Получение детальной информации о пользователе
|
||||
- Критичность: 🟢 НИЗКАЯ
|
||||
- Требует голосования: НЕТ
|
||||
```
|
||||
|
||||
#### ✏️ РЕДАКТИРОВАНИЕ ЯЧЕЕК
|
||||
|
||||
```javascript
|
||||
// Изменение значения ячейки
|
||||
PATCH /api/tables/cell
|
||||
- Описание: Изменение значения конкретной ячейки таблицы
|
||||
- Критичность: 🟢 НИЗКАЯ
|
||||
- Требует голосования: НЕТ
|
||||
```
|
||||
|
||||
## 🎯 Система голосования
|
||||
|
||||
### Текущая реализация
|
||||
|
||||
#### Процесс голосования
|
||||
1. **Создание предложения** - пользователь с достаточным количеством токенов создает предложение
|
||||
2. **Период голосования** - 7 дней для голосования
|
||||
3. **Подсчет голосов** - проверка кворума (4% от общего количества токенов)
|
||||
4. **Постановка в очередь** - успешные предложения ставятся в очередь Timelock
|
||||
5. **Выполнение** - после задержки (2 дня) предложение выполняется
|
||||
|
||||
#### Параметры голосования
|
||||
- **Порог для создания предложений**: 100,000 GT
|
||||
- **Кворум**: 4% от общего количества токенов
|
||||
- **Задержка голосования**: 1 день (в блоках)
|
||||
- **Период голосования**: 7 дней (в блоках)
|
||||
- **Минимальная задержка Timelock**: 2 дня
|
||||
|
||||
### Предлагаемые улучшения
|
||||
|
||||
#### Новый модуль: AdminGovernanceModule
|
||||
|
||||
```solidity
|
||||
contract AdminGovernanceModule {
|
||||
struct AdminAction {
|
||||
string actionType; // Тип действия
|
||||
string targetId; // ID цели
|
||||
bytes actionData; // Данные действия
|
||||
uint256 proposalId; // ID предложения
|
||||
bool executed; // Выполнено ли
|
||||
uint256 createdAt; // Время создания
|
||||
}
|
||||
|
||||
mapping(uint256 => AdminAction) public adminActions;
|
||||
mapping(string => bool) public actionTypesRequiringVote;
|
||||
|
||||
// Функции
|
||||
function proposeAdminAction(string memory actionType, string memory targetId, bytes memory actionData) external returns (uint256);
|
||||
function executeAdminAction(uint256 actionId) external;
|
||||
function canExecuteAction(address executor, string memory actionType) external view returns (bool);
|
||||
}
|
||||
```
|
||||
|
||||
#### Типы административных действий
|
||||
|
||||
```solidity
|
||||
// Критические действия (обязательное голосование)
|
||||
"DELETE_USER" // Удаление пользователя
|
||||
"DELETE_DLE" // Удаление DLE
|
||||
"DELETE_TABLE" // Удаление таблицы
|
||||
"CREATE_DLE" // Создание DLE
|
||||
"UPDATE_DB_SETTINGS" // Изменение настроек БД
|
||||
"UPDATE_RPC" // Изменение RPC настроек
|
||||
"UPDATE_AUTH_TOKENS" // Изменение токенов аутентификации
|
||||
|
||||
// Важные действия (опциональное голосование)
|
||||
"CREATE_TABLE" // Создание таблицы
|
||||
"UPDATE_AI_SETTINGS" // Изменение AI настроек
|
||||
"UPDATE_EMAIL_SETTINGS" // Изменение email настроек
|
||||
"UPDATE_TELEGRAM_SETTINGS" // Изменение telegram настроек
|
||||
"IMPORT_USERS" // Импорт пользователей
|
||||
```
|
||||
|
||||
## 🔐 Система доступа
|
||||
|
||||
### Текущая система ролей
|
||||
|
||||
#### Роли пользователей
|
||||
- **Администратор** - полный доступ ко всем функциям
|
||||
- **Пользователь** - ограниченный доступ
|
||||
|
||||
#### Проверка прав
|
||||
```javascript
|
||||
// Middleware для проверки администратора
|
||||
requireAdmin(req, res, next) {
|
||||
// Проверка через сессию
|
||||
if (req.session.isAdmin) return next();
|
||||
|
||||
// Проверка через кошелек
|
||||
if (req.session.address) {
|
||||
const isAdmin = await authService.checkAdminTokens(req.session.address);
|
||||
if (isAdmin) return next();
|
||||
}
|
||||
|
||||
// Проверка через ID пользователя
|
||||
if (req.session.userId) {
|
||||
const user = await db.getQuery()('SELECT role FROM users WHERE id = $1', [req.session.userId]);
|
||||
if (user.rows[0].role === 'admin') return next();
|
||||
}
|
||||
|
||||
return res.status(403).json({ error: 'Доступ запрещен' });
|
||||
}
|
||||
```
|
||||
|
||||
### Предлагаемая система доступа с токенами
|
||||
|
||||
#### Проверка через смарт-контракт
|
||||
```solidity
|
||||
function canExecuteAction(address executor, string memory actionType) public view returns (bool) {
|
||||
// Проверка баланса токенов
|
||||
uint256 balance = governanceToken.balanceOf(executor);
|
||||
|
||||
// Проверка типа действия
|
||||
if (actionTypesRequiringVote[actionType]) {
|
||||
return balance >= proposalThreshold;
|
||||
}
|
||||
|
||||
// Для некритических действий достаточно быть администратором
|
||||
return adminService.isAdmin(executor);
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 Модули DLE
|
||||
|
||||
### Текущие модули
|
||||
|
||||
#### Доступные модули
|
||||
1. **Контракт на активы** - токенизация физических активов
|
||||
2. **Мультиподпись** - повышенная безопасность
|
||||
3. **Дивиденды** - распределение дивидендов между держателями
|
||||
4. **Стейкинг** - стейкинг токенов для получения наград
|
||||
5. **Прием платежей** - прием оплаты в выбранных токенах
|
||||
|
||||
#### Предлагаемый модуль: Административное голосование
|
||||
```javascript
|
||||
{
|
||||
name: 'Административное голосование',
|
||||
description: 'Добавляет систему голосования для административных действий',
|
||||
installed: false,
|
||||
features: [
|
||||
'Голосование за удаление пользователей',
|
||||
'Голосование за создание таблиц',
|
||||
'Голосование за изменение системных настроек',
|
||||
'Интеграция с существующими контрактами DLE'
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 🚀 План реализации
|
||||
|
||||
### Этап 1: Анализ и проектирование
|
||||
- [x] Анализ текущих функций приложения
|
||||
- [x] Определение критических операций
|
||||
- [x] Проектирование архитектуры системы голосования
|
||||
|
||||
### Этап 2: Разработка смарт-контрактов
|
||||
- [ ] Создание AdminGovernanceModule
|
||||
- [ ] Расширение GovernorContract
|
||||
- [ ] Создание интерфейсов для взаимодействия
|
||||
|
||||
### Этап 3: Интеграция с приложением
|
||||
- [ ] Создание сервиса для работы с голосованием
|
||||
- [ ] Интеграция с существующими API
|
||||
- [ ] Обновление middleware для проверки прав
|
||||
|
||||
### Этап 4: Обновление UI
|
||||
- [ ] Создание интерфейса для управления предложениями
|
||||
- [ ] Интеграция с модульной системой DLE
|
||||
- [ ] Добавление уведомлений о голосованиях
|
||||
|
||||
### Этап 5: Тестирование и развертывание
|
||||
- [ ] Тестирование смарт-контрактов
|
||||
- [ ] Интеграционное тестирование
|
||||
- [ ] Развертывание в production
|
||||
|
||||
## 📝 Заключение
|
||||
|
||||
Текущая система DLE предоставляет базовую функциональность управления через токены, но требует расширения для полной интеграции с административными функциями приложения. Предлагаемая система голосования позволит обеспечить безопасность и прозрачность при выполнении критических операций.
|
||||
|
||||
### Ключевые преимущества предлагаемого решения:
|
||||
1. **Безопасность** - все критические операции требуют голосования
|
||||
2. **Прозрачность** - все действия записываются в блокчейн
|
||||
3. **Гибкость** - возможность настройки уровней критичности
|
||||
4. **Интеграция** - использование существующей инфраструктуры DLE
|
||||
5. **Модульность** - возможность включения/выключения функций
|
||||
|
||||
---
|
||||
|
||||
# 🏗️ Архитектура DLE как цифрового акционерного общества
|
||||
|
||||
## 🎯 Концепция DLE
|
||||
|
||||
DLE (Digital Legal Entity) - это **цифровое акционерное общество**, где смарт-контракт сам по себе является **цифровым ИНН организации** со всеми функциями традиционного АО.
|
||||
|
||||
### **Основная аналогия:**
|
||||
```
|
||||
Акционерное общество:
|
||||
├── ИНН (идентификатор)
|
||||
├── Банковский счет (финансы)
|
||||
├── Юридический адрес
|
||||
├── Контакты (телефон, email)
|
||||
├── Коды деятельности (ОКВЭД)
|
||||
├── Акционеры (владельцы)
|
||||
├── Управление (голосование)
|
||||
└── Участие в других организациях
|
||||
|
||||
DLE (цифровой аналог):
|
||||
├── Адрес контракта (идентификатор)
|
||||
├── Токены управления (акции)
|
||||
├── Цифровой адрес (блокчейн)
|
||||
├── Контакты (веб-интерфейс)
|
||||
├── Коды деятельности (ISIC)
|
||||
├── Держатели токенов (акционеры)
|
||||
├── Система голосования
|
||||
└── Участие в других DLE
|
||||
```
|
||||
|
||||
## 📋 Формы для ручного деплоя смарт-контрактов
|
||||
|
||||
### **Основная форма деплоя DLE:**
|
||||
|
||||
#### **Блок 1: Идентификация (ИНН)**
|
||||
```
|
||||
- Название организации (name)
|
||||
- Символ токена (symbol)
|
||||
- Описание деятельности (businessDescription)
|
||||
- Юридический адрес (legalAddress)
|
||||
- Контактная информация (contactInfo)
|
||||
```
|
||||
|
||||
#### **Блок 2: Коды деятельности (ISIC)**
|
||||
```
|
||||
- Выбор секций ISIC (A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U)
|
||||
- Выбор разделов (2-значные коды)
|
||||
- Выбор групп (3-значные коды)
|
||||
- Выбор классов (4-значные коды)
|
||||
- Дополнительные коды деятельности
|
||||
```
|
||||
|
||||
#### **Блок 3: Финансы (банковский счет)**
|
||||
```
|
||||
- Начальное распределение токенов (partners[], amounts[])
|
||||
- Общее количество токенов (totalSupply)
|
||||
- Минимальный баланс для голосования (proposalThreshold)
|
||||
- Кворум для принятия решений (quorumPercentage)
|
||||
```
|
||||
|
||||
#### **Блок 4: Управление (акционерное собрание)**
|
||||
```
|
||||
- Задержка голосования (votingDelay)
|
||||
- Период голосования (votingPeriod)
|
||||
- Минимальная задержка выполнения (timelockMinDelay)
|
||||
- Тип управления (демократическое/олигархическое)
|
||||
```
|
||||
|
||||
#### **Блок 5: Мультиподпись**
|
||||
```
|
||||
- Количество требуемых подписей (requiredSignatures)
|
||||
- Список авторизованных подписантов (authorizedSigners[])
|
||||
- Временные ограничения на подписание
|
||||
- Типы операций, требующие мультиподпись
|
||||
```
|
||||
|
||||
#### **Блок 6: Коммуникация**
|
||||
```
|
||||
- Веб-сайт организации (website)
|
||||
- Email для связи (contactEmail)
|
||||
- Телефон для связи (contactPhone)
|
||||
- Адрес для сообщений (communicationAddress)
|
||||
```
|
||||
|
||||
## 🏗️ Типы и функции смарт-контрактов
|
||||
|
||||
### **Основной контракт: DigitalLegalEntity.sol**
|
||||
|
||||
#### **A. Функции идентификации:**
|
||||
```solidity
|
||||
- getName() - получение названия
|
||||
- getSymbol() - получение символа
|
||||
- getContractAddress() - получение адреса (ИНН)
|
||||
- getBusinessDescription() - получение описания
|
||||
- getLegalAddress() - получение юр. адреса
|
||||
- getContactInfo() - получение контактов
|
||||
```
|
||||
|
||||
#### **B. Функции кодов деятельности:**
|
||||
```solidity
|
||||
- getIsicCodes() - получение кодов ISIC
|
||||
- addIsicCode(string code) - добавление кода
|
||||
- removeIsicCode(string code) - удаление кода
|
||||
- updateBusinessDescription(string description) - обновление описания
|
||||
```
|
||||
|
||||
#### **C. Финансовые функции:**
|
||||
```solidity
|
||||
- receive() - прием ETH
|
||||
- receiveERC20(address token, uint256 amount) - прием токенов
|
||||
- getBalance() - получение баланса
|
||||
- distributePayment(address[] recipients, uint256[] amounts) - распределение
|
||||
- mintTokens(address to, uint256 amount) - эмиссия токенов
|
||||
- transferTokens(address to, uint256 amount) - передача токенов
|
||||
- getTotalSupply() - общее количество токенов
|
||||
```
|
||||
|
||||
#### **D. Функции управления:**
|
||||
```solidity
|
||||
- createProposal(string title, string description, ProposalType type) - создание предложения
|
||||
- vote(uint256 proposalId, bool support) - голосование
|
||||
- executeProposal(uint256 proposalId) - выполнение предложения
|
||||
- cancelProposal(uint256 proposalId) - отмена предложения
|
||||
- getProposalStatus(uint256 proposalId) - статус предложения
|
||||
- getVotingPower(address account) - голосующая сила
|
||||
```
|
||||
|
||||
#### **E. Функции участия в других DLE:**
|
||||
```solidity
|
||||
- participateInDLE(address dleAddress, uint256 tokens) - участие в другом DLE
|
||||
- voteInOtherDLE(address dleAddress, uint256 proposalId, bool support) - голосование в другом DLE
|
||||
- getParticipation(address dleAddress) - получение информации об участии
|
||||
- withdrawFromDLE(address dleAddress, uint256 tokens) - выход из DLE
|
||||
```
|
||||
|
||||
#### **F. Функции мультиподписи:**
|
||||
```solidity
|
||||
- requireMultiSignature(bytes32 operationId, uint256 requiredSignatures) - требование мультиподписи
|
||||
- signOperation(bytes32 operationId) - подписание операции
|
||||
- getSignatureCount(bytes32 operationId) - количество подписей
|
||||
- addAuthorizedSigner(address signer) - добавление подписанта
|
||||
- removeAuthorizedSigner(address signer) - удаление подписанта
|
||||
```
|
||||
|
||||
#### **G. Коммуникационные функции:**
|
||||
```solidity
|
||||
- sendMessage(string message, string senderInfo) - отправка сообщения
|
||||
- respondToMessage(uint256 messageId, string response) - ответ на сообщение
|
||||
- initiateCall(string callerInfo, string purpose) - запрос звонка
|
||||
- acceptCall(uint256 callId, string response) - принятие звонка
|
||||
- rejectCall(uint256 callId, string reason) - отклонение звонка
|
||||
```
|
||||
|
||||
## 🧩 Модули для настройки смарт-контракта
|
||||
|
||||
### **Базовые модули:**
|
||||
|
||||
#### **Модуль 1: Управление токенами**
|
||||
```
|
||||
Функции:
|
||||
- Эмиссия новых токенов
|
||||
- Сжигание токенов
|
||||
- Замораживание/размораживание токенов
|
||||
- Делегирование голосов
|
||||
- Настройка прав доступа
|
||||
|
||||
Настройки:
|
||||
- Максимальное количество токенов
|
||||
- Минимальный баланс для голосования
|
||||
- Период блокировки токенов
|
||||
- Комиссии за операции
|
||||
```
|
||||
|
||||
#### **Модуль 2: Система голосования**
|
||||
```
|
||||
Функции:
|
||||
- Создание различных типов предложений
|
||||
- Настройка параметров голосования
|
||||
- Автоматическое выполнение решений
|
||||
- Отмена предложений
|
||||
- Делегирование голосов
|
||||
|
||||
Настройки:
|
||||
- Кворум для разных типов решений
|
||||
- Период голосования
|
||||
- Задержка выполнения
|
||||
- Порог для создания предложений
|
||||
```
|
||||
|
||||
#### **Модуль 3: Мультиподпись**
|
||||
```
|
||||
Функции:
|
||||
- Настройка количества подписей
|
||||
- Управление подписантами
|
||||
- Временные ограничения
|
||||
- Отмена подписей
|
||||
- Автоматическое выполнение
|
||||
|
||||
Настройки:
|
||||
- Количество требуемых подписей
|
||||
- Список авторизованных подписантов
|
||||
- Время действия подписей
|
||||
- Типы операций, требующие мультиподписи
|
||||
```
|
||||
|
||||
#### **Модуль 4: Финансовое управление**
|
||||
```
|
||||
Функции:
|
||||
- Управление балансами
|
||||
- Распределение дивидендов
|
||||
- Инвестирование средств
|
||||
- Конвертация валют
|
||||
- Управление портфелем
|
||||
|
||||
Настройки:
|
||||
- Автоматическое распределение дивидендов
|
||||
- Инвестиционные лимиты
|
||||
- Валютные пары для конвертации
|
||||
- Комиссии за операции
|
||||
```
|
||||
|
||||
#### **Модуль 5: Участие в других DLE**
|
||||
```
|
||||
Функции:
|
||||
- Покупка токенов других DLE
|
||||
- Голосование в других DLE
|
||||
- Управление портфелем участий
|
||||
- Автоматическое голосование
|
||||
- Отчетность по участиям
|
||||
|
||||
Настройки:
|
||||
- Лимиты на участие в других DLE
|
||||
- Стратегии голосования
|
||||
- Автоматические действия
|
||||
- Уведомления о важных событиях
|
||||
```
|
||||
|
||||
#### **Модуль 6: Коммуникация**
|
||||
```
|
||||
Функции:
|
||||
- Управление сообщениями
|
||||
- Настройка уведомлений
|
||||
- Автоматические ответы
|
||||
- Интеграция с внешними сервисами
|
||||
- Архив коммуникаций
|
||||
|
||||
Настройки:
|
||||
- Автоматические ответы
|
||||
- Фильтры сообщений
|
||||
- Интеграции (email, telegram, slack)
|
||||
- Шаблоны ответов
|
||||
```
|
||||
|
||||
#### **Модуль 7: Безопасность**
|
||||
```
|
||||
Функции:
|
||||
- Многофакторная аутентификация
|
||||
- Временные блокировки
|
||||
- Аудит операций
|
||||
- Восстановление доступа
|
||||
- Мониторинг безопасности
|
||||
|
||||
Настройки:
|
||||
- Уровни безопасности
|
||||
- Временные ограничения
|
||||
- Список доверенных адресов
|
||||
- Автоматические блокировки
|
||||
```
|
||||
|
||||
#### **Модуль 8: Отчетность**
|
||||
```
|
||||
Функции:
|
||||
- Генерация финансовых отчетов
|
||||
- Отчеты о голосованиях
|
||||
- Отчеты об участиях
|
||||
- Налоговая отчетность
|
||||
- Экспорт данных
|
||||
|
||||
Настройки:
|
||||
- Периодичность отчетов
|
||||
- Форматы экспорта
|
||||
- Автоматическая отправка
|
||||
- Шаблоны отчетов
|
||||
```
|
||||
|
||||
## 🔄 Интеграция модулей
|
||||
|
||||
### **Связи между модулями:**
|
||||
```
|
||||
Управление токенами ↔ Система голосования
|
||||
Финансовое управление ↔ Участие в других DLE
|
||||
Мультиподпись ↔ Все критические операции
|
||||
Безопасность ↔ Все модули
|
||||
Отчетность ↔ Все модули
|
||||
Коммуникация ↔ Все модули
|
||||
```
|
||||
|
||||
### **Настройка модулей:**
|
||||
```
|
||||
1. Активация/деактивация модулей
|
||||
2. Настройка параметров каждого модуля
|
||||
3. Установка связей между модулями
|
||||
4. Тестирование функциональности
|
||||
5. Развертывание в production
|
||||
```
|
||||
|
||||
## 🎯 Ключевые особенности DLE
|
||||
|
||||
### **1. Единый идентификатор:**
|
||||
- Адрес смарт-контракта = ИНН организации
|
||||
- Все функции доступны через один адрес
|
||||
- Полная прозрачность всех операций
|
||||
|
||||
### **2. Автоматизация:**
|
||||
- Автоматическое выполнение решений
|
||||
- Автоматическое распределение дивидендов
|
||||
- Автоматическая отчетность
|
||||
|
||||
### **3. Безопасность:**
|
||||
- Мультиподпись для критических операций
|
||||
- Временные задержки для важных решений
|
||||
- Полный аудит в блокчейне
|
||||
|
||||
### **4. Масштабируемость:**
|
||||
- Участие в неограниченном количестве других DLE
|
||||
- Настраиваемые параметры для разных типов операций
|
||||
- Модульная архитектура для добавления новых функций
|
||||
|
||||
## 🏆 Преимущества DLE над традиционным АО
|
||||
|
||||
### **Эффективность:**
|
||||
- Мгновенные платежи и переводы
|
||||
- Автоматическое выполнение решений
|
||||
- Снижение бюрократических процедур
|
||||
|
||||
### **Прозрачность:**
|
||||
- Все операции видны в блокчейне
|
||||
- Невозможность подделки документов
|
||||
- Полная история всех действий
|
||||
|
||||
### **Глобальность:**
|
||||
- Работа без границ
|
||||
- Участие в международных проектах
|
||||
- Мультивалютные операции
|
||||
|
||||
### **Инновационность:**
|
||||
- Интеграция с DeFi протоколами
|
||||
- Участие в DAO экосистеме
|
||||
- Доступ к новым финансовым инструментам
|
||||
101
docs/RAG_ASSISTANT_INTEGRATION.md
Normal file
101
docs/RAG_ASSISTANT_INTEGRATION.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Интеграция RAG-ассистента для бизнеса с поддержкой продуктов, сегментов клиентов и LLM
|
||||
|
||||
## Цель
|
||||
|
||||
Реализовать интеллектуального ассистента для бизнеса, который:
|
||||
- Использует RAG-таблицы для хранения вопросов, ответов, уточняющих вопросов, ответов на возражения и дополнительного контекста.
|
||||
- Поддерживает фильтрацию по продуктам, сегментам клиентов (тегам), приоритету, дате и другим бизнес-полям.
|
||||
- Интегрируется с LLM (Ollama/OpenAI) для генерации финального ответа на основе найденного контекста.
|
||||
- Позволяет настраивать системный промт с плейсхолдерами для гибкой персонализации ответов.
|
||||
- Позволяет генерировать draft-ответ для администратора, который может быть отредактирован и отправлен вручную.
|
||||
|
||||
---
|
||||
|
||||
## Основные требования
|
||||
|
||||
1. **Гибкая структура RAG-таблицы**
|
||||
- Пользователь может создавать таблицы с произвольными столбцами и назначать им специальное значение (purpose) через выпадающий список:
|
||||
- Вопрос (`question`)
|
||||
- Ответ (`answer`)
|
||||
- Ответ с уточняющим вопросом (`clarifyingAnswer`)
|
||||
- Ответ на возражение (`objectionAnswer`)
|
||||
- Теги пользователя/сегмента (`userTags`)
|
||||
- Продукт/услуга (`product`)
|
||||
- Дополнительный контекст (`context`)
|
||||
- Приоритет (`priority`)
|
||||
- Дата (`date`)
|
||||
- Для каждого столбца указывается назначение при создании/редактировании.
|
||||
- Можно добавлять дополнительные столбцы для бизнес-атрибутов.
|
||||
|
||||
2. **Фильтрация и поиск**
|
||||
- При поступлении вопроса пользователя:
|
||||
- Фильтровать строки по продукту, тегам пользователя, приоритету, дате и другим полям.
|
||||
- Выполнять векторный поиск (embedding) только по релевантным строкам (по столбцу "Вопрос").
|
||||
|
||||
3. **Интеграция с LLM**
|
||||
- После поиска по RAG-таблице формировать системный промт с подстановкой найденных данных (через плейсхолдеры).
|
||||
- Передавать промт и вопрос пользователя в LLM (Ollama/OpenAI).
|
||||
- Возвращать финальный ответ пользователю.
|
||||
|
||||
4. **Плейсхолдеры для промта**
|
||||
- Поддерживаются плейсхолдеры:
|
||||
- `{context}` — дополнительная информация
|
||||
- `{answer}` — основной ответ
|
||||
- `{clarifyingAnswer}` — уточняющий вопрос
|
||||
- `{objectionAnswer}` — ответ на возражение
|
||||
- `{question}` — вопрос пользователя
|
||||
- `{userTags}` — теги пользователя
|
||||
- `{product}` — продукт/услуга
|
||||
- `{priority}` — приоритет
|
||||
- `{date}` — дата
|
||||
- `{rules}` — описание применённых правил
|
||||
- `{history}` — история диалога
|
||||
- `{model}` — используемая LLM
|
||||
- `{language}` — язык ответа
|
||||
|
||||
5. **Кэширование embedding**
|
||||
- Для ускорения поиска embedding для вопросов кэшируются в БД.
|
||||
- При изменении вопроса embedding обновляется.
|
||||
|
||||
6. **Логирование и аналитика**
|
||||
- Логируются все этапы работы ассистента: запрос пользователя, найденный контекст, результат LLM, время ответа, id пользователя и т.д.
|
||||
- Вся информация сохраняется для последующего анализа и улучшения качества ответов.
|
||||
|
||||
7. **Автоответ и draft-ответ**
|
||||
- Если найден релевантный вопрос (score > 0.95) — ассистент автоматически отвечает пользователю.
|
||||
- Если нет — ассистент генерирует draft-ответ для администратора (через роут `/ai-draft`), который подставляется в поле ввода и ожидает отправки админом. Draft генерируется всегда, даже если нет точного совпадения в RAG.
|
||||
- Draft-ответ строится с учётом промта, истории и всех доступных данных из RAG.
|
||||
|
||||
---
|
||||
|
||||
## Пример бизнес-сценария
|
||||
|
||||
- Клиент B2B интересуется продуктом "ProductX".
|
||||
- Вопрос: "Как интегрировать ваш продукт с нашей ERP?"
|
||||
- Система фильтрует строки по `product = "ProductX"` и тегу `B2B`.
|
||||
- Векторный поиск проводится только по релевантным строкам.
|
||||
- В системном промте используются плейсхолдеры для подстановки найденных данных.
|
||||
- LLM генерирует финальный ответ с учётом контекста, уточняющих вопросов и ответов на возражения.
|
||||
- Если точного совпадения нет — draft-ответ для администратора формируется на основе промта и истории.
|
||||
|
||||
---
|
||||
|
||||
## Пример системного промта
|
||||
|
||||
```
|
||||
Ты — ассистент компании. Пользователь интересуется продуктом: {product}, сегмент: {userTags}.
|
||||
Используй только релевантные ответы и контекст для этого продукта и типа клиента.
|
||||
Контекст: {context}
|
||||
Ответ: {answer}
|
||||
Уточняющий вопрос: {clarifyingAnswer}
|
||||
Ответ на возражение: {objectionAnswer}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Результат
|
||||
|
||||
- Персонализированные, точные и масштабируемые ответы для разных продуктов и сегментов клиентов.
|
||||
- Гибкая настройка ассистента через UI и системный промт.
|
||||
- Возможность расширения под любые бизнес-сценарии.
|
||||
- Draft-ответы для администратора, которые можно редактировать и отправлять вручную.
|
||||
207
docs/RAG_TASKS.md
Normal file
207
docs/RAG_TASKS.md
Normal file
@@ -0,0 +1,207 @@
|
||||
# Внедрение RAG-ассистента: поэтапный план
|
||||
|
||||
---
|
||||
|
||||
## Особенности проекта: разнообразие клиентов, каналов и данных
|
||||
|
||||
- **Клиенты:**
|
||||
- Различные сегменты: B2B, B2C, VIP, оптовые и розничные покупатели, корпоративные клиенты, частные лица и др.
|
||||
- Различные сценарии взаимодействия (покупка, поддержка, консультация, возврат и т.д.).
|
||||
|
||||
- **Каналы коммуникации:**
|
||||
- Веб-чат
|
||||
- Email
|
||||
- Telegram/мессенджеры
|
||||
- Возможна интеграция с другими каналами (WhatsApp, телефон и др.)
|
||||
|
||||
- **Типы данных:**
|
||||
- Текстовые сообщения
|
||||
- Аудио, видео, изображения (мультимодальные данные)
|
||||
- Вложения (документы, сканы, фото товаров и т.д.)
|
||||
|
||||
- **Языки:**
|
||||
- Русский
|
||||
- Английский
|
||||
- Испанский
|
||||
- Китайский
|
||||
- Возможность расширения на другие языки
|
||||
|
||||
- **Товары и услуги:**
|
||||
- Широкий ассортимент товаров (разные категории, бренды, характеристики)
|
||||
- Различные услуги (консультации, сервис, доставка, гарантия, возврат и др.)
|
||||
- Возможность кросс-продаж и рекомендаций
|
||||
|
||||
- **Требования к RAG:**
|
||||
- Гибкая фильтрация знаний по сегменту клиента, языку, категории товара/услуги, каналу обращения
|
||||
- Поддержка мультиязычности и мультимодальности
|
||||
- Масштабируемость для добавления новых ассистентов, сегментов, каналов и языков
|
||||
|
||||
---
|
||||
|
||||
## Этап 1. Проектирование и подготовка инфраструктуры
|
||||
1. **Проектирование схемы хранения знаний (RAG):**
|
||||
- Описать структуру таблицы `knowledge_documents` (миграция).
|
||||
- Определить поля: id, content, language, type (текст/медиа), метаданные, дата, автор и т.д.
|
||||
2. **Подготовка backend:**
|
||||
- Создать миграцию и модель для `knowledge_documents`.
|
||||
- Подготовить базовые CRUD-эндпоинты для работы с базой знаний.
|
||||
|
||||
---
|
||||
|
||||
## Этап 2. Интеграция векторного поиска (RAG)
|
||||
1. **Реализация векторного хранилища:**
|
||||
- Реализовать методы инициализации и поиска (`initVectorStore`, `findSimilarDocuments`) в `ai-assistant.js`.
|
||||
- Настроить хранение эмбеддингов для документов.
|
||||
2. **API для поиска знаний:**
|
||||
- Добавить эндпоинт для поиска релевантных знаний по запросу пользователя.
|
||||
|
||||
---
|
||||
|
||||
## Этап 3. Интеграция RAG в pipeline ассистента
|
||||
1. **Модификация логики ответа ассистента:**
|
||||
- При получении сообщения пользователя — искать релевантные знания и включать их в prompt LLM.
|
||||
- Обеспечить мультиязычность поиска и генерации ответа.
|
||||
2. **Логирование и трассировка:**
|
||||
- Сохранять, какие знания были использованы для ответа.
|
||||
|
||||
---
|
||||
|
||||
## Этап 4. Интерфейс для админа
|
||||
1. **UI для управления знаниями:**
|
||||
- Добавить на фронте раздел для просмотра, добавления, редактирования и удаления знаний.
|
||||
2. **UI для модерации ответов ассистента:**
|
||||
- Кнопки "Редактировать", "Отправить", "Добавить в RAG" для сообщений и ответов.
|
||||
- Возможность быстро добавить сообщение пользователя или ответ ассистента в базу знаний.
|
||||
|
||||
---
|
||||
|
||||
## Этап 5. Поддержка мультимодальности и мультиязычности
|
||||
1. **Обработка вложений (аудио, видео, картинки):**
|
||||
- Решить, как хранить и индексировать такие данные (например, хранить ссылки и метаданные, а не сами файлы).
|
||||
2. **Мультиязычный поиск и генерация:**
|
||||
- Проверить корректность работы эмбеддингов и LLM для разных языков.
|
||||
|
||||
---
|
||||
|
||||
## Этап 6. Тестирование и оптимизация
|
||||
1. **Покрытие тестами ключевых сценариев (unit, интеграционные).**
|
||||
2. **Оптимизация скорости поиска и генерации.**
|
||||
3. **Документация для команды.**
|
||||
|
||||
---
|
||||
|
||||
## Бизнес-логика управления знаниями и тегами для RAG-ассистента
|
||||
|
||||
### 1. Гибкая система тегов и связей с пользователями
|
||||
- Пользователь может создавать собственные таблицы тегов (например, "покупатель", "поставщик", "VIP-клиент" и т.д.).
|
||||
- В таблице тегов должна быть возможность добавлять ссылки (relation) на пользователей из таблицы `users`.
|
||||
- Для одного тега может быть привязано несколько пользователей (мультисвязь).
|
||||
- Для одного пользователя может быть несколько тегов.
|
||||
|
||||
### 2. Управление знаниями (FAQ, инструкции, ответы)
|
||||
- Пользователь может создавать таблицы с вопросами и ответами (например, FAQ для определённой группы клиентов).
|
||||
- Каждая запись (вопрос-ответ) может быть связана с определённым тегом или группой тегов.
|
||||
- Возможна фильтрация и поиск знаний по тегам, языку, типу клиента и другим параметрам.
|
||||
|
||||
### 3. Использование тегов и знаний в RAG-ассистенте
|
||||
- При обработке запроса пользователя RAG-ассистент определяет его теги (по связям в таблице тегов).
|
||||
- Для генерации ответа ассистент использует только те знания (вопросы/ответы), которые соответствуют тегам пользователя.
|
||||
- Администратор может добавлять новые теги, связывать их с пользователями, а также создавать и редактировать знания для каждой группы.
|
||||
|
||||
### 4. UI/UX требования
|
||||
- В интерфейсе создания/редактирования пользовательских таблиц должен быть доступен тип столбца "relation" (связь с users).
|
||||
- Для ячеек типа "relation" реализовать выпадающий список с поиском по пользователям.
|
||||
- Для таблиц знаний — возможность выбора одного или нескольких тегов для каждой записи.
|
||||
|
||||
**Пример структуры:**
|
||||
- Таблица `user_tags`: id, name, [user_id (relation, мультисвязь)]
|
||||
- Таблица `faq`: id, question, answer, [tag_id (relation, мультисвязь)]
|
||||
|
||||
**Применение:**
|
||||
- RAG-ассистент использует связи между пользователями, тегами и знаниями для персонализации ответов и поиска релевантной информации.
|
||||
|
||||
### 5. Безопасность и контроль
|
||||
- Только администратор может создавать и редактировать системные теги и знания.
|
||||
- Обычные пользователи могут видеть только свои теги и связанные с ними знания.
|
||||
|
||||
---
|
||||
|
||||
## Требования к CRM-интерфейсу для работы с контактами, тегами и настройками RAG-ассистента
|
||||
|
||||
### 1. Раздел "Контакты" в CRM
|
||||
- **Фильтры:**
|
||||
- Новые пользователи (по дате создания или статусу "новый").
|
||||
- Новые входящие сообщения (по наличию непрочитанных/неотвеченных сообщений).
|
||||
- Теги (мультиселект по тегам пользователя).
|
||||
- **Детали контакта:**
|
||||
- Просмотр истории сообщений.
|
||||
- Список тегов пользователя.
|
||||
- Добавление/удаление тегов через выпадающий список или автокомплит (создание связи в таблице user_tags).
|
||||
|
||||
### 2. Настройки ИИ-ассистента
|
||||
- **Выбор RAG-таблиц:**
|
||||
- В настройках ассистента отображается список всех доступных RAG-таблиц.
|
||||
- Администратор выбирает (чекбоксами или мультиселектом), какие таблицы использовать для поиска ответов.
|
||||
- Для каждой выбранной таблицы отображается список тегов, которые она содержит.
|
||||
- **Связь с тегами:**
|
||||
- При генерации ответа ИИ использует только те RAG-таблицы и записи, которые соответствуют тегам пользователя.
|
||||
|
||||
### 3. Рекомендации по интерфейсу (Vue)
|
||||
- Компоненты:
|
||||
- `ContactList.vue` — фильтры, список пользователей
|
||||
- `ContactDetails.vue` — история сообщений, теги, добавление тегов
|
||||
- `AssistantSettings.vue` — выбор RAG-таблиц
|
||||
- `RagTableSelector.vue` — список таблиц с чекбоксами
|
||||
- `TagList.vue` — просмотр тегов в выбранной таблице
|
||||
|
||||
### 4. Схема действий администратора
|
||||
1. В разделе "Контакты" находит нового пользователя/сообщение через фильтры.
|
||||
2. В деталях контакта добавляет нужные теги пользователю.
|
||||
3. В настройках ассистента выбирает, какие RAG-таблицы использовать для поиска по тегам.
|
||||
4. ИИ-ассистент при ответе использует только релевантные RAG-таблицы и теги.
|
||||
|
||||
### 5. Пример структуры таблиц для RAG и тегов
|
||||
- `users` — пользователи
|
||||
- `messages` — сообщения
|
||||
- `tags` — справочник тегов
|
||||
- `user_tags` — связь пользователей и тегов (user_id, tag_id)
|
||||
- `rag_tables` — таблицы знаний (например, FAQ, инструкции)
|
||||
- `rag_entries` — записи в таблицах знаний (content, rag_table_id, ...)
|
||||
- `rag_entry_tags` — связь записей знаний и тегов (rag_entry_id, tag_id)
|
||||
|
||||
---
|
||||
|
||||
## План внедрения RAG-ассистента в CRM
|
||||
|
||||
1. **Создать RAG-таблицы для ИИ-ассистента**
|
||||
- Таблицы для хранения знаний о компании, продуктах, услугах (например, `rag_tables`, `rag_entries`).
|
||||
- Возможность добавлять, редактировать, удалять записи через UI.
|
||||
- Каждая запись может быть связана с тегами (например, категория продукта, язык, сегмент клиента).
|
||||
|
||||
2. **Создать таблицы с тегами для пользователей**
|
||||
- Таблица тегов (`tags`).
|
||||
- Связующая таблица `user_tags` (user_id, tag_id).
|
||||
- UI для управления тегами и их привязкой к пользователям.
|
||||
|
||||
3. **Отредактировать страницу настройки ИИ-ассистента**
|
||||
- Добавить выбор, какие RAG-таблицы использовать для поиска.
|
||||
- Отображать список тегов, связанных с выбранными таблицами.
|
||||
- Возможность быстро подключать/отключать таблицы и теги.
|
||||
|
||||
4. **Добавить в раздел "Контакты" фильтры (отдельные компоненты)**
|
||||
- Фильтр по новым пользователям.
|
||||
- Фильтр по новым входящим сообщениям.
|
||||
- Фильтр по тегам (мультиселект).
|
||||
- Каждый фильтр реализовать отдельным Vue-компонентом для переиспользования.
|
||||
|
||||
5. **В "Детали контакта" добавить инлайн-кнопки**
|
||||
- Кнопки:
|
||||
- Сгенерировать (ответ с помощью ИИ)
|
||||
- Редактировать (отредактировать сгенерированный ответ)
|
||||
- Отправить (отправить ответ пользователю)
|
||||
- Добавить в RAG-таблицу (сделать сообщение или ответ частью базы знаний)
|
||||
- Кнопки должны быть доступны для каждого сообщения в истории.
|
||||
|
||||
---
|
||||
|
||||
**Этот документ будет дополняться по мере реализации каждого этапа.**
|
||||
406
docs/SOFT_DESCRIPTION.md
Normal file
406
docs/SOFT_DESCRIPTION.md
Normal file
@@ -0,0 +1,406 @@
|
||||
# DApp for Business
|
||||
|
||||
## Краткое описание
|
||||
**DApp for Business** — это современное веб3-приложение, позволяющее предпринимателям использовать цифровое юридическое лицо для обслуживания клиентов, приема безналичных платежей, безопасного управления активами и прозрачного учета с помощью смарт-контрактов и искусственного интеллекта.
|
||||
|
||||
---
|
||||
|
||||
## Основные возможности
|
||||
- Создание и управление цифровым юридическим лицом на блокчейне
|
||||
- Прием безналичных платежей (криптовалюта, стейблкоины)
|
||||
- Безопасное хранение и управление бизнес-активами через смарт-контракты
|
||||
- Прозрачный учет операций и автоматизация отчетности
|
||||
- Интеграция с ИИ для анализа данных и автоматизации бизнес-процессов
|
||||
- Управление клиентской базой и сервисами через децентрализованное приложение
|
||||
|
||||
---
|
||||
|
||||
## Целевая аудитория
|
||||
- Индивидуальные предприниматели
|
||||
- Малый и средний бизнес
|
||||
- Стартапы, работающие с цифровыми активами
|
||||
- Фрилансеры, желающие автоматизировать бизнес-процессы
|
||||
|
||||
---
|
||||
|
||||
## Преимущества
|
||||
- Полная прозрачность и доверие благодаря блокчейну
|
||||
- Автоматизация рутинных задач с помощью ИИ
|
||||
- Безопасное управление активами без посредников
|
||||
- Гибкая интеграция с внешними сервисами и кошельками
|
||||
- Масштабируемость и независимость от традиционных банковских систем
|
||||
|
||||
---
|
||||
|
||||
## Технические требования
|
||||
- Операционная система: Linux, macOS, Windows (рекомендуется WSL2 для Windows)
|
||||
- Docker
|
||||
- Node.js (v16+)
|
||||
- Yarn
|
||||
- Браузер с поддержкой Web3 (например, MetaMask)
|
||||
|
||||
---
|
||||
|
||||
## Установка и запуск
|
||||
|
||||
1. Клонируйте репозиторий:
|
||||
```bash
|
||||
git clone https://github.com/your-org/dapp-for-business.git
|
||||
cd dapp-for-business
|
||||
```
|
||||
2. Установите зависимости:
|
||||
```bash
|
||||
yarn install
|
||||
```
|
||||
3. Запустите приложение в Docker:
|
||||
```bash
|
||||
docker-compose up --build
|
||||
```
|
||||
4. Откройте приложение в браузере по адресу: [http://localhost:3000](http://localhost:3000)
|
||||
|
||||
---
|
||||
|
||||
## Быстрый старт
|
||||
|
||||
1. Зарегистрируйте цифровое юридическое лицо через интерфейс приложения.
|
||||
2. Подключите криптокошелек (MetaMask или другой Web3-кошелек).
|
||||
3. Настройте параметры бизнеса и добавьте клиентов.
|
||||
4. Начните принимать платежи и управлять активами через смарт-контракты.
|
||||
|
||||
---
|
||||
|
||||
## Структура проекта
|
||||
|
||||
- `frontend/` — клиентская часть на Vue.js (исходный код, конфиги, сборка, nginx)
|
||||
- `backend/` — серверная логика, API, работа с БД, интеграция со смарт-контрактами
|
||||
- `vector-search/` — сервис поиска и работы с векторными данными (Python, FastAPI)
|
||||
- `webssh-agent/` — сервис для работы с SSH-агентом через веб-интерфейс (Node.js)
|
||||
- `scripts/` — bash-скрипты для автоматизации (миграции, обновления DNS и др.)
|
||||
- `md/` — дополнительная документация и технические описания
|
||||
- `docs/` — документация и примеры
|
||||
- `docker-compose.yml`, `Dockerfile` — конфигурация контейнеризации и сборки
|
||||
- `setup.sh`, `clean-logs.sh` — вспомогательные скрипты для установки и обслуживания
|
||||
|
||||
---
|
||||
|
||||
## Часто задаваемые вопросы (FAQ)
|
||||
|
||||
- **Как подключить кошелек?**
|
||||
Используйте MetaMask или любой другой Web3-кошелек, следуя инструкции в интерфейсе приложения.
|
||||
|
||||
- **Какие криптовалюты поддерживаются?**
|
||||
Поддерживаются основные токены стандарта ERC-20 и стейблкоины.
|
||||
|
||||
- **Безопасно ли хранить активы в приложении?**
|
||||
Все операции выполняются через проверенные смарт-контракты, код которых открыт и доступен для аудита.
|
||||
|
||||
---
|
||||
|
||||
## Особенности развертывания и автономной работы
|
||||
|
||||
- Программное обеспечение с ИИ может работать полностью автономно на локальном устройстве без доступа к интернету после установки.
|
||||
- С локального устройства возможно открыть доступ к сервису для интернет-пользователей (например, через проброс портов или настройку прокси).
|
||||
- Приложение может быть установлено и сразу в облачный сервис (VPS, облачные платформы и т.д.) для круглосуточного доступа из любой точки мира.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Управление настройками и доступом
|
||||
|
||||
- Управление всеми настройками приложения осуществляется через удобный веб-интерфейс.
|
||||
- Доступ к настройкам получает только пользователь, чей криптокошелек содержит специальный админ-токен управления смарт-контрактом.
|
||||
- После первого входа в приложение администратор может изменить стандартный админ-токен, создав собственный токен через специальную форму для деплоя смарт-контракта прямо в интерфейсе приложения.
|
||||
- Таким образом, ваш кошелек — это ваш смарт-контракт, ваши токены, ваш управляемый доступ и ваши активы: только вы контролируете все ключевые параметры и права.
|
||||
- Для получения бесплатных обновлений приложения в течение 5 лет администратору необходимо отправить первичный админ-токен на собственный смарт-контракт, созданный в приложении (операция выполняется через интерфейс).
|
||||
|
||||
> **Примечание:** Все смарт-контракты приложения построены на базе проверенных и безопасных библиотек OpenZeppelin.
|
||||
|
||||
---
|
||||
|
||||
## Инструкция по заполнению формы «Блокчейн-настройки»
|
||||
|
||||
1. **Создание нового DLE (Digital Legal Entity)**
|
||||
- **Имя DLE**: Введите уникальное название вашей цифровой организации (например, My DLE).
|
||||
- **Символ токена управления (GT)**: Укажите короткое обозначение токена (3-5 латинских символов, например, MDGT).
|
||||
|
||||
2. **Выбор кода деятельности (ISIC)**
|
||||
- Последовательно выберите секцию, раздел, группу и класс деятельности из выпадающих списков.
|
||||
- После выбора нужного кода нажмите «Добавить код деятельности». Можно добавить несколько кодов.
|
||||
|
||||
3. **Партнёры**
|
||||
- Для каждого партнёра укажите:
|
||||
- **Адрес партнёра** (Ethereum-адрес, например, 0x...).
|
||||
- **Сумму GT для партнёра** (количество токенов управления).
|
||||
- Для добавления нового партнёра используйте кнопку «Добавить партнёра».
|
||||
- Для удаления — «Удалить партнёра».
|
||||
|
||||
4. **RPC-конфигурации**
|
||||
- В разделе «Добавить новую RPC конфигурацию» выберите сеть из списка или укажите пользовательский ID и Chain ID.
|
||||
- Введите RPC URL (например, https://...).
|
||||
- При необходимости воспользуйтесь предложенным URL.
|
||||
- Нажмите «Добавить RPC» для сохранения конфигурации.
|
||||
|
||||
5. **Выбор сети для деплоя**
|
||||
- В выпадающем списке выберите блокчейн-сеть, в которую будет развёрнут смарт-контракт вашей организации.
|
||||
|
||||
6. **Приватный ключ для деплоя**
|
||||
- Введите приватный ключ деплоера (будет использоваться только для развертывания смарт-контракта).
|
||||
|
||||
7. **Пользовательские настройки газа (опционально)**
|
||||
- Если требуется, включите опцию «Использовать пользовательские настройки газа» и укажите лимит газа, максимальную и приоритетную комиссию.
|
||||
|
||||
8. **Сохранение и деплой**
|
||||
- После заполнения всех полей проверьте введённые данные.
|
||||
- Нажмите кнопку деплоя (или «Сохранить»), чтобы развернуть смарт-контракт и завершить настройку.
|
||||
|
||||
**Важно:**
|
||||
- Доступ к настройкам имеют только пользователи с админ-токеном в кошельке.
|
||||
- После деплоя вы сможете управлять организацией через смарт-контракт и веб-интерфейс.
|
||||
|
||||
---
|
||||
|
||||
## Управление DLE и модульными смарт-контрактами
|
||||
|
||||
После создания смарт-контракта с админ-токеном управления в разделе CRM приложения появляется интерфейс для управления функциями смарт-контракта и добавления модульных смарт-контрактов.
|
||||
|
||||
### Как управлять DLE через интерфейс
|
||||
|
||||
1. **Переход к управлению DLE**
|
||||
- В разделе CRM нажмите на блок "Управление DLE" и кнопку "Подробнее" или перейдите по адресу `/dle-management`.
|
||||
|
||||
2. **Выбор DLE**
|
||||
- В списке отобразятся все созданные вами DLE. Выберите нужную организацию для управления.
|
||||
|
||||
3. **Основная информация**
|
||||
- Вкладка "Основная информация" содержит сведения о названии, символе токена, местонахождении, кодах деятельности, дате создания и адресах смарт-контрактов (токен, таймлок, Governor). Можно скопировать адреса или открыть их в обозревателе блокчейна.
|
||||
|
||||
4. **Предложения**
|
||||
- На вкладке "Предложения" можно создавать новые предложения для управления DLE (например, изменение параметров, добавление участников и др.).
|
||||
- Для создания предложения заполните заголовок и описание, затем отправьте на голосование.
|
||||
- Участвуйте в голосовании по предложениям ("За" или "Против"). Статус предложения обновляется автоматически.
|
||||
|
||||
5. **Управление (Governance)**
|
||||
- Вкладка "Управление" позволяет просматривать и изменять параметры управления: порог предложения, кворум, задержку и период голосования.
|
||||
|
||||
6. **Модули**
|
||||
- Вкладка "Модули" предназначена для подключения дополнительных модульных смарт-контрактов (например, токенизация активов, мультиподпись, дивиденды, стейкинг, приём платежей и др.).
|
||||
- Для установки модуля нажмите "Установить" напротив нужного модуля. Для удаления — "Удалить".
|
||||
- Для модуля "Прием платежей" выберите токены, которые будут приниматься, и сохраните настройки.
|
||||
|
||||
7. **Удаление DLE**
|
||||
- При необходимости можно удалить DLE (доступно только администратору). Будьте внимательны: действие необратимо.
|
||||
|
||||
**Важно:**
|
||||
- Все действия с DLE и модулями доступны только пользователям с админ-токеном в кошельке.
|
||||
- Управление DLE реализовано через смарт-контракты на базе OpenZeppelin, что обеспечивает безопасность и прозрачность операций.
|
||||
|
||||
---
|
||||
|
||||
## Настройка и использование ИИ-моделей
|
||||
|
||||
После установки приложения администратор может:
|
||||
- Добавить ключи своих ИИ-моделей по подписке (например, OpenAI, Gemini и др.) в настройках приложения.
|
||||
- Скачать одну из доступных ИИ-моделей и развернуть её локально на своём устройстве для автоматизации обслуживания клиентов бизнеса без рисков утечки конфиденциальных данных.
|
||||
|
||||
Для дообучения добавленных моделей деталям вашего бизнеса предусмотрена возможность:
|
||||
- Создавать собственные таблицы в установленной базе данных через веб-интерфейс приложения.
|
||||
- Заполнять эти таблицы данными, которые ИИ-ассистент сможет использовать для генерации персонализированных сообщений клиентам бизнеса как в чате приложения, так и в других каналах коммуникации (например, email, Telegram и др.).
|
||||
|
||||
Это позволяет максимально адаптировать ИИ-ассистента под специфику вашего бизнеса и обеспечить безопасность корпоративных данных.
|
||||
|
||||
---
|
||||
|
||||
## Интерактивный обмен контентом, публикация и интеграция с ИИ
|
||||
|
||||
- Пользователи могут создавать и публиковать веб-страницы (о компании, продуктах, статьи) с помощью удобной формы.
|
||||
- Каждая страница получает уникальный URL, оптимизирована для SEO и доступна для поиска в интернете и ИИ-системах.
|
||||
- После публикации страницы можно делиться ими в корпоративном чате: появляется интерактивная карточка с кнопкой для просмотра содержимого, а также возможностью задать вопрос по содержимому страницы.
|
||||
- Страницы автоматически интегрируются с RAG: разбиваются на смысловые блоки, векторизуются и используются ИИ-ассистентом для поиска и генерации ответов.
|
||||
- При публикации можно выбрать интеграцию с RAG и добавить Q&A по теме страницы для последующего поиска.
|
||||
- Возможна публикация страниц в соцсетях и блогах (Medium, LinkedIn, Instagram, Telegram и др.) через API с выбором платформ.
|
||||
- Все компоненты реализованы с учётом безопасности и приватности данных, поддерживается удаление и редактирование страниц.
|
||||
- Используются современные RAG-фреймворки (LlamaIndex, LangChain) и актуальные модели для векторизации (OpenAI, Sentence Transformers и др.).
|
||||
- Страницы открыты для индексации поисковыми системами и ИИ-ботами, что обеспечивает максимальную видимость и доступность информации.
|
||||
|
||||
---
|
||||
|
||||
## Управление контактами в CRM
|
||||
|
||||
В разделе "Контакты" CRM администраторы приложения могут:
|
||||
- Отслеживать и управлять всеми выбранными контактами через удобную таблицу.
|
||||
- Использовать фильтры быстрого поиска по имени, email, Telegram, кошельку, типу контакта, дате и тегам.
|
||||
- Применять кнопки быстрых действий для массовой рассылки сообщений, импорта контактов, удаления выбранных записей.
|
||||
- Просматривать подробную информацию о каждом контакте, редактировать имя, email, Telegram, кошелек, язык общения.
|
||||
- Добавлять и удалять теги для контакта, а также создавать новые теги прямо из интерфейса.
|
||||
- Блокировать и разблокировать пользователей, полностью удалять контакт.
|
||||
- Вести чат с каждым контактом прямо в интерфейсе приложения, использовать ИИ-ассистента для генерации ответов.
|
||||
- Все изменения и действия с контактами доступны только администраторам.
|
||||
|
||||
Это позволяет эффективно управлять клиентской базой, быстро находить нужные контакты и автоматизировать коммуникации с помощью встроенных инструментов.
|
||||
|
||||
|
||||
## Контакты и поддержка
|
||||
|
||||
- Email: info@hb3-accelerator.com
|
||||
- Telegram: @yourproject_support
|
||||
- Сайт: [https://hb3-accelerator.com](https://hb3-accelerator.com)
|
||||
|
||||
---
|
||||
|
||||
## Лицензия
|
||||
|
||||
MIT License
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
офер:
|
||||
|
||||
Привет! Я **Алекс** из венчурного фонда **HB3 Accelerator**.
|
||||
|
||||
Если ваша компания:
|
||||
* использует **CRM** для обслуживания клиентов и имеет штат **продавцов и бухгалтеров**;
|
||||
* нуждается в **безналичных платежах без лимитов, ограничений и с низкими комиссиями**;
|
||||
* ценит **прозрачный учёт и свободное управление активами**,
|
||||
|
||||
то я буду рад предложить вам **программное обеспечение с ИИ и смарт-контрактами**.
|
||||
|
||||
|
||||
примеры вопросов оо клиентов:
|
||||
|
||||
1. Как ваш софт интегрируется с уже существующими CRM-системами? Например, у нас сейчас используется 1С и Bitrix24.
|
||||
2. Какие конкретно задачи автоматизирует ваш ИИ? Это только аналитика или он может, например, помогать продавцам в реальном времени?
|
||||
3. Как обеспечивается безопасность и прозрачность работы со смарт-контрактами? Кто их разрабатывает и кто несёт ответственность в случае ошибки?
|
||||
4. Какой у вас опыт внедрения подобных решений в СНГ? Есть ли кейсы в моей отрасли (например, розничная торговля)?
|
||||
5. Какой порядок внедрения: сколько времени занимает интеграция, кто обучает персонал?
|
||||
6. Какие комиссии по безналичным платежам и с какими банками/платёжными системами вы работаете?
|
||||
7. Какой уровень поддержки вы предоставляете после внедрения?
|
||||
|
||||
|
||||
ответ:
|
||||
|
||||
### Наше комплексное решение для вашего бизнеса
|
||||
|
||||
Наше программное обеспечение включает **встроенную CRM-систему**, куда вы можете легко загрузить необходимые контакты из ваших текущих CRM для **омниканального обслуживания**.
|
||||
|
||||
**ИИ-ассистент**, интегрированный в наш софт, способен обучаться работе с сегментами ваших клиентов и поставщиков. Обучение происходит на основе правил, которые вы устанавливаете и загружаете в **векторную базу данных**. Эта база надёжно хранит ваши конфиденциальные данные либо на **локальном**, либо на **облачном сервере**.
|
||||
|
||||
Мы — **молодой стартап**, представляющий свой первый технологический продукт. Внедрение нашего решения занимает от **нескольких часов до одного года**, в зависимости от сложности интеграции.
|
||||
|
||||
---
|
||||
|
||||
### Условия сотрудничества
|
||||
|
||||
Мы предоставляем **5 лет обновлений** для вашего программного обеспечения.
|
||||
|
||||
Кроме того, если **в течение первого года** мы не сможем настроить софт под индивидуальные потребности вашего бизнеса, вы можете получить **возврат 70% от стоимости**.
|
||||
|
||||
|
||||
вопросы:
|
||||
|
||||
Какой у вас опыт работы с интеграцией в 1С и Bitrix24? Есть ли готовые модули или потребуется доработка под нас?
|
||||
Как реализована миграция данных из старых CRM? Кто этим занимается — ваша команда или наши специалисты?
|
||||
Какой стек технологий вы используете для ИИ и смарт-контрактов? На каких блокчейн-платформах строится ваша система?
|
||||
Какой SLA по поддержке и реагированию на инциденты? Есть ли круглосуточная поддержка?
|
||||
Как лицензируется продукт: это подписка, разовая покупка или гибридная модель?
|
||||
Какой порядок оплаты: аванс, поэтапно, после внедрения?
|
||||
Как вы обеспечиваете соответствие требованиям законодательства РФ/СНГ по хранению и обработке персональных данных?
|
||||
Есть ли демо-доступ или пилотный проект, чтобы мы могли протестировать систему на реальных данных?
|
||||
|
||||
ответы :
|
||||
|
||||
---
|
||||
|
||||
### Особенности нашего решения
|
||||
|
||||
Мы не занимаемся интеграциями с **устаревшими CRM-системами**. Однако ваши сотрудники смогут легко выполнить **миграцию данных** при поддержке нашего **ИИ-ассистента**.
|
||||
|
||||
Наш **ИИ-ассистент** обеспечивает **круглосуточную поддержку**. Инциденты с нашей стороны **исключены**, поскольку приобретаемое вами программное обеспечение является **полностью локальным решением**.
|
||||
|
||||
---
|
||||
|
||||
### Безопасность и конфиденциальность данных
|
||||
|
||||
Хранение персональных данных **соответствует требованиям законодательства**. Все данные **зашифрованы** и хранятся **на вашей территории**.
|
||||
|
||||
---
|
||||
|
||||
### Технологический стек
|
||||
|
||||
Вот основные технологии, которые мы используем в нашем **backend-решении**:
|
||||
|
||||
* **Искусственный интеллект и машинное обучение:** `@anthropic-ai/sdk`, `@google/genai`, `@langchain/community`, `@langchain/core`, `@langchain/ollama`, `langchain`, `openai`
|
||||
* **Блокчейн и смарт-контракты:** `@openzeppelin/contracts`, `ethers`, `siwe`, `viem`
|
||||
* **Веб-сервер и API:** `express`, `cors`, `helmet`, `express-rate-limit`
|
||||
* **Базы данных:** `pg`, `connect-pg-simple`
|
||||
* **Безопасность:** `csurf`, `express-session`, `session-file-store`, `cookie`
|
||||
* **Обработка электронной почты:** `imap`, `mailparser`, `nodemailer`
|
||||
* **Мессенджеры:** `node-telegram-bot-api`, `telegraf`, `ws`
|
||||
* **Утилиты и вспомогательные библиотеки:** `archiver`, `axios`, `cron`, `dotenv`, `multer`, `node-cron`, `semver`, `winston`
|
||||
* **Инструменты разработки:** `nodemon`, `eslint`, `prettier`, `hardhat`, `mocha`, `chai`, `typescript`
|
||||
|
||||
|
||||
вопросы:
|
||||
|
||||
1. Как реализована поддержка и обновления: если решение полностью локальное, как будут устанавливаться апдейты и исправления? Это делается через удалённый доступ, или вы предоставляете инструкции для нашей IT-команды?
|
||||
2. Какой механизм резервного копирования и восстановления данных предусмотрен в вашем решении?
|
||||
3. Если потребуется интеграция с внешними сервисами (например, платёжные шлюзы, государственные системы учёта), возможно ли это реализовать на вашей платформе?
|
||||
4. Какой минимальный и рекомендуемый состав IT-специалистов нужен для поддержки вашего ПО на стороне клиента?
|
||||
5. Какой порядок лицензирования используемых вами open-source библиотек и SDK? Нет ли рисков для конечного пользователя?
|
||||
6. Предусмотрена ли возможность кастомизации интерфейса и бизнес-логики под наши процессы?
|
||||
7. Какой минимальный объём внедрения (по стоимости или количеству пользователей) вы рассматриваете?
|
||||
|
||||
|
||||
ответ: Конечно! Вот ответы на вопросы предпринимателя, составленные на основе документации к продукту DApp for Business:
|
||||
|
||||
---
|
||||
|
||||
### 1. Как реализована поддержка и обновления: если решение полностью локальное, как будут устанавливаться апдейты и исправления? Это делается через удалённый доступ, или вы предоставляете инструкции для нашей IT-команды?
|
||||
|
||||
**Ответ:**
|
||||
Обновления предоставляются бесплатно в течение 5 лет. Программное обеспечение устанавливается и работает полностью локально, без необходимости постоянного интернет-доступа. Для установки обновлений вы можете использовать предоставленные bash-скрипты (`setup.sh`, `clean-logs.sh`) и инструкции из документации. При необходимости можно открыть доступ к сервису для интернет-пользователей (например, через проброс портов или прокси), но это не обязательно. Все инструкции по обновлению и обслуживанию доступны вашей IT-команде, удалённый доступ не требуется.
|
||||
|
||||
---
|
||||
|
||||
### 2. Какой механизм резервного копирования и восстановления данных предусмотрен в вашем решении?
|
||||
|
||||
**Ответ:**
|
||||
В документации прямо не описан отдельный модуль резервного копирования, однако, поскольку все данные хранятся локально (или на вашем облачном сервере), вы полностью контролируете процесс бэкапа. Используются стандартные базы данных (`pg` — PostgreSQL), для которых легко настраиваются регулярные резервные копии с помощью штатных инструментов PostgreSQL или через Docker-скрипты. Также можно использовать bash-скрипты из папки `scripts/` для автоматизации резервного копирования и восстановления.
|
||||
|
||||
---
|
||||
|
||||
### 3. Если потребуется интеграция с внешними сервисами (например, платёжные шлюзы, государственные системы учёта), возможно ли это реализовать на вашей платформе?
|
||||
|
||||
**Ответ:**
|
||||
Да, гибкая интеграция с внешними сервисами и кошельками поддерживается. Приложение масштабируемо и не зависит от традиционных банковских систем. В разделе "Модули" можно подключать дополнительные смарт-контракты, в том числе для приёма платежей, токенизации активов и других задач. Также реализована возможность публикации и интеграции с внешними платформами через API (например, соцсети, мессенджеры, внешние сервисы учёта).
|
||||
|
||||
---
|
||||
|
||||
### 4. Какой минимальный и рекомендуемый состав IT-специалистов нужен для поддержки вашего ПО на стороне клиента?
|
||||
|
||||
**Ответ:**
|
||||
Для базовой эксплуатации достаточно одного системного администратора или DevOps-специалиста, знакомого с Docker, Linux и базовыми инструментами Node.js/PostgreSQL. Вся установка и обслуживание автоматизированы скриптами и не требуют глубоких знаний в программировании. Для расширенной кастомизации или интеграции с внешними сервисами может потребоваться разработчик с опытом работы с Node.js, смарт-контрактами (Solidity) и API.
|
||||
|
||||
---
|
||||
|
||||
### 5. Какой порядок лицензирования используемых вами open-source библиотек и SDK? Нет ли рисков для конечного пользователя?
|
||||
|
||||
**Ответ:**
|
||||
Программное обеспечение распространяется по лицензии MIT, что гарантирует отсутствие ограничений для конечного пользователя. Все используемые библиотеки (например, OpenZeppelin, LangChain, Express, PostgreSQL и др.) также имеют открытые лицензии (MIT, Apache 2.0 и аналогичные), что исключает юридические риски для вашего бизнеса.
|
||||
|
||||
---
|
||||
|
||||
### 6. Предусмотрена ли возможность кастомизации интерфейса и бизнес-логики под наши процессы?
|
||||
|
||||
**Ответ:**
|
||||
Да, архитектура приложения модульная и предусматривает возможность кастомизации. Вы можете добавлять собственные таблицы в базу данных через веб-интерфейс, подключать новые модули смарт-контрактов, настраивать параметры бизнеса, интегрировать свои ИИ-модели и дообучать их на ваших данных. Интерфейс реализован на Vue.js и может быть доработан под ваши задачи.
|
||||
|
||||
---
|
||||
|
||||
### 7. Какой минимальный объём внедрения (по стоимости или количеству пользователей) вы рассматриваете?
|
||||
|
||||
**Ответ:**
|
||||
В документации не указаны ограничения по минимальному объёму внедрения или количеству пользователей. Продукт ориентирован как на индивидуальных предпринимателей, так и на малый и средний бизнес, стартапы и фрилансеров. Вы можете начать с одного пользователя и масштабировать решение по мере роста бизнеса.
|
||||
|
||||
111
docs/WEB_SSH_TUNNEL_PLAN.md
Normal file
111
docs/WEB_SSH_TUNNEL_PLAN.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Автоматизация публикации локального приложения через SSH-туннель и NGINX
|
||||
|
||||
## Описание задачи
|
||||
|
||||
Необходимо реализовать функционал, позволяющий пользователю локального веб-приложения в один клик опубликовать своё приложение в интернете по собственному домену. Для этого используется внешний сервер (VPS) с белым IP и доменом, на котором автоматически настраиваются:
|
||||
- Установка и настройка NGINX для проксирования домена на SSH-туннель
|
||||
- Выпуск и установка SSL-сертификата (Let's Encrypt)
|
||||
- SSH reverse-туннель с сервера на локальное приложение пользователя
|
||||
- (Опционально) Автоматическая установка NGINX и certbot на сервере по SSH силами локального агента
|
||||
|
||||
Пользователь заполняет форму с необходимыми данными, после чего система автоматически выполняет все шаги по настройке инфраструктуры.
|
||||
|
||||
---
|
||||
|
||||
## Архитектура решения
|
||||
|
||||
1. **Локальное приложение** работает в Docker-контейнере на ПК пользователя (порт 5173 проброшен наружу).
|
||||
2. **Локальный агент** (Node.js-приложение) устанавливается на ПК пользователя и позволяет фронтенду запускать команды (например, поднять SSH-туннель, а также настраивать NGINX/SSL на сервере по SSH) в один клик.
|
||||
3. **Агент по SSH подключается к серверу (VPS)** и:
|
||||
- Устанавливает NGINX и certbot (если не установлены)
|
||||
- Создаёт или обновляет конфиг NGINX для указанного домена (проксирует на порт 9000)
|
||||
- Перезапускает NGINX
|
||||
- Выпускает SSL-сертификат через certbot
|
||||
- Проверяет доступность домена по HTTPS
|
||||
- Запускает SSH reverse-туннель (9000:localhost:5173)
|
||||
4. **NGINX** на сервере проксирует домен на порт туннеля (9000).
|
||||
|
||||
---
|
||||
|
||||
## Необходимые данные для формы
|
||||
|
||||
- Домен (например, myapp.example.com)
|
||||
- Host/IP сервера
|
||||
- Пользователь SSH
|
||||
- SSH-ключ (или пароль)
|
||||
- E-mail для SSL (Let's Encrypt)
|
||||
|
||||
**Поля "Локальный порт приложения", "Порт на сервере для туннеля" и "Порт SSH" скрыты и всегда используются значения по умолчанию:**
|
||||
- Локальный порт: 5173
|
||||
- Порт на сервере: 9000
|
||||
- Порт SSH: 22
|
||||
|
||||
---
|
||||
|
||||
## UX-поток с локальным агентом (финальный порядок)
|
||||
|
||||
1. Пользователь заходит в локальное веб-приложение и заполняет форму публикации (домен, SSH и т.д.).
|
||||
2. Нажимает кнопку "Опубликовать".
|
||||
3. Агент автоматически скачивается, устанавливается и запускается (без дополнительных действий пользователя).
|
||||
4. После запуска агента фронтенд отправляет параметры публикации на локальный агент (порты и порт SSH подставляются автоматически).
|
||||
5. Агент по SSH подключается к серверу и:
|
||||
- Устанавливает NGINX и certbot (если не установлены)
|
||||
- Создаёт или обновляет конфиг NGINX для домена
|
||||
- Перезапускает NGINX
|
||||
- Выпускает SSL-сертификат через certbot
|
||||
- Запускает SSH reverse-туннель (9000:localhost:5173, порт SSH всегда 22)
|
||||
6. После успешного запуска туннеля приложение становится доступно по домену из интернета.
|
||||
|
||||
---
|
||||
|
||||
## План выполнения
|
||||
|
||||
### 1. Фронтенд
|
||||
- [ ] Добавить на страницу настроек интерфейса блок "WEB SSH" с кнопкой "Подробнее"
|
||||
- [ ] Создать отдельную страницу
|
||||
- [ ] Реализовать отправку формы на локальный агент (поля с портами и портом SSH скрыты, используются значения по умолчанию)
|
||||
- [ ] После успешной настройки — отобразить пользователю статус публикации с ссылкой на домен
|
||||
|
||||
### 2. Локальный агент
|
||||
- [ ] Реализовать Node.js-приложение (Web SSH Agent), слушающее локальный порт
|
||||
- [ ] API: запуск/остановка SSH-туннеля, статус, логирование
|
||||
- [ ] Автоматическая установка и настройка NGINX, выпуск SSL-сертификата на сервере по SSH
|
||||
- [ ] Безопасность: принимать команды только с localhost, авторизация по токену
|
||||
- [ ] Инструкция по установке для пользователя (Windows, Mac, Linux)
|
||||
- [ ] (Опционально) Автообновление агента
|
||||
|
||||
### 3. Бэкенд (опционально)
|
||||
- [ ] Реализовать API для логирования, аудита, хранения истории публикаций (если требуется)
|
||||
- [ ] Возвращать статус выполнения и сообщения об ошибках (если используется)
|
||||
|
||||
### 4. Инфраструктура/DevOps
|
||||
- [ ] Проверить, что на сервере открыт порт 9000 для туннеля
|
||||
- [ ] Проверить, что домен указывает на сервер
|
||||
- [ ] Проверить, что на сервере установлен NGINX и certbot
|
||||
- [ ] (Опционально) Добавить systemd unit для автозапуска туннеля
|
||||
|
||||
---
|
||||
|
||||
## Важные замечания
|
||||
- Для полной автоматизации публикации в один клик требуется локальный агент, который запускает команды на ПК пользователя и может настраивать сервер по SSH.
|
||||
- В браузере без агента можно только сгенерировать команду для ручного запуска SSH-туннеля.
|
||||
- Все действия на сервере должны выполняться только для авторизованных пользователей (лучше — только для админов)
|
||||
- Необходимо реализовать валидацию всех полей формы
|
||||
- **Используется именно проброшенный наружу порт из Docker (5173)**
|
||||
- **Порт SSH всегда 1024 (по умолчанию), пользователь не видит это поле**
|
||||
|
||||
---
|
||||
|
||||
приложение остаётся локально — туннель обязателен
|
||||
|
||||
---
|
||||
|
||||
## Пример команды для SSH-туннеля
|
||||
|
||||
```bash
|
||||
ssh -i /path/to/key -p 22 -R 9000:localhost:5173 user@ваш-сервер
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## С локальным агентом публикация действительно становится "в один клик"!
|
||||
199
docs/interactive-content-sharing.md
Normal file
199
docs/interactive-content-sharing.md
Normal file
@@ -0,0 +1,199 @@
|
||||
# Интерактивный обмен веб-страницами с ИИ-ассистентом в корпоративном чате
|
||||
|
||||
## Описание задачи
|
||||
|
||||
Реализовать функционал, позволяющий пользователям создавать веб-страницы с данными о компании, продуктах или статьями (блог), делиться ими в корпоративном чате в виде интерактивных сообщений с кнопками, а также обеспечивать автоматическое добавление этих страниц в базу знаний (RAG) для поиска и генерации ответов ИИ-ассистентом. Страницы должны быть доступны для поиска в интернете по ключевым словам.
|
||||
|
||||
---
|
||||
|
||||
## Основные требования
|
||||
|
||||
1. **Создание веб-страниц**
|
||||
- Форма на странице `/content` для ввода информации (название, описание, текст, теги, изображения и т.д.).
|
||||
- Возможность предпросмотра и редактирования страницы до публикации.
|
||||
- Кнопка "Поделиться", после нажатия которой страница сохраняется и становится доступной для дальнейших действий.
|
||||
|
||||
2. **Публикация и доступность**
|
||||
- После публикации страница доступна по уникальному URL (например, `/content/page/123` или `/content/page/название`).
|
||||
- Страница оптимизирована для SEO (мета-теги, ЧПУ-адреса, sitemap.xml).
|
||||
- При необходимости — настройка индексации для поисковых систем (robots.txt).
|
||||
- **Оптимизация для ИИ-поиска**: страницы должны быть структурированы и открыты для индексации поисковыми ИИ (Perplexity, GPT, Gemini и др.). Рекомендуется:
|
||||
- Использовать семантическую разметку (schema.org, JSON-LD)
|
||||
- Добавлять структурированные данные (FAQ, Article, Product)
|
||||
- Открывать страницы для crawler-ботов ИИ (не блокировать их в robots.txt)
|
||||
- Обеспечивать чистый, легко читаемый HTML-код
|
||||
- Добавлять релевантные ключевые слова и теги
|
||||
|
||||
3. **Интеграция с корпоративным чатом**
|
||||
- После публикации пользователь может отправить страницу в чат с помощью кнопки "Поделиться в чат".
|
||||
- В чате появляется интерактивное сообщение (карточка) с краткой информацией о странице и кнопкой (например, "Показать содержимое").
|
||||
- При нажатии на кнопку ассистент отправляет содержимое страницы (или его резюме) в чат.
|
||||
- Возможность задать вопрос по содержимому страницы через чат (ассистент ищет ответ только в этой странице).
|
||||
- При публикации страницы в чатах пользователей (веб, Telegram, email) вместе с ответами на сообщения должно автоматически добавляться интерактивное сообщение с заголовком страницы и кнопкой "Подробнее". При нажатии на кнопку ИИ-ассистент отправляет содержимое веб-страницы в чат.
|
||||
|
||||
4. **Интеграция с RAG (Retrieval-Augmented Generation)**
|
||||
- После публикации страница автоматически разбивается на смысловые блоки (например, по абзацам).
|
||||
- Каждый блок векторизуется (создается embedding) и сохраняется в векторное хранилище (Qdrant, Pinecone и т.д.) с метаданными (id страницы, теги, автор, дата).
|
||||
- Ассистент использует эти данные для поиска и генерации ответов на вопросы пользователей.
|
||||
- В форме создания страницы добавить выпадающий список "Интегрировать с RAG" (Да/Нет). При выборе "Да" ИИ-ассистент анализирует содержимое страницы, автоматически предлагает список возможных вопросов и ответов (Q&A) по теме страницы. Пользователь может отредактировать эти вопросы и ответы, отметить чекбоксами нужные и нажать "Добавить" — выбранные Q&A будут сохранены в базу знаний для последующего поиска и генерации ответов.
|
||||
|
||||
5. **Поиск в интернете**
|
||||
- Страницы доступны для индексации поисковыми системами.
|
||||
- Поиск по ключевым словам приводит к отображению соответствующих страниц.
|
||||
|
||||
---
|
||||
|
||||
## Пользовательские сценарии
|
||||
|
||||
1. **Создание и публикация страницы**
|
||||
- Пользователь заполняет форму на `/content`, нажимает "Поделиться".
|
||||
- Страница сохраняется, появляется уникальный URL.
|
||||
|
||||
2. **Обмен в чате**
|
||||
- Пользователь нажимает "Поделиться в чат".
|
||||
- В чате появляется карточка с кнопкой "Показать содержимое".
|
||||
- Другой пользователь нажимает кнопку — ассистент отправляет содержимое страницы в чат.
|
||||
|
||||
3. **Поиск и ответы ассистента**
|
||||
- Пользователь задаёт вопрос по теме страницы.
|
||||
- Ассистент ищет ответ в RAG по содержимому страницы и формирует релевантный ответ.
|
||||
|
||||
4. **Поиск через интернет**
|
||||
- Внешний пользователь находит страницу через поисковик по ключевым словам.
|
||||
|
||||
---
|
||||
|
||||
## Техническая реализация
|
||||
|
||||
### Frontend
|
||||
- Vue.js, локальные scoped-стили
|
||||
- Форма создания/редактирования страницы
|
||||
- Компонент карточки для чата с интерактивной кнопкой
|
||||
|
||||
### Backend
|
||||
- Node.js/NestJS/Fastify/Express
|
||||
- REST API для создания, публикации, получения страниц
|
||||
- Векторизация и интеграция с векторным хранилищем (Qdrant, Pinecone)
|
||||
- Генерация и отправка сообщений в чат
|
||||
|
||||
### Векторное хранилище (RAG)
|
||||
- Сохранение embedding-блоков с метаданными
|
||||
- Поиск по embedding для генерации ответов ассистентом
|
||||
|
||||
### SEO и индексация
|
||||
- Генерация мета-тегов, sitemap.xml
|
||||
- ЧПУ-адреса страниц
|
||||
- Настройка robots.txt
|
||||
|
||||
---
|
||||
|
||||
## Диаграмма взаимодействия
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Frontend
|
||||
participant Backend
|
||||
participant VectorDB
|
||||
participant Chat
|
||||
participant SearchEngine
|
||||
|
||||
User->>Frontend: Заполняет форму на /content
|
||||
Frontend->>Backend: POST /api/content (данные)
|
||||
Backend->>Backend: Создает страницу, сохраняет в БД
|
||||
Backend->>VectorDB: Векторизация, добавление в RAG
|
||||
Backend->>Frontend: Возвращает ссылку на страницу
|
||||
Frontend->>Chat: Отправляет карточку в чат
|
||||
Chat->>User: Показывает карточку + ответ ассистента
|
||||
SearchEngine->>Backend: Индексирует страницу (если разрешено)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Примечания
|
||||
- Все компоненты должны быть реализованы с учетом безопасности и приватности данных.
|
||||
- Необходимо предусмотреть возможность удаления и редактирования страниц.
|
||||
- Для интеграции с ИИ-ассистентом использовать современные RAG-фреймворки (LlamaIndex, LangChain и т.д.).
|
||||
- Для векторизации использовать актуальные модели (OpenAI, Sentence Transformers и др.).
|
||||
|
||||
---
|
||||
|
||||
## Автоматический выбор и добавление интерактивных сообщений ИИ-ассистентом
|
||||
|
||||
ИИ-ассистент может самостоятельно анализировать контекст диалога и принимать решение о добавлении интерактивных сообщений (карточек) в чат, чтобы повысить релевантность и удобство взаимодействия.
|
||||
|
||||
### Принцип работы
|
||||
|
||||
1. **Анализ контекста диалога**
|
||||
- Ассистент анализирует сообщения пользователя, определяет тему, намерение и ключевые слова.
|
||||
- Выполняет поиск по базе знаний (RAG) для нахождения релевантных страниц или блоков.
|
||||
|
||||
2. **Принятие решения о вставке интерактивного сообщения**
|
||||
- Если найден релевантный контент, ассистент решает, нужно ли добавить карточку с кнопкой (например, "Подробнее").
|
||||
- Решение зависит от:
|
||||
- Тематики и повторяемости вопросов
|
||||
- Новизны или важности контента
|
||||
- Явных триггеров в сообщениях пользователя (например, "покажи инструкцию", "расскажи подробнее" и т.д.)
|
||||
|
||||
3. **Формирование интерактивного сообщения**
|
||||
- Ассистент формирует карточку с заголовком, кратким описанием и кнопкой (например, "Подробнее").
|
||||
- При нажатии на кнопку пользователем ассистент отправляет содержимое страницы или выбранного блока в чат.
|
||||
|
||||
### Пример сценария
|
||||
|
||||
- Пользователь: "Как подключить наш продукт X?"
|
||||
- Ассистент:
|
||||
1. Находит в RAG инструкцию по подключению продукта X.
|
||||
2. Отвечает кратко и автоматически добавляет интерактивную карточку с кнопкой "Показать инструкцию".
|
||||
3. При нажатии на кнопку отправляет подробную инструкцию в чат.
|
||||
|
||||
### Преимущества
|
||||
- Пользователь получает релевантную информацию в нужный момент, не перегружая чат лишними карточками.
|
||||
- Ассистент становится более "умным" и проактивным.
|
||||
- Повышается вовлечённость и удовлетворённость пользователей.
|
||||
|
||||
---
|
||||
|
||||
## Публикация страниц в социальных сетях и блогах через API
|
||||
|
||||
Система может поддерживать публикацию созданных страниц на страницах компании в социальных сетях и блогах (Medium, LinkedIn, Instagram, Paragraph, Telegraph, Telegram и др.) с помощью соответствующих API.
|
||||
|
||||
### Возможности
|
||||
- Публикация статей и постов на платформах: Medium, LinkedIn (страницы компаний), Instagram (бизнес-аккаунты), Paragraph, Telegraph, Telegram (боты/каналы) и др.
|
||||
- Выбор платформ для публикации пользователем (чекбоксы или список).
|
||||
- Формирование контента с учётом особенностей каждой платформы (текст, изображения, разметка).
|
||||
|
||||
### Принцип работы
|
||||
1. Пользователь выбирает опцию "Опубликовать в соцсетях" после создания страницы.
|
||||
2. Открывается окно выбора платформ и авторизации (OAuth2, если требуется).
|
||||
3. Для каждой платформы формируется подходящий формат контента.
|
||||
4. Система отправляет запросы к API выбранных платформ для публикации.
|
||||
5. Пользователь получает уведомление об успешной публикации или ошибке.
|
||||
|
||||
### Ограничения и нюансы
|
||||
- Для некоторых платформ требуется бизнес-аккаунт и прохождение модерации приложения (LinkedIn, Instagram).
|
||||
- Формат и объём контента может отличаться (например, Instagram — только изображение+текст).
|
||||
- Возможны лимиты на частоту публикаций и размер постов.
|
||||
- Некоторые платформы могут задерживать публикацию для модерации.
|
||||
|
||||
### Пример архитектуры
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Frontend
|
||||
participant Backend
|
||||
participant SocialAPI
|
||||
|
||||
User->>Frontend: Нажимает “Опубликовать в соцсетях”
|
||||
Frontend->>Backend: POST /api/publish-to-social (данные, токены)
|
||||
Backend->>SocialAPI: Публикует на выбранных платформах
|
||||
SocialAPI-->>Backend: Ответ (успех/ошибка)
|
||||
Backend-->>Frontend: Сообщение о результате
|
||||
Frontend-->>User: Уведомление
|
||||
```
|
||||
|
||||
### Рекомендации
|
||||
- Для каждой платформы реализовать отдельный модуль интеграции или использовать сторонние сервисы (Zapier, Make).
|
||||
- Предусмотреть очередь публикаций и логи для отслеживания статуса.
|
||||
- Обеспечить безопасное хранение и обновление токенов авторизации.
|
||||
95
docs/rag-assistant-details.md
Normal file
95
docs/rag-assistant-details.md
Normal file
@@ -0,0 +1,95 @@
|
||||
# VC HB3 - Accelerator: Детали задания для ИИ-ассистента
|
||||
|
||||
## 1. Описание проекта
|
||||
VC HB3 - Accelerator — это венчурный фонд и поставщик софта, который с помощью акселерационных программ помогает предпринимателям создавать токенизированные стартапы во всех отраслях. Фонд объединяет предпринимателей из разных юрисдикций, предоставляет инструменты для токенизации, прозрачных инвестиций и управления цифровыми юридическими лицами.
|
||||
|
||||
## 2. Цели и задачи ИИ-ассистента
|
||||
- Помогать клиентам быстро находить ответы на вопросы о продуктах, услугах и условиях фонда.
|
||||
- Предлагать релевантные продукты и услуги на основе сегментации клиентов.
|
||||
- Автоматизировать консультации, обработку типовых запросов и навигацию по возможностям фонда.
|
||||
- Содействовать формированию групп акселератора и информировать о возможностях участия.
|
||||
|
||||
## 3. Сегментация клиентов
|
||||
ИИ-ассистент должен различать следующие основные сегменты клиентов:
|
||||
|
||||
### 3.1. Предприниматели
|
||||
- Интересуются запуском стартапа, токенизацией бизнеса, участием в акселераторе.
|
||||
- Могут быть из разных юрисдикций и отраслей.
|
||||
- Ищут инструменты для управления, учета, приема платежей, автоматизации.
|
||||
|
||||
### 3.2. LP (Liquidity Providers)
|
||||
- Инвесторы, желающие получить доступ к метрикам DLE, ранним инвестициям, доле в фонде.
|
||||
- Интересуются прозрачностью, возвратом инвестиций, управлением токенами.
|
||||
|
||||
### 3.3. Стартапы-участники акселератора
|
||||
- Уже приобрели софт, участвуют в акселерационных программах.
|
||||
- Ищут финансирование, экспертизу, партнерство.
|
||||
|
||||
### 3.4. Холдеры админ токенов
|
||||
- Заинтересованы в управлении фондом, получении обновлений, возврате средств.
|
||||
|
||||
### 3.5. Регуляторы и партнеры
|
||||
- Интересуются прозрачностью, юридическими аспектами, сотрудничеством.
|
||||
|
||||
## 4. Примеры типовых запросов и сценариев
|
||||
- Как установить и настроить софт?
|
||||
- Как получить финансирование для стартапа?
|
||||
- Как стать участником акселератора?
|
||||
- Как LP может получить доступ к метрикам?
|
||||
- Как вернуть средства за админ токены?
|
||||
|
||||
---
|
||||
|
||||
## 5. RAG-таблица (для дальнейшего наполнения)
|
||||
| Вопрос | Ответ | Категория |
|
||||
|--------|-------|-----------|
|
||||
| | | |
|
||||
|
||||
## 6. Сценарии взаимодействия
|
||||
(заполняется по мере детализации бизнес-процессов)
|
||||
|
||||
## 7. Использование тегов для сегментации и персонализации
|
||||
Для каждого вопроса и ответа в RAG-таблице добавляется столбец с мультивыбором тегов клиентов. Это позволяет:
|
||||
- Связывать вопросы и ответы с определёнными сегментами пользователей (например, предприниматель, LP, стартап, холдер, регулятор, отрасль, регион и т.д.).
|
||||
- Персонализировать рекомендации ассистента на основе тегов пользователя.
|
||||
- Масштабировать базу знаний, добавляя новые теги и сегменты по мере развития проекта.
|
||||
|
||||
**Пример расширенной структуры RAG-таблицы:**
|
||||
| Вопрос | Ответ | Категория | Теги клиентов |
|
||||
|--------|-------|-----------|--------------|
|
||||
| Как получить финансирование? | ... | Инвестиции | предприниматель, стартап, акселератор |
|
||||
| Как вернуть средства за токены? | ... | Тарифы | холдер, LP |
|
||||
| Как установить софт? | ... | Продукт | предприниматель, стартап |
|
||||
|
||||
## 8. Фильтры для работы с таблицами
|
||||
Для удобства редактирования и поиска в таблицах реализуются фильтры:
|
||||
- По тегам клиентов (мультивыбор).
|
||||
- По категориям вопросов/ответов.
|
||||
- По продуктам и услугам.
|
||||
- По статусу (активен, архив и др.).
|
||||
|
||||
Фильтры позволяют быстро находить, редактировать и анализировать релевантные записи, а также персонализировать отображение данных для разных ролей пользователей.
|
||||
|
||||
## 9. Пользовательские таблицы, multiselect-столбцы и связи
|
||||
|
||||
### 9.1. Гибкая структура пользовательских таблиц
|
||||
- Пользователь может создавать собственные таблицы (user_tables), столбцы (user_columns) и строки (user_rows).
|
||||
- Для каждого столбца можно выбрать тип: text, select, multiselect, relation и др.
|
||||
- Для multiselect/select-столбцов значения (опции) хранятся в поле options столбца и могут добавляться/удаляться прямо из интерфейса.
|
||||
|
||||
### 9.2. Хранение и настройка связей
|
||||
- Для связи между сущностями (например, пользователь — партнеры, вопрос — продукты) используется отдельная таблица связей (например, user_multiselect_values: id, user_id, column_id, value).
|
||||
- Это позволяет хранить любые связи "многие-ко-многим" между пользователями, вопросами, продуктами и т.д.
|
||||
- Для multiselect-столбцов в RAG-таблице вопросы/ответы можно выбирать продукты/услуги, к которым относится запись.
|
||||
|
||||
### 9.3. Фильтрация и производительность
|
||||
- Фильтрация реализуется через SQL-запросы с JOIN по user_tables, user_columns, user_rows, user_cell_values и таблице связей.
|
||||
- Для multiselect-столбцов фильтрация по значениям возможна через LIKE или jsonb-операторы (при хранении массивов).
|
||||
- Производительность обеспечивается индексами по row_id, column_id и, при необходимости, по value (jsonb gin-индекс).
|
||||
- Такая архитектура масштабируется и используется в современных low-code/CRM системах (Notion, Airtable и др.).
|
||||
|
||||
### 9.4. Пример использования
|
||||
- Пользователь создает таблицу "Партнеры" с multiselect-столбцом.
|
||||
- В интерфейсе контакта можно выбрать партнеров для пользователя — значения сохраняются в user_multiselect_values.
|
||||
- В RAG-таблице вопросы/ответы можно связать с продуктами/услугами через multiselect-столбец.
|
||||
- ИИ-ассистент может фильтровать и персонализировать ответы по этим связям.
|
||||
150
docs/user-tables-relation-task.md
Normal file
150
docs/user-tables-relation-task.md
Normal file
@@ -0,0 +1,150 @@
|
||||
# Техническое задание: Пользовательские таблицы с настраиваемыми связями
|
||||
|
||||
## Цель
|
||||
Реализовать систему пользовательских таблиц, в которых при создании столбца можно настраивать нужные связи (relation/reference/lookup) с другими таблицами.
|
||||
|
||||
---
|
||||
|
||||
## Основные требования
|
||||
|
||||
1. **Пользователь может создавать любые таблицы** (например, "Клиенты", "Теги", "Продукты", "RAG-таблица" и т.д.).
|
||||
2. **Для каждой таблицы можно добавлять столбцы разных типов:**
|
||||
- text, number, date, select, multiselect
|
||||
- relation/reference (связь с другой таблицей)
|
||||
- lookup (вывод связанных данных из другой таблицы)
|
||||
3. **Для столбцов типа relation/reference:**
|
||||
- Можно выбрать, с какой таблицей и каким полем устанавливается связь
|
||||
- Можно выбрать тип связи: один-к-одному, один-ко-многим, многие-ко-многим
|
||||
- В ячейке такого столбца пользователь может выбрать одну или несколько строк из связанной таблицы
|
||||
4. **Связи хранятся в отдельной таблице связей или в value ячейки (массив id)**
|
||||
5. **В интерфейсе:**
|
||||
- При создании/редактировании столбца типа relation пользователь выбирает таблицу и поле для связи
|
||||
- В таблице, в ячейке relation-столбца, отображается выпадающий список/мультивыбор с данными из связанной таблицы
|
||||
6. **Фильтрация и поиск:**
|
||||
- Можно фильтровать строки по связанным значениям (например, все вопросы, относящиеся к определённому тегу или продукту)
|
||||
7. **Масштабируемость:**
|
||||
- Архитектура должна поддерживать создание большого количества таблиц, столбцов и связей без потери производительности
|
||||
|
||||
---
|
||||
|
||||
## Примеры сценариев
|
||||
|
||||
### 1. Связь "Клиент — Теги"
|
||||
- Пользователь создаёт таблицу "Клиенты" и таблицу "Теги"
|
||||
- В таблице "Клиенты" добавляет столбец типа relation, связывающий клиента с одним или несколькими тегами
|
||||
- В каждой строке можно выбрать теги из справочника
|
||||
|
||||
### 2. Связь "Вопрос — Продукты"
|
||||
- В RAG-таблице добавляется столбец типа relation к таблице "Продукты"
|
||||
- Для каждого вопроса можно выбрать, к каким продуктам он относится
|
||||
|
||||
### 3. Lookup-столбец
|
||||
- В таблице "Клиенты" можно добавить lookup-столбец, который автоматически подтягивает связанные значения из другой таблицы (например, список продуктов, которыми пользуется клиент)
|
||||
|
||||
---
|
||||
|
||||
## Требования к backend
|
||||
- Расширить модели user_tables, user_columns, user_rows, user_cell_values
|
||||
- Добавить таблицу связей (например, table_relations: id, from_row_id, column_id, to_table, to_row_id)
|
||||
- API для создания/редактирования столбцов с типом relation
|
||||
- API для получения и сохранения связей
|
||||
|
||||
## Требования к frontend
|
||||
- UI для выбора типа столбца (relation/reference/lookup)
|
||||
- UI для выбора связанной таблицы и поля
|
||||
- UI для выбора значений в ячейке relation-столбца (выпадающий список, мультивыбор)
|
||||
- Фильтрация и отображение связанных данных
|
||||
|
||||
---
|
||||
|
||||
## Преимущества
|
||||
- Максимальная гибкость и масштабируемость
|
||||
- Возможность строить сложные взаимосвязанные базы знаний, CRM, RAG-ассистентов
|
||||
- Удобство для ИИ и аналитики
|
||||
|
||||
## Типы столбцов для пользовательских таблиц
|
||||
|
||||
1. **text** — однострочный текст
|
||||
2. **textarea** — многострочный текст (заметки, описания)
|
||||
3. **number** — число (целое или дробное)
|
||||
4. **date** — дата
|
||||
5. **datetime** — дата и время
|
||||
6. **time** — только время
|
||||
7. **boolean/checkbox** — булево значение (чекбокс)
|
||||
8. **select** — выпадающий список (одиночный выбор)
|
||||
9. **multiselect** — выпадающий список (множественный выбор)
|
||||
10. **file/image** — файл или изображение (загрузка и хранение)
|
||||
11. **relation/reference** — связь с другой таблицей (выбор одной или нескольких строк из другой таблицы)
|
||||
12. **lookup** — автоматический вывод связанных данных из другой таблицы по relation
|
||||
13. **email** — email-адрес с валидацией
|
||||
14. **phone** — телефон с валидацией
|
||||
15. **url** — ссылка/URL с валидацией
|
||||
16. **currency** — число с символом валюты
|
||||
17. **percent** — число с отображением в процентах
|
||||
18. **color** — выбор цвета (colorpicker)
|
||||
19. **user/assignee** — ссылка на пользователя системы (ответственный)
|
||||
20. **status** — список статусов (например, “В работе”, “Готово”)
|
||||
21. **formula** — вычисляемое поле на основе других столбцов
|
||||
22. **progress/rating** — визуальное отображение прогресса, рейтинга (шкала, звёзды)
|
||||
23. **json/object** — хранение структурированных данных (JSON)
|
||||
|
||||
## Плейсхолдеры для интеграции с ИИ-ассистентом
|
||||
|
||||
- Для каждого столбца при создании автоматически генерируется плейсхолдер (placeholder), который можно использовать в промтах и шаблонах для ИИ-ассистента.
|
||||
- Плейсхолдер формируется на основе названия столбца (транслитерация, нижний регистр, замена пробелов на подчёркивания, например: "Партнеры венчурного фонда" → {partners_venchurnogo_fonda}).
|
||||
- Плейсхолдер уникален в рамках таблицы. При совпадении имён добавляется суффикс или используется id столбца.
|
||||
- В таблице user_columns рекомендуется добавить поле placeholder (string, unique).
|
||||
- В интерфейсе при создании/редактировании столбца отображать сгенерированный плейсхолдер (и, при необходимости, давать возможность его редактировать).
|
||||
- В системных промтах и шаблонах для LLM/ассистента значения автоматически подставляются по плейсхолдерам.
|
||||
|
||||
**Пример использования в промте:**
|
||||
```
|
||||
Вопрос: {question}
|
||||
Ответ: {answer}
|
||||
Партнеры: {partners}
|
||||
```
|
||||
|
||||
## Использование плейсхолдеров в системном промте ассистента
|
||||
|
||||
- На странице настроек ассистента (`/settings/ai/assistant`) под полем для системного промта автоматически отображается список всех плейсхолдеров, созданных пользователем в пользовательских таблицах.
|
||||
- Для каждого плейсхолдера показывается:
|
||||
- Сам плейсхолдер (например, `{partners}`)
|
||||
- Название столбца и таблицы, к которому он относится (например, “Партнеры венчурного фонда” — RAG-таблица)
|
||||
- Список плейсхолдеров обновляется автоматически при добавлении/удалении столбцов.
|
||||
|
||||
**Инструкция для пользователя:**
|
||||
> Используйте плейсхолдеры из списка ниже для подстановки значений из пользовательских таблиц в системный промт. Например:
|
||||
> ```
|
||||
> Вопрос: {question}
|
||||
> Ответ: {answer}
|
||||
> Партнеры: {partners}
|
||||
> ```
|
||||
> Плейсхолдеры автоматически заменяются на соответствующие значения при генерации ответа ассистента.
|
||||
|
||||
## Сценарий: добавление тегов пользователю через пользовательские таблицы
|
||||
|
||||
1. **Добавление тега на странице контакта**
|
||||
- На странице контакта (`/contacts/1`) при нажатии на кнопку "Добавить тег" система автоматически создаёт пользовательскую таблицу "Теги клиентов" (если она ещё не создана).
|
||||
- Пользователь может добавить новый тег (например, "VIP", "B2B", "Startup") — он появляется в этой таблице.
|
||||
|
||||
2. **Выпадающий список тегов**
|
||||
- После добавления хотя бы одного тега появляется выпадающий список (или мультивыбор), в котором отображаются все теги из таблицы "Теги клиентов".
|
||||
- Пользователь может выбрать один или несколько тегов для текущего контакта.
|
||||
|
||||
3. **Связь пользователя с тегом**
|
||||
- При выборе тега для пользователя создаётся связь между пользователем и тегом.
|
||||
- Эта связь хранится в отдельной пользовательской таблице (например, `user_tag_links` или универсальной таблице связей), где фиксируется, какой пользователь связан с каким тегом.
|
||||
- Пример структуры таблицы связей:
|
||||
| id | user_id | tag_id |
|
||||
|----|---------|--------|
|
||||
| 1 | 1 | 2 |
|
||||
| 2 | 1 | 3 |
|
||||
|
||||
4. **Обратная связь (теги → пользователи)**
|
||||
- В таблице "Теги клиентов" можно реализовать обратную связь: для каждого тега показывать список пользователей, у которых он установлен (например, через relation/lookup-столбец).
|
||||
|
||||
5. **Итог:**
|
||||
- Пользователь может создавать и редактировать теги.
|
||||
- Для каждого контакта можно выбрать теги из выпадающего списка.
|
||||
- Все связи между пользователями и тегами хранятся в отдельной таблице.
|
||||
- Можно быстро получить список всех пользователей с определённым тегом и наоборот.
|
||||
108
docs/vector-search-service.md
Normal file
108
docs/vector-search-service.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# Техническое задание: Векторный сервис поиска по таблице
|
||||
|
||||
## Цель
|
||||
Реализовать отдельный микросервис для векторного поиска по данным из таблицы в базе данных. Сервис должен предоставлять REST API для добавления, поиска и обновления векторных представлений (эмбеддингов) строк таблицы.
|
||||
|
||||
## Язык и стек
|
||||
- Язык: Python 3.10+
|
||||
- Векторный движок: FAISS
|
||||
- API: FastAPI
|
||||
- Хранение индекса: на диске (persistency)
|
||||
- Docker-образ для деплоя
|
||||
|
||||
## API сервиса
|
||||
|
||||
### 1. Добавление/обновление записей
|
||||
- **POST /upsert**
|
||||
- Тело запроса:
|
||||
```json
|
||||
{
|
||||
"table_id": "string", // идентификатор таблицы
|
||||
"rows": [
|
||||
{
|
||||
"row_id": "string", // идентификатор строки
|
||||
"text": "string", // текст для эмбеддинга
|
||||
"metadata": { ... } // любые дополнительные поля
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
- Ответ: `{ "success": true }`
|
||||
|
||||
### 2. Поиск похожих записей
|
||||
- **POST /search**
|
||||
- Тело запроса:
|
||||
```json
|
||||
{
|
||||
"table_id": "string",
|
||||
"query": "string", // текст запроса
|
||||
"top_k": 3 // количество результатов
|
||||
}
|
||||
```
|
||||
- Ответ:
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{
|
||||
"row_id": "string",
|
||||
"score": float,
|
||||
"metadata": { ... }
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Удаление записей
|
||||
- **POST /delete**
|
||||
- Тело запроса:
|
||||
```json
|
||||
{
|
||||
"table_id": "string",
|
||||
"row_ids": ["string", ...]
|
||||
}
|
||||
```
|
||||
- Ответ: `{ "success": true }`
|
||||
|
||||
### 4. Пересоздание индекса (опционально)
|
||||
- **POST /rebuild**
|
||||
- Тело запроса:
|
||||
```json
|
||||
{
|
||||
"table_id": "string"
|
||||
}
|
||||
```
|
||||
- Ответ: `{ "success": true }`
|
||||
|
||||
## Требования к эмбеддингам
|
||||
- Для генерации эмбеддингов сервис использует Ollama (через HTTP API, модель mxbai-embed-large или аналогичную).
|
||||
- Эмбеддинги кэшируются локально для ускорения поиска.
|
||||
|
||||
## Требования к интеграции
|
||||
- Сервис не хранит бизнес-логику, только индексы и метаданные.
|
||||
- Node.js backend обращается к сервису по HTTP (localhost или через docker-compose).
|
||||
- Все операции атомарны, сервис устойчив к сбоям.
|
||||
|
||||
## Безопасность
|
||||
- Сервис доступен только во внутренней сети (docker-compose).
|
||||
- Нет публичного доступа извне.
|
||||
|
||||
## Мониторинг и логирование
|
||||
- Логирование всех запросов и ошибок.
|
||||
- Healthcheck endpoint: **GET /health** (ответ: `{ "status": "ok" }`)
|
||||
|
||||
## Docker
|
||||
- Сервис должен запускаться как отдельный контейнер.
|
||||
- Все зависимости описаны в requirements.txt.
|
||||
|
||||
## Пример docker-compose.yml (фрагмент)
|
||||
```yaml
|
||||
services:
|
||||
vector-search:
|
||||
build: ./vector-search
|
||||
ports:
|
||||
- "8001:8001"
|
||||
environment:
|
||||
- OLLAMA_BASE_URL=http://ollama:11434
|
||||
depends_on:
|
||||
- ollama
|
||||
```
|
||||
Reference in New Issue
Block a user