Hacker News Digest

Parallel Search API — это веб-инструмент поиска, созданный специально для ИИ-агентов, а не для людей. В отличие от традиционных поисковых систем, оптимизированных для кликов и навигации, Parallel фокусируется на семантических целях, релевантности токенов, информационно-плотных выдержках и однократном разрешении запросов. Это позволяет предоставлять наиболее релевантные веб-данные эффективнее, чем стандартные API поиска.

Согласно тестам, Parallel значительно превосходит существующие API по точности, особенно для сложных многошаговых запросов. На тесте BrowseComp он достигает 48% точности против 1% у GPT-4. Система снижает количество необходимых запросов, уменьшая задержки, стоимость и повышая точность за счет предоставления более информационно-плотных токенов за один вызов. Это позволяет ИИ-агентам выполнять задачи эффективнее с меньшим количеством циклов и общей стоимостью.

• Пользователи обсуждают, что API-интерфейс Parallel AI предлагает 20 000 бесплатных запросов, но при попытке воспользоваться ими баланс оказывается недостаточным, что вызывает раздражение.
• Участники спора оценивают, что ценообразование и условия использования сервиса не прозрачны, и что это может быть нечестным маркетингом.
• Некоторые комментаторы поднимают вопрос о том, что, возможно, Parallel AI не предоставляет действительно уникальную ценность, поскольку они просто используют модель, которая может быть запущена локально.
• Обсуждается, что будущее поиска может лежать в агентных системах, но при этом важно, чтобы API был доступен и не требовал бы дорогих вычислений.
• Участники также обсуждают, что важно, чтобы API был доступен и не требовал бы дорогих вычислений, и что будущее поиска может лежать в агентных системах.

В статье предлагается первое конкретное определение AGI, соответствующее когнитической универсальности и компетентности хорошо образованного взрослого человека. Авторы основали свою методологию на теории Кэттелла-Хорна-Карролла, наиболее эмпирически проверенной модели человеческого познания, разбив общую интеллект на десять когнитивных доменов, включая рассуждение, память и восприятие. Применение этого подхода показало "зубчатый" когнитивный профиль современных моделей, где текущие ИИ-системы, несмотря на proficiency в знаниемких областях, имеют критические недостатки в базовом когнитивном аппарате, особенно в долговременном хранении памяти.

Представленные AGI-оценки количественно определяют как прогресс, так и оставшийся разрыв до достижения AGI: GPT-4 получил 27%, а GPT-5 - 58%. Эта метрика предлагает объективный способ измерения развития систем ИИ и выявления их сильных и слабых сторон, что может направить будущие исследования в области создания более сбалансированных и универсальных искусственных интеллектов.

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

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

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

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

Эксперимент показал, что формат данных существенно влияет на точность понимания таблиц LLM. Лучший результат показал Markdown-KV (key-value пары в markdown) с точностью 60,7%, но он потребовал в 2,7 раза больше токенов, чем самый экономный CSV. XML и INI также показали высокую точность (56% и 55,7%), тогда как CSV и JSONL оказались наихудшими — около 44%. Это указывает на возможность улучшения RAG-пайплайнов простой сменой формата данных, хотя эффективность часто требует компромисса с количеством токенов.

• Результаты тестирования GPT-4.1-nano показали, что точность извлечения данных из таблиц варьируется от 40% до 60% в зависимости от формата, при этом Markdown-KV показал наилучший результат.
• Многие участники раскритиковали методологию исследования, указав на использование только одной, слабой модели (GPT-4.1-nano) и недостаточный размер данных для оценки влияния контекстного окна.
• Было высказано сомнение в практической целесообразности использования LLM для обработки табличных данных, учитывая доступность более точных и эффективных традиционных инструментов (например, Python-скриптов, SQL).
• В качестве альтернативы предложены агентные подходы, где LLM генерирует код (например, SQL-запросы или функции) для последующего выполнения, что показало высокую эффективность в реальных задачах.
• Обсуждались потенциально более эффективные форматы данных (XML с короткими тегами, TOML, KSON) и необходимость тестирования на более мощных моделях (GPT-5, Claude, Gemini) для получения репрезентативных результатов.

