Hacker News Digest

Open Executive — это система виртуального исполнительного руководства, построенная на восьми специализированных агентах Claude (CSO, CFO, CHRO, GC, COO, CMO, CPO, Director of Board Communications), которые работают за кулисами, но отвечают единым, согласованным голосом старшего исполнителя с уровнем знаний Harvard MBA. Система использует архитектуру RAG: каждый запрос проходит через Executive Orchestrator (claude-sonnet-4-6), который параллельно вызывает специалистов, извлекающих релевантный контекст из двух слоёв — встроенной MBA-базы знаний (в ChromaDB, git-tracked) и загруженных пользователем корпоративных документов (в отдельной коллекции company_docs). После генерации ответа фоновый процесс claude-haiku-4-5 сохраняет ключевые решения и инициативы в SQLite как эпизодическую память, которая подгружается в начало следующей сессии в блоке <past_decisions>. Также есть встроенный планировщик для проактивных напоминаний о времени чувствительных действиях.

Для расширения системы под новые домены требуется: добавить alias в DOMAIN_ALIASES, разместить Markdown-документы в knowledge/builtin/your_domain/, подготовить минимум два сценария оценки в evals/scenarios/ и отправить PR — CI проверяет наличие всех компонентов. Оценка качества проводится через набор из 29 сценариев, где claude-opus-4-7 выступает в роли LLM-as-judge по пяти измерениям (коherence persona, domain accuracy, использование контекста компании, качество маршрутизации, actionability), требуя среднего балла ≥3.5/5; падение любого измерения более чем на 10% относительно main блокирует PR. Все пользовательские данные (профиль YAML, загруженные файлы, ChromaDB) хранятся локально и игнорируются git, никогда не покидая устройство или приватный том в облаке, кроме как в промптах, отправляемых в Anthropic API, которые не используются для обучения моделей. Лицензия — Apache 2.0.

Тред воспринимает проект преимущественно как шуточный PR-ход и сатиру на замену разработчиков AI. Главное добавление дискуссии — концептуальное: @Animats выделяет это как новый класс «corporate-level AI» (организация из агентов), а не «human-level AI», и сравнивает с Gas Town и подходом «Fences, not Sandboxes». Скептики (@janalsncm, @walrus01) указывают на практические минусы — высокая стоимость токенов и качество ответов на уровне обычного ChatGPT. @reillyse возражает против самой посылки тредa: роль CEO — защищать капитал, а не отвечать на вопросы, поэтому замена AI нерелевантна.

• Спор: @reillyse спорит с доминирующим нарративом треда: CEO должен «исчезнуть на год» без ущерба для компании, его функция — защита инвестированного капитала, а не ответы на вопросы; поэтому AI-замена бьёт мимо цели. Большинство же (@Animats, @theodorewiles, @drTobiasFunke) считают, что AI лучше справится с обзором данных и принятием решений, чем люди-CEO.

• Почти все сходятся, что проект — это сатира и PR-жест, а не рабочий инструмент: @hypfer называет это «petty performative PR stunt», @janalsncm не видит преимущества над ChatGPT из коробки, @walrus01 предупреждает о раздувании счёта за Anthropic-токены.

• Несколько комментаторов (@Animats, @theodorewiles, @arjie) сходятся, что реальная ценность — не «AI-CEO», а AI как структурированный корпоративный decision-maker с прозрачной историей решений; @yunnpp добавляет, что auditable executive сам по себе — это новинка.

• Совет: @thelastgallon советует продвигать замену CEO через shareholder resolutions с готовыми промптами, предлагая формат SKILLs.md для инициативы.

• Совет: @dchftcs предлагает конкретный сценарий: технари, застрявшие в низкоуровневых задачах, должны использовать AI, чтобы подняться до product/decision-making ролей и конкурировать с текущими CEO.

• Спор: @Animats утверждает, что multi-agent «организационный» AI — это новая важная категория, требующая внимания, хотя такие системы «expensive to operate» из-за внутренних коммуникаций агентов. @walrus01 подтверждает высокую стоимость токенов, но это скорее практическая претензия, чем возражение по существу.

