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

推荐订阅源

人人都是产品经理
人人都是产品经理
有赞技术团队
有赞技术团队
L
LangChain Blog
C
Check Point Blog
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
GbyAI
GbyAI
美团技术团队
博客园 - 司徒正美
Google DeepMind News
Google DeepMind News
WordPress大学
WordPress大学
aimingoo的专栏
aimingoo的专栏
S
SegmentFault 最新的问题
A
About on SuperTechFans
Blog — PlanetScale
Blog — PlanetScale
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗
腾讯CDC
B
Blog
G
Google Developers Blog
The Cloudflare Blog
P
Proofpoint News Feed

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

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет 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 на стыке философии, критической теории и технологий - буду рад подписке.