SWE-Bench Pro — это новый бенчмарк для оценки способности ИИ-агентов решать сложные и долгосрочные задачи в разработке ПО. Он включает реальные проблемы из открытых репозиториев, требующие анализа кода, поиска ошибок, написания тестов и внесения изменений. Это шаг вперёд по сравнению с предыдущими тестами, так как фокусируется на многошаговых задачах, имитирующих реальную работу инженера.

Проект демонстрирует, что современные модели, такие как GPT-4, справляются лишь с частью заданий, подчёркивая пробелы в понимании контекста и планировании действий. Это указывает на необходимость дальнейшего улучшения агентов для автономной работы над сложными проектами. Практический вывод: хотя ИИ уже полезен в рутине, до полной автономии в разработке ещё далеко.

• Критика названия "SWE-Bench Pro" как потенциально нарушающего чужой товарный знак и вводящего в заблуждение относительно превосходства.
• Сомнения в эффективности защиты тестового набора копилфт-лицензией для предотвращения обучения на нём ИИ-моделей, учитывая игнорирование лицензий в индустрии.
• Вопросы к репрезентативности бенчмарка: отсутствие в тестировании самых современных и крупных моделей, доверие к приватному датасету и проблема "загрязнения" публичного.
• Обсуждение ключевых проблем бенчмарков для ИИ-кодеров: сложность создания "чистых" задач, которые модель не видела ранее, и уязвимость к "читтингу" через анализ скрытых частей репозитория.
• Замечание о стиле README репозитория (обилие эмодзи) как возможном признаке генерации LLM, что подрывает доверие.

Разработчик заметил постепенное ухудшение качества ответов языковых моделей Azure AI при использовании одинаковых промптов и тестовых диалогов с температурой 0 для воспроизводимости. После выхода GPT-5 точность GPT-4o-mini резко снизилась, а новые версии, такие как GPT-5-mini, оказались медленнее — ответы иногда генерируются до 20 секунд — и столь же неточными.

Подозревается, что Microsoft намеренно ухудшает старые модели, чтобы стимулировать переход на новые, хотя те не демонстрируют улучшений. Это ставит под угрозу проекты, требующие точности и стабильности, и вынуждает команду рассматривать альтернативы Azure.

• Участники обсуждают возможное скрытое ухудшение качества языковых моделей (LLM) со временем, в том числе из-за квантования и изменения системных промптов.
• Высказывается предположение, что восприятие ухудшения может быть связано с завышенными первоначальными ожиданиями и недетерминированным характером работы LLM.
• Отмечается отсутствие конкретных данных и примеров в исходном сообщении, что затрудняет объективную оценку claims.
• Подчеркивается важность фиксации версий моделей и проведения периодических бенчмарков для отслеживания изменений.
• Обсуждаются технические аспекты тестирования, такие как использование temperature=0 и детерминированность выводов.

Проблема: выбор наиболее подходящей LLM для каждого запроса при ограниченном бюджете.
Цель: максимизировать качество ответов, не превышая стоимость.

Метод:

• Роутер обучается на истории запросов и ценах моделей.
• Использует лёгкую модель-классификатор для быстрого предсказания «ценности» запроса.
• Динамически распределяет запросы между дорогими (высокое качество) и дешёвыми моделями.
• Алгоритм адаптируется к изменению бюджета в реальном времени.

Эксперименты:

• Датасет из 50k вопросов и 5 LLM (от GPT-3.5 до GPT-4).
• При бюджете −30 % от полной стоимости GPT-4 достигается 95 % её качества.
• Роутер срабатывает за 2 мс, не влияя на латентность.

Вывод: адаптивный роутинг позволяет экономить до 70 % затрат без значимой потери качества.

• GPT-4 стоит в 100 раз дороже Mixtral ($24,7 против $0,24/млн токенов), и даже при 20 % ошибок маршрутизации экономика всё равно выгодна.
• Главный спор — как измерять «performance»: технические метрики не всегда совпадают с удовлетворённостью пользователей.
• Авторы предлагают алгоритм PILOT (LinUCB-роутер с учётом предпочтений), но критики считают, что роутеры нужно тонко настраивать под конкретную нагрузку, иначе в проде работают хуже, чем в тестах.
• Часть участников считает тему «роутинг для экономии» слишком мелкой и не фронтиром: «AGI не скоро, зато дёшево».

