Без сервера CMS ( просто простой текст !!! ) На основе отметки с расширениями для многомерной классификации таксономии, позволяя ориентироваться в контенте на основе тем (оси) и подтопиков (координаты).
Эти проекты направлены на то, чтобы обеспечить простой в использовании инструмент для управления документацией «долгой жизни» (годы или десятков лет).
Рекомендуется безопасно хранить и классифицировать исследовательские (PHD), сложную программную документацию, сложные процедуры, написание книг, «промышленные» веб -страницы. Несколько примеров для нетерпеливо:
Поскольку контент - это просто простой текст (по сравнению с некоторым странным форматом двоичной базы данных) это означает, что многие инструменты могут быть использованы для редактирования и управления контентом после «Сделайте одну вещь и сделайте это правильно!» UNIX Философия.
Следующие функции поступают бесплатно:
┌──────────────────────────────────────────────────────────────┐
├─ CONVENTIONAL CMS (CONFLUENCE, SHAREPOINT, ...) ────────────┤
├──────────────────────────────────────────────────────────────┤
│ │
│1) Central CMS Server 2) "Fool" Browser │
│ ────────────────── ────────────────│
│ DDBB <··· network···> Render conent │
│ Single place of failure │
│ (single place of attack) │
│ Binary format │
│ Server/CMS/Network Admins │
│ │
├──────────────────────────────────────────────────────────────┤
├─ STATIC SITE GENERATOR (NEXT, ...) ─────────────────────────┤
├──────────────────────────────────────────────────────────────┤
│ │
│1) "Source" Content 3) Web Server │
│ ───────────────── ┌····> ──────────── ···┐ │
│ (git versioned, p2p · Publish · │
│ distributed) · "compiled" html · │
│ · · · │
│ · · · │
│ · · v │
│ · 2) Compile 4)"Fool" Browser │
│ └─····> ───────────────── ────────────── │
│ Generates HTML Render content │
│ in opinionated ways │
│ using "complex" tooling │
│ (npm, transpilers, modules, │
│ packagers, ...) │
│ │
├──────────────────────────────────────────────────────────────┤
├─ TXT WORLD DOMINATION PROJECT ──────────────────────────────┤
├──────────────────────────────────────────────────────────────┤
│ │
│1) "Source" Content 2) "Inteligent" Browser │
│ ───────────────────────── ··> ─────────────────────────── │
│ markdown+topic.sub. tags Fetch local/remote "payload"│
│ (git versioned, p2p Processes it. Generate │
│ distributed) HTML, taxonomy, indexes, │
│ · extensions, ... │
│ · │
│ ├─·· or ··········>2) Printer │
│ · ─────────────────────────── │
│ · Print to paper │
│ · (extensions ignored) │
│ · │
│ ├─·· or ··········>2) LLM Learning Algorithm │
│ · ─────────────────────────── │
│ · - LLM training algorithm. │
│ · topics/subtopics provide │
│ · (huge) dimensionality │
│ · reduction!!! │
│ · │
│ ├─·· or ···········>2) JAVA/Rust/Python/... IDE │
│ · ─────────────────────────── │
│ · Improve source code │
│ · navigation based on │
│ · topics.subtopics concerns │
│ · like UI, QA, security, .... │
│ · │
│ ├─·· or ···········>2) (Fill with new ideas and │
│ · use-cases) │
└──────────────────────────────────────────────────────────────┘
Установки или подмножества текстовых файлов (Markdown, Source Code) могут быть сгруппированы в один «большой» окончательный виртуальный файл через списки «полезной нагрузки». Список - это просто обычный файл TXT, указанный в каждой новой строке, список файлов Markdown для Concatenate, чтобы сформировать окончательный документ Markdown. Пример:
full_book.payload security_book.payload frontend_book.payload
----------------- --------------------- ---------------------
./introduction.md ./chapter4.md ./chapter1.md
./chapter1.md ./chapter5.md ./chapter2.md
./chapter2.md ./chapter9.md ./chapter9.md
./chapter3.md
./chapter4.md
./chapter5.md
./chapter6.md
./chapter7.md
./chapter8.md
./chapter9.md
Всего несколько примеров того, как этот проект используется для документирования документации в реальном мире:
Зачем делать заметки в эпоху машинного обучения и крупных языковых моделей?
Проще говоря. Они дополняют друг друга:
ИИ работает «нормально» при применении к ограниченным (не очень небольшим) контекстам, например, основным задачам программирования или (не такими основными) математическими задачами с четко определенным набором и операциями (алгебраические проблемы, проблемы с шахматами, ...).
Я работаю в мире разработки программного обеспечения. Позвольте мне подвести итог мой опыт:
С другой стороны, когда делаем заметки от экспертов, мы можем пометить конкурирующие продукты, выделять плюсы/минусы, принимать чит-листы, аннотировать с помощью использования, ожидающих функций, такими вещами.
Мы можем получить некоторую «информацию» и заполнить некоторую предыдущую заметку (возможно, написано 4 года назад), чтобы контент был неполным, начинал «иметь смысл». Наконец, мы можем принимать гораздо более разумные решения.
Благодаря расширенному приглашению, чтобы сделать ИИ возвращать разумные ответы ... но продвинутое быстрое управление быстрого инженера намного сложнее и трудоемкое, которое просто принимает и классифицирует заметки . На самом деле, я бы сказал, что принятие и классификацию заметок, создание четко определенной и стабильной таксономии-это «обязательна» для «продвинутых» оперативных инженерных инженеров .
Мы можем спросить бота LLM о решении задачи, и много раз она будет работать. Возникают некоторые вопросы:
Мы спрашиваем LLM, потому что игнорируем решение на первом месте, поэтому мы, вероятно, игнорируем альтернативные решения и, вероятно, игнорируем многие другие вещи (помните риск неизвестных неизвестных .). Если мы сделаем заметки о связанных задачах и связанных альтернативах для аналогичных задач, мы теперь можем добавить такую информацию в нашу подсказку, и мы также можем рассмотреть вопрос о заполнении «ортогональными» аспектами (QA, безопасность, отделение, лучшие шаблоны, ...). Таким образом, мы помогаем LLM уменьшить размерность проблемы, и наша подсказка будет гораздо более эффективной подсказкой.
Не нужно сказать, что LLM также может помочь нам разработать нашу таксономию, предлагая темы и подтопики. В этом смысле обе системы могут питать друг друга в бесконечной петле. Отлично, не так ли?