惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
N
Netflix TechBlog - Medium
V
Visual Studio Blog
博客园 - Franky
小众软件
小众软件
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 三生石上(FineUI控件)
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
宝玉的分享
宝玉的分享
量子位
大猫的无限游戏
大猫的无限游戏
人人都是产品经理
人人都是产品经理
V
V2EX
The Cloudflare Blog
月光博客
月光博客
Last Week in AI
Last Week in AI
雷峰网
雷峰网
WordPress大学
WordPress大学
博客园 - 【当耐特】
博客园 - 聂微东
IT之家
IT之家
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Почему LLM Wiki Карпатого не стоит внедрять для личной ба...
kitnikita · 2026-04-19 · via Все публикации подряд на Хабре

Простой

2 мин

3.9K

Мнение

Андрей Карпатый недавно написал про замену RAG - LLM Wiki. Если вкратце, Карпатый предлагает модель, в которой LLM читает сырые источники, пишет страницы wiki в базе знаний, поддерживает перелинковку между заметками, а человек - читает, задаёт вопросы, делает ревью. И вся эта система живёт практически автономно - человек крайне редко трогает файлы заметок.

Мне кажется, полезно сделать важный комментарий - его модель хорошо работает для логики решения корпоративных задач (где знания = справочник), но думать про подобное внедрение LLM в личные заметки - скорее вредно. Я верю, что для Андрея это работает: у него много интеллектуально сложных технических задач, потребность в реальных изобретениях. У большинства людей, к счастью, ситуация не требует такой глубокой оптимизации и автоматизации.

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

Подход Карпатого прямо противоречит тезису "письмо = мышление", на основе которого строится глубокая рефлексия. Когнитивный акт происходит в письме, не до него и, тем более, не после.

У базы знаний, безусловно, может быть две функции - инструментальная (запоминать) и рефлексивная (понимать). Нужно всегда держать в голове, что у Карпатого отягощающий бэкграунд в IT, и это желание постоянно всё оптимизировать и автоматизировать накладывает свои особенности - я часто замечаю, как в IT-сообществе база знаний становится во многом инструментом повышения личной и рабочей эффективности, чем практикой рефлексии (а изначальный запрос - как раз на рефлексию).

Мишель Фуко в конце своей жизни подробно рассматривает одну из важнейших "практик заботы о себе" - hypomnemata. Это записные книжки (по типу писем стоиков, эпикурейцев), функция которых - не архивная, а присваивающая. Писать, чтобы "строить себя", описывая прочитанное, услышанное, подуманное. Перечитывание заметок в таком случае также играет роль только перепроживания мысли, а не восстановления контекста для выполнения задачи. 

Карпатый, на мой взгляд, своим постом выкручивает на минимум часть письма как практики заботы о себе, и максимизирует мнемоническую функцию, где заметка выполняет только инструментальную роль. И, если Карпатый подробно описал как сделать "инструментальную базу знаний", то мне хочется дополнить противоположными советами про личную базу:

  • Переписывание прочитанного в свои слова и мысли - не делегировать в LLM.

  • Связи между заметками искать самому. Автогенерация бэклинков даёт граф, но не даёт узнавания: "о, это же про то, о чём я думал в октябре". Узнавание и есть мышление.

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

  • Автоматизировать можно то, что идёт до письма (транскрибация, сбор источников) и то, что после (поиск по базе знаний). Сам момент письма оставляем - это граница, которую Карпатый стирает.

  • Разделять контуры базы знаний на рефлексивную и справочную.

Фактически, это может влиять только на структуру базы знаний: в рефлексивных заметках она более свободная, удобная для чтения, а в инструментальных - жесткая, выступающая скорее контекстом для языковой модели, которая будет считывать эти заметки.

В телеграм-канале пишу про внедрение AI на стыке философии, критической теории и технологий - буду рад подписке.