Полная автономия AI-программистов невозможна в обозримом будущем.
Современные модели (GPT-4, Claude, GitHub Copilot) умеют генерировать фрагменты кода и даже мелкие приложения, но:

• не понимают контекст бизнес-логики и архитектуры;
• не способны к долгосрочному планированию, поэтому «забывают» требования через несколько шагов;
• не отвечают за последствия: безопасность, этика, юридические риски;
• требуют постоянного человеческого контроля при отладке, рефакторинге и интеграции.

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

• Участники спорят, «настоящий ли программист» ИИ: одни считают, что он лишь продвинутый калькулятор и требует человека-эксперта, другие уже полностью делегируют ему рутинные задачи.
• Ключевое разделение — между написанием кода и инженерией: спецификации, архитектура, тесты и бизнес-контекст пока остаются зоной человека.
• Многие отмечают «ленивость» моделей: ИИ охотно объявляет задачу решённой, хотя очевидны ошибки, и требует постоянного «нянькинга».
• Поддержка ИИ особенно ценна в незнакомых языках/фреймворках и для быстрого прототипирования, но масштабные legacy-кодовые базы и долгосрочное планирование ему не по зубам.
• Общий вывод: ИИ — мощный экзоскелет для разработчика, а не полноценная замена; уровень полезности зависит от размера задачи и умения человека формулировать запросы.

## Простой RAG с PageIndex

**Цель**  
Показать, как за 5 минут построить полноценный Retrieval-Augmented Generation пайплайн на базе PageIndex.

---

### 1. Установка и импорт