• @edoceo, @drTobiasFunke, @bwhiting2356 отмечают, что часть функций CEO (vision, prioritization, координация, data-driven decisions) теоретически воспроизводима AI, но @bwhiting2356 возражает: high-order strategy, relationship building и управление людьми будут автоматизированы последними.

• Совет: @chanux предлагает обратный эксперимент: пусть C-suite попробует управлять только с AI и посмотрит на результат, чтобы сравнить с гипотезой AI-CEO.

• Спор: @holoduke жалуется на разрыв между «gold plated stories» об автономных агентах и реальностью: он сам использует AI весь день, но ни разу не видел полностью рабочую замену команды людей — это прямой прод-опыт против хайпа.

• Ряд комментаторов (@arjie, @nullorempty, @matheusmoreira) распространяют идею замены дальше: на worker cooperatives, политиков, чиновников — аргумент, что AI не подвержен компромату и bias-у.

• @__MatrixMan__ ставит экспериментальный вопрос: если компании под управлением людей систематически проигрывают AI-управляемым, это говорит больше об AI или о том, как власть коррупционирует людей — прямого ответа в треде нет.

Большинство команд переусложняют RAG-системы, сразу внедряя эмбеддинги и векторные БД, хотя пользователи часто ищут простые документы вроде «Как сбросить пароль». Автор предлагает пошаговый подход: начинать с простых решений и переходить к сложным только при доказательстве необходимости. Ключевые факторы выбора архитектуры — свежесть данных, характеристики корпуса, паттерны запросов, нагрузка и компетенции команды.

Для большинства случаев (60%) достаточно полнотекстового поиска (BM25, Elasticsearch, Postgres) с переформулировкой запросов через LLM — это дешево, быстро (<50 мс), не требует чанкинга и легко отлаживается. Если нужно лучшее семантическое понимание, добавляют гибридный поиск: on-the-fly эмбеддинги для часто меняющихся данных (200–500 мс задержка), hot/cold tiers для средней нагрузки (50–100 мс) или полное предварительное эмбеддинги для стабильного корпуса и высокой нагрузки (<50 мс, но сложно в поддержке). Только 10% систем требуют полного предварительного эмбеддинга, а 5% — кастомных решений. Главное — не строить сложную систему для простой задачи.

Обсуждение подтверждает, что полнотекстовый поиск (FTS) и BM25 чаще всего достаточны для RAG, а векторные эмбеддинги и векторные БД добавляют сложность, стоимость и операционную нагрузку без значимого прироста качества в большинстве реальных сценариев. FTS прост, портативен, масштабируем и решает 80% задач. Эмбеддинги требуют постоянной настройки, переэмбеддинга и сопровождения, не давая ожидаемого преимущества. BM25 — надёжный старт для RAG; эмбеддинги стоит добавлять только когда ключевой поиск действительно не справляется. Операционная нагрузка от векторных БД (обновление, хранение, реранкинг) часто превышает выгоды, особенно для небольших или внутренних корпусов. При этом размер чанков важнее выбора модели поиска — неправильный чанк сводит на нет преимущества любого подхода. Многие RAG-системы работают лучше без ретривала: когда ретривал-патч возвращал нулевые результаты, пользователи этого не замечали. **Практические советы:** - Для простого RAG с PostgreSQL — plpgsql_bm25, открытая реализация BM25 на PL/pgSQL без внешних зависимостей. - При отсутствии больших корпусов — эмбеддить всё сразу, суммировать и очищать текст дешёвой моделью, затем хранить в BigQuery, который нативно поддерживает векторный поиск. - Агенты для итеративного переформулирования запросов к Lucene/FTS дают эффект, близкий к эмбеддингам, но без неопределённости. - Для локального RAG с клиентскими моделями — Qdrant и Mem0 (обновление в реальном времени, без облака). - Сначала оценить паттерны запросов: если пользователи не знают точных ключевых слов, эмбеддинги могут быть оправданы, иначе — FTS. - Агенты с простыми инструментами автоматически усиливают усилия для сложных вопросов и минимизируют их для простых, снижая общую сложность. **Спор:** - Часть участников считает, что 90% документальных RAG-проектов должны использовать семантический поиск как основной метод — он прост и эффективен. - Другие возражают: эмбеддинги добавляют неопределённость на неопределённость (LLM + семантический поиск), тогда как лексический поиск предсказуем и надёжен. Большинство современных RAG-систем на деле — это FTS с переформулированием и реранкингом, а не настоящий семантический поиск. Сложность RAG-архитектур часто неоправданна.

За 8 месяцев работы над RAG-системами для обработки 13+ миллионов документов автор выявил ключевые факторы успеха. Начав с типового стека Langchain + Llamaindex по туториалам, команда столкнулась с тем, что прототип на 100 документах показывал отличные результаты, а на полном наборе данных - провальные. Основные улучшения, давшие наибольший эффект: генерация множества семантических и ключевых запросов параллельно с исходным, реранкинг (оптимальное соотношение 50:15 чанков), тщательная настройка чанкинга с сохранением логических единиц, добавление метаданных в контекст LLM и маршрутизация запросов, не требующих поиска по базе.

Технологический эволюция включала переход от Azure к Pinecone, а затем Turbopuffer для векторного хранилища, от Cohere к Zerank для реранкинга, и от GPT-4.1 к GPT-5 и обратно. Автор подчеркивает, что реранкинг - "самые ценные 5 строк кода", а на чанкинг уходит большая часть времени. Весь опыт был упакован в open-source проект agentset под лицензией MIT.

• Обсуждение охватывает широкий спектр тем: от генерации синтетических запросов и проблем с их качеством до самостоятельного хостинга, отсутствия настоящего самостоятельного хостинга и до влияния выбора модели эмбеддинга на качество и стоимость.
• Участники обмениваются практическими советами по оптимизации чанкинга, реранкинга и использованию различных моделей эмбеддинга и ранжирования.
• Обсуждаются сложности с интеграцией и стоимостью при использовании сторонних сервисов, а также вопросы безопасности и контроля при использовании облачных сервисов.
• Рассматриваются вопросы о том, какие факторы действительно важны при выборе инструментов и подходов, и какие из них являются просто маркетинговыми фишками.

RAG-архитектура, доминировавшая в AI последние три года, уступает место новым подходам. Ранние модели вроде GPT-3.5 ограничивались 4–8 тыс. токенов, что делало невозможной работу с объёмными документами — например, отчёт SEC 10-K содержит ~51 тыс. токенов. RAG решал это через разбиение текста на фрагменты (чанки) и поиск релевантных частей, но даже продвинутые методы чанкинга не спасали от потери контекста: финансовые таблицы, сноски и связи между разделами разрушались.

Современные модели с контекстом в миллионы токенов (например, Gemini 1.5) и агентные архитектуры делают RAG избыточным. Зачем извлекать фрагменты, если можно загрузить весь документ целиком? Это устраняет проблемы чанкинга, эмбеддингов и повторного ранжирования. Ключевой вывод: эра компромиссов между точностью и контекстом заканчивается — будущее за системами, работающими с полными данными без промежуточных шагов.

• Участники критикуют автора за чрезмерное обобщение: утверждение о "смерти RAG" основано на узком примере поиска в коде и не учитывает масштабируемость и другие сложные use-case'ы (например, миллионы документов в распределенных системах).
• Подчеркивается, что RAG — это общий паттерн (извлечение информации + обогащение контекста), а не только векторный поиск; grep, SQL, API-вызовы или использование агента с инструментами — это тоже формы RAG.
• Отмечается, что агентный поиск (с использованием инструментов вроде grep, BM25 и др.) может быть мощнее классического RAG, но он медленнее, дороже и сложнее из-за множественных вызовов функций.
• Указывается, что большие контекстные окна LLM позволяют им читать целые файлы, что меняет workflow и снижает необходимость в сложных пайплайнах чанкинга и эмбеддингов.
• Многие видят иронию в том, что автор называет RAG "кошмаром edge-кейсов", в то время как агентный подход с инструментами вроде grep introduces свои сложности (производительность, безопасность, детерминизм).

