theextensional / knowledge-api Goto Github PK

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

• количество просмотров данной заметки
• количество переходов по данному запросу
• источник перехода
• персонализация (статистика пользователя)

Проблема:
Пакетный менеджер PIP не удалит из системы те библиотеки, которые были удалены из файла requirements. Как минимум это приводит к засорению системы, как максимум - к конфликту, если у заменяемой библиотеки будет одинаковое название (например, форк).

При конкретном запросе выдаются только соседние пункты, но не сам результат

Хотелось бы иметь возможность экстренно обновлять базу и редеплоить сервер вручную. А также просматривать, когда было последнее обновление (это даст понимание, отработал ли хук), последние поисковые запросы (даст понимание, пользуется ли кто базой).

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

Нужно поправить фронтальную часть.

Ошибка замечена Арсением.

Проблема: на данный момент управление скриптом только через консоль.
Решение: создать панель управления.

Я как администратор:

• могу залогиниться в кабинет через логин пароль, либо googleAccount
• есть возможность обновить базу знаний в Firestore

Проблема

Сейчас перед обновлением базы происходит удаление всех заметок, что может привести к опустошению базы, если обновление не сработает.

Решение

Первый способ:
Необходимо как-то сначала добавлять новые заметки, затем удалить старые. Либо в транзакции удаляем все заметки перед добавленим первой порции новых.

Изменения вносить в класс UploaderDjangoServer

Проблема не критична, так как обновление происходит при коммитах автоматически и обновлять базу вручную необходимости нет.

Сейчас не ясно, насколько активно используют поиск по заметкам в Телеграм и Дискорде. По активности поиска можно оценивать актальность функционала.

Задача пока большой актуальности не имеет. А в будущем, при разделении репозитория на микросервисы можно будет задействовать сторонее приложение "Gravitee.io": https://habr.com/ru/company/X5Tech/blog/543324/ , предназначенное для логирования создания единой точки входа в API разных микросервисов и логирования/анализа запросов к ним.

Романом были предложены следующие правки для устранения неоднозначсти/неясности полей:

Блок "1. Цель"

1. Добавить поле "Первоначальные решение"

Блок "2. Участники"

1. Переименовать в "Обязательные участники"
2. либо добавить столбец "Обязательно ли присутствие участника"

Блок "3. Повестка"

1. Добавить поле "Принципиальные возражения"
2. Добавить поле "Предлагаемые решения"
3. Добавить поле "Встречные предложения"
4. Поле "Мнение/вопросы" переименовать в "Вопросы", так как слово "Мнение" - высокоабстрактное
5. Поле "Темы" переименовать в "Тема выступления участника"

Источник: https://discord.com/channels/651126451998818320/1060293974893543545/1076921561921093654

P.S. Мне смотрится полезным в блоке "Повестка" разделить поле "мнение" на принципиальные возражения, встречные предложения и предлагаемые решения, так как разделение сделает более очевидным, что нужно указывать в данном поле.

Изначально сообществом была задумана архитектура микросервисов.

Проблема: при поиске выдача в никому не нужном алфавитном порядке.

Решение: изучение алгоритмов поиска и выдачи результатов.

Информация к размышлению

• https://kokoc.com/blog/relevantnost-ehto-chto-takoe-prostymi-slovami/
• https://ru.wikipedia.org/wiki/TF-IDF
• https://ru.wikipedia.org/wiki/%D0%9B%D0%B0%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE-%D1%81%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7
• https://habr.com/ru/post/491448/

Концепты:

• TF-IDF
• Латентно-семантический анализ
• Ссылочная масса
• количество просмотров данной заметки
• конверсия (CTR)
• количество переходов по данному запросу
• персонализация (статистика пользователя) «пузырь фильтров» (показатель возвратов)
• близость к началу предложения и документа
• виды вхождения запроса. Они могут быть прямыми, разбавленными и словоформами (fuzzywuzzy)
• наличие ключевых слов в Title и H1, ссылочных анкорах, метатегах и прочих элементах контента

Готовые скрипты

• https://whoosh.readthedocs.io/en/latest/index.html

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

Решение:
Кнопка активна, если на гитхабе существуют свежие коммиты (и их нет в ветке на сервере). Рядом указывать количество свежих коммитов.

В противном случае кнопка неактивна, выводится надпись о

Проблема: При вводе цели приглашения участника в блоке "Участники" значение не сохраняется

Это приведёт к тому, что приглашённый участник не будет понимать, для чего его пригласили.

Проблема: имеющееся API является черновым и, можно сказать, его нет. Это препятствует разработке приложения activista.

API должно позволять:

• добавлять новые холсты
• редактировать существующие
• получать холсты (в виде JSON и в виде заметки)

• Если заметка была переименована, произойдёт попытка её получить из базы, что приведёт к паднению
• Сохранять тело запроса от гитхаба в базу, чтобы при падении было возможно принудительно вызвать хук. После успешного завершения удалять хук из базы. Сейчас же при падении сервера мы вынуждены сносить базу и делать заново полный импорт django-командой.

Сейчас есть API для поиска и получения заметок, но нет для добавления. Это препятствует реализации приложения Activista.

Проблема: сейчас все статические файлы расположены вне репозитория, следовательно при локальном запуске будут отсутствовать *.css и *.js

Решение: перенести директорию со статическими файлами в репозиторий, поправить в settings.py путь к статике.