```bash
pip install pageindex openai

import pageindex, openai, os
openai.api_key = os.getenv("OPENAI_API_KEY")

---

2. Загрузка документов

Поддерживаются PDF, DOCX, TXT, MD, PPTX, CSV, JSON.

docs = pageindex.load_documents("data/")
index = pageindex.Index(name="my_docs")
index.add_documents(docs)

---

3. Поиск и генерация

query = "Какие преимущества RAG?"
chunks = index.search(query, top_k=3)

context = "\n".join(c.text for c in chunks)
prompt = f"Используй контекст:\n{context}\n\nВопрос: {query}"

answer = openai.ChatCompletion.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": prompt}]
).choices[0].message.content

print(answer)

---

4. Потоковый чат

chat = index.chat_session(model="gpt-4")
print(chat.ask("Сравни RAG и fine-tuning"))

---

5. Сохранение и переиспользование

index.save("my_docs.pidx")
# index = pageindex.Index.load("my_docs.pidx")

---

Советы

• Для больших объёмов используй batch_size=100.
• Повышай top_k при недостаточном контексте.
• Добавляй metadata={"source": "file.pdf"} для фильтрации.

Готово! Теперь у вас работает RAG без векторных БД и сложной инфраструктуры.

• Критики считают «vectorless RAG» переизобретением семантического чанкинга + иерархического поиска и сомневаются в масштабируемости.
• Основной минус — высокие затраты и латентность: каждый запрос требует прогона LLM по всем документам или их крупным фрагментам.
• Подход может подойти для малого корпуса или офлайн-задач (юрдоки, медкарты), но не для чатов «здесь и сейчас».
• Некоторые предлагают гибриды: ANN-вектора для быстрого отбора, затем LLM-переранжирование.
• Пропущены публичные бенчмарки; сравнение ограничено собственным датасетом MAFIN2.5.

%PDF-1.7
50 0 obj
<< /Length 2836 /Filter /FlateDecode >>
stream
…сжатый бинарный поток…
endstream
endobj

65 0 obj
<< /Length 2952 /Filter /FlateDecode >>
stream
…сжатый бинарный поток…
endstream
endobj

• GPT-5 показывает смешанные результаты: лучше справляется с фактами и рассуждениями, но хуже — со структурированными запросами, честностью и доказательной базой.
• Обычным пользователям, интересующимся здоровьем, важнее всего HeadQA, Medbullets, MedHallu и PubMedQA; при этом RAG-подходы могут быть полезнее «чистого» модельного ответа.
• Некоторые разработчики отмечают, что GPT-5 быстро решает сложные задачи, но «самоуправляется» и делает лишнее; другие считают улучшение минимальным и связывают это с экономией вычислений.
• Обсуждаются возможные причины регрессии: маршрутизатор экспертных моделей, ограничения на tool-calls и использование режима «medium» вместо «high» reasoning.

Когда ИИ захватил Hacker News?

В августе 2025-го каждая третья история в топ-10 HN про ИИ. Автор решил выяснить, когда это началось и как менялось отношение сообщества. Для анализа взял 24 910 топовых постов с 2019-го по 15 августа 2025-го через BigQuery-датасет HN.

Каждый пост и его комментарии прогнали через GPT-5-mini, чтобы получить:

• краткое содержание;
• факт упоминания ИИ;
• тон (позитив/нейтрал/негатив).

Ключевые выводы

• Пик хайпа — середина 2025-го; темп сохранится — рекорд.
• Первый скачок случился не с ChatGPT (Q3 2022), а с выходом GPT-4 (Q1 2023), когда разработчики получили доступ к мощной модели.
• Единственный заметный всплеск негатива — Q3 2021:
  – Apple анонсировала NeuralHash для сканирования CSAM на устройствах;
  – GitHub Copilot показал, что копирует чужой код.

Итого по 2816 ИИ-постам: 52 % позитив, 31 % негатив, 16 % нейтрал. Последние два квартала чуть негативнее, но тренда пока нет.

• На HN обсуждают, что тема ИИ полностью «захватила» ленту: до 9 из 10 топ-постов бывают про ИИ.
• Пользователи жалуются на навязчивость темы и хотят фильтров/игнора, чтобы скрывать ИИ-новости и комментарии.
• Некоторые сравнивают нынешний бум с криптой, NFT и Web3, которые тоже пиковали, а потом исчезли с главной.
• Отмечают, что даже в не-ИИ статьях комментарии сводятся к ИИ; критика тут же минусуется.
• Сомнения в адекватности оценки тональности: автор анализа использовал ChatGPT, который может завышать «позитив».

• Шутка — это неожиданный, но в ретроспективе очевидный поворот.
• Универсально смешного не существует: дети не хватает контекста, профи всё предугадывают.
• LLM обучены минимизировать сюрприз, предсказывая «среднее» мнение; смешного не выходит.
• Больше GPU не помогут: архитектура противоречит юмору.
• То же касается историй: если события предсказуемы — скучно; если не вытекают друг из друга — неправдоподобно.

• Автор статьи утверждает, что LLM плохи в шутках, потому что обучены минимизировать сюрприз; участники спорят, путая ли он «сюрприз» с «невероятностью».
• Некоторые считают, что дело не в модели, а в пост-обработке (safety, RLHF), которая гасит остроумие.
• Другие добавляют: юмор — это ещё доставка, контекст и ошибки мышления, а не просто текст.
• Примеры показывают, что более крупные модели (Gemini 2.5, GPT-4.5) уже умеют быть смешными, если их хорошо спросить.
• Вывод: проблема не в «запрете на сюрприз», а в сложности самого юмора и в текущих ограничениях систем.

• У OpenAI десятки миллиардов долларов на кластеры GPU (по $20–40 тыс. за карту) и инфраструктуру, чего нет у обычного пользователя.
• Ключевая «фишка» — массовое батчирование запросов: одновременная обработка тысяч пользователей позволяет загружать видеопамять и вычислительные блоки почти на 100 %, тогда как дома GPU простаивает.
• Используются Mixture-of-Experts, спекулятивное декодирование, конвейерная разбивка модели по GPU и прочие оптимизации, снижающие затраты на одного пользователя.
• Большинство пользователей активны лишь доли процента времени, поэтому общая нагрузка оказывается меньше, чем кажется по 700 млн «weekly users».
• Всё это — классический эффект экономии масштаба: высокие фиксированные затраты и почти нулевые переменные на одного юзера делают запуск GPT-4 локально невыгодным.