Основная идея
Авторы утверждают, что современные LLM уже близки к «стене» роста качества: дальнейшее увеличение моделей и данных даёт лишь логарифмический прирост, а затраты растут экспоненциально.

Причины стены

• Исчерпаемость данных: высококачественный текст в интернете ограничен; синтетические данные быстро насыщают.
• Сложность задач: после решения «лёгких» 90 % остаются «трудные» 10 %, где ошибки почти не коррелируют с размером модели.
• Экономика: чтобы снизить ошибку в 2 раза, нужно в 10–100× больше ресурсов.

Эксперименты
На MMLU, GSM8K, HumanEval и BIG-Bench наблюдается выравнивание кривых качества даже при масштабировании на порядки.

Что делать

• Переход к специализированным моделям и инструментам (код-интерпретаторы, поиск).
• Агентские схемы, где LLM вызывает API и внешние системы.
• Новые архитектуры (MoE, RAG, RL) и синтетические данные нового типа (симуляции, мультимодальные сцены).

Вывод
Чистое масштабирование скоро исчерпается; прорыв потребует перехода от «больших» к «умным» системам.

• Обсуждение крутится вокруг того, можно ли свести понимание и логическое рассуждение к вероятностным моделям вроде LLM.
• Часть участников считает, что формальное равенство с цепями Маркова или LLM ничего не даёт и упускает ключевые вещи — например, backtracking и символьное мышление.
• Другие отвечают, что трансформеры с chain-of-thought уже теоретически могут решать всё в классе P, а агенты с внешними инструментами уже делают backtracking на практике.
• Критика статьи: авторы-физики пишут запутанно, примеров нет, фокус на ядерных реакторах и численных методах выглядит неуместным.
• Сторонники «горького урока» указывают, что дальнейшее увеличение моделей и данных даст больше, чем попытки встроить строгую символику.

• Локальный стек: Ollama (LLM), assistant-ui (веб-интерфейс), Apple container (изолированные ВМ), Playwright (браузер), coderunner (MCP-сервер с Jupyter).
• Цель: чат, запуск кода и доступ в интернет без облаков и утечек данных.
• Проблемы:
  – Модели Ollama пока не поддерживают вызовы инструментов.
  – Создание нативного Mac-приложения провалилось: a0.dev заточен под iOS, Electron + NextJS оказались геморроем.
  – Apple container часто падает с Trap; помогает pkill + перезапуск.
• Решения:
  – Веб-версия assistant-ui через ai-sdk с выпадающим списком моделей (локальных и облачных).
  – Jupyter в изолированной ВМ, доступен по MCP: http://coderunner.local:8222/mcp.
  – Конфиг для Claude Desktop: "coderunner": { "httpUrl": "http://coderunner.local:8222/mcp" }.

• Участники восхищаются локальной, «песочной» архитектурой для приватного AI-воркспейса и инструментом coderunner, но отмечают, что узкие места — это не только софт, но и «железо»: 80B-модели требуют ≥80 ГБ быстрой RAM, что доступно разве что на RTX 4090 или Strix Halo.
• Критичным становится слой знаний: RAG над личными файлами требует вектор-БД, а значит — много диска и оперативки; Docker-обёртка или docker compose up -d просится как минимальный способ разворачивания.
• Пока локальные модели — скорее «увлекательное хобби» (медленно, глючно, нужен тюнинг), чем рабочий инструмент; облачные API (Cerebras, Groq) дают 1000 ток/с, но подрывают приватность.
• Сообщество просит готовый «всё-в-одном» стек: веб-поиск, голосовой режим, image-gen, лёгкий switch «локально ↔ облако» без потери данных.
• Несколько участников делятся своими решениями: Kasm + Ollama, Open WebUI, MLX-электрон-приложение, Synology-NAS-контейнеры, браузерный LLM без установки.