Hacker News Digest

wikigrapher — поиск кратчайших путей между статьями Википедии.

Меню: пути, страницы, редиректы, категории, сироты. Вход.

Дамп en-wiki 20.08.2025

• узлы: 7 043 985 страниц, 11 563 911 редиректов, 2 550 366 категорий, 27 427 сирот
• связи: 691 392 572 ссылок, 11 535 980 редиректов, 44 331 587 принадлежностей

Инструменты

• граф: пропустить, лимит, иерархия, направления UD/DU/LR/RL
• солверы: barnesHut, hierarchicalRepulsion, forceAtlas2Based
• действия: случайный, скачать, очистить

API & мониторинг

swagger-ui • eureka • tracer • dashboards • grafana

wikigrapher v0.0.1-alpha | dev | github | кофе

• Пользователи удивлены количеством и неожиданностью путей между статьями (Tetris → Family Guy → Tour de France).
• Предложено исключать ссылки из категорий/наград, чтобы показывать более «интересные» связи.
• Отмечены баги: «Love → Kissinger» не находится, «Sogdia → Teotihuacan» не отображается.
• Несколько человек поделились альтернативами: thewikigame.com, wikiwalk.app, wikijumps.com, txtai-векторный граф.
• Популярные пожелания: весить рёбра по расположению ссылки, показывать контекст абзаца, фильтровать «общие» узлы.
• Сайт временно лежит («hugged to death» / Cloudflare 502).

Двухуровневая модель

Основной агент ведёт диалог, помнит контекст, раздаёт задачи.
Под-агенты — чистые функции: получили вход, вернули результат, забыли всё.
Больше двух уровней — лишние точки отказа.

Под-агенты без состояния

Каждый вызов — как вызов функции:

• одинаковый вход → одинаковый выход
• легко кешировать, тестировать, запускать параллельно
  Пример сообщения:

{"task": "sentiment", "data": [...], "constraints": {"timeout": 5}}

Разбиение задач

• Вертикальное: последовательные шаги (сбор → извлечение → сравнение).
• Горизонтальное: параллельные ветки (исследовать 5 конкурентов одновременно).
  Смешиваем: сначала параллельная категоризация фидбека, потом последовательная приоритизация.

Протокол общения

Каждая команда содержит:

• цель, входные данные, ограничения, формат вывода.
  Ответ: status, result, confidence, processing_time.
  Болтовни и «помни, что мы обсуждали» — нет.

Специализация агентов

• Research — поиск по базе фидбека.
• Analysis — извлечение тем и настроений.
• Summary — генерация отчётов и changelog.
  Один агент = одна чёткая функция.

Оркестрация

• Round-robin — когда порядок важен.
• Priority queue — сначала критичные фидбеки.
• Fan-out/fan-in — параллельные под-агенты, потом сбор результатов.
  Состояние хранит только основной агент; под-агенты не знают о существовании друг друга.

Управление контекстом

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

Обработка ошибок

• Повторы с экспоненциальной задержкой (до 3 раз).
• Fallback-агенты: если «анализатор» упал, включаем «резервный».
• Circuit breaker: после N ошибок отключаем агента и пишем алерт.

Производительность

• Кешируем по хешу запроса.
• Параллельные вызовы без блокировок.
• Пакетная обработка: отправляем 50 фидбеков за раз, а не по одному.

Мониторинг

Отслеживаем:

• latency под-агентов,
• точность (сравниваем с разметкой),
• частота ошибок,
• объём контекста (токенов).
  Всё пишем в Prometheus + Grafana.

Уроки из продакшена

• Начинайте с 2–3 под-агентов, добавляйте постепенно.
• Пишите юнит-тесты для каждого под-агента.
• Не давайте агентам доступ к внешним API без rate-limit.
• Держите промпты в git; версионируйте как код.

Принципы

1. Простота > масштаб.
2. Чистые функции > разделяемое состояние.
3. Структурированные сообщения > свободный текст.
4. Мониторинг с первого дня > дебаг в проде.

Частые ошибки

• «Умные» под-агенты с памятью → гонки и непредсказуемость.
• Слишком большой контекст → таймауты и лишние токены.
• Отсутствие таймаутов → зависшие цепочки.
• Игнорирование кеширования → лишние $$$ на API.

Как начать

1. Определите 1–2 ключевые задачи (например, «суммаризировать фидбек»).
2. Создайте под-агентов: research, summarize.
3. Напишите структурированные схемы входа/выхода.
4. Покройте тестами, добавьте метрики.
5. Подключите к реальному потоку данных и наблюдайте.

• Автор делится опытом построения практичных «агентов» как чистых функций без состояния и истории разговоров, что экономит токены и упрощает отладку.
• Поддержка: дешёвые/локальные модели на 75 % задач, жёсткое разбиение на под-агентов, явное описание шагов вместо «умных» решений.
• Критика: часть читателей считает описанное не настоящим агентством, а обычным workflow с LLM-вызовами; стиль текста вызывает раздражение как «AI-generated».
• Практические инструменты: Claude Code (файлы .claude/agents), AWS Lambda + Step Functions, Spring AI, кеширование промптов.
• Сообщество обсуждает, где грань между «агентом» и «инструментом», просит примеров и данных, а также делится ссылкой на оригинальный пост Anthropic.

• Цель: создать единый фреймворк для тестов производительности Ollama на двух конфигурациях:

  1. настольная материнка (1×CPU, 1×GPU, 128 ГБ ОЗУ);
  2. кластер из 4 узлов (по 64 ГБ ОЗУ, 1×GPU, 10 GbE).

• Методика

  • Одинаковые образы Docker/Podman на обеих платформах.
  • Набор моделей: llama3.1:8b, codellama:13b, mistral:7b, qwen2.5:32b.
  • Метрики: t/s, TTFT, TPS, Watts, $/1k токенов.
  • Повторять 3×, усреднять, выводить ±σ.

• Автоматизация

  • Ansible-playbook разворачивает Ollama, node-exporter, prometheus, grafana.
  • Скрипт run-suite.sh последовательно запускает каждую модель с 512, 2 048, 4 096 токенов ввода/вывода.
  • Результаты пишутся в CSV и публикуются в PR как results-<platform>-<date>.md.

• Сравнение

  • Построить графики «токен/с vs. Watts» и «$/1k токенов vs. модель».
  • Выделить break-even точку, где кластер начинает выигрывать по стоимости при одновременной обработке ≥3 моделей.

• AMD Framework Desktop (AI Max+ 395) показывает 2,5–3× прирост к RTX 4000 SFF Ada 20 ГБ, но уступает 9950X из-за низкого TDP.
• Для локального запуска LLM рекомендуют RTX 3090 (24 ГБ) как лучшее ценовое решение, либо Apple/AMD при необходимости >20 ГБ памяти.
• ROCm и Linux-стек работают стабильно, но потенциал iGPU/NPU ещё не раскрыт; тесты велись в llama.cpp.
• Для масштабирования предлагают distributed-llama, Exo и llama.cpp-RPC, а также Oculink/eGPU-конфигурации.
• Продукт выглядит нишевым: ML-инференс дома, но для «обычных» задач лучше Threadripper или сервер.