Hacker News Digest

## Простой 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.

WebLibre — независимый браузер на базе Gecko и Mozilla Android Components. Поддерживает мобильные расширения Firefox и ориентирован на приватность.

⚠️ Альфа-версия: возможны баги и частые обновления. Сообщайте о проблемах на GitHub.
Без зависимостей Google только в сборке F-Droid.

• WebLibre — ещё один Firefox-форк под Android, добавляется к Iceraven, Fennec, Waterfox и др.
• Отличается: Tor-вкладки, мульти-аккаунт-контейнеры, локальная AI-модель, но UI почти не похож на Firefox.
• Подводные камни: в релизах проприетарные Google Play Services, нельзя выключить Google Safe Browsing, нет кастомных поисковых URL.
• Финансирование неясно; проект за одним немцем, что вызывает вопросы устойчивости и доверия.
• Участники сомневаются: «надо ли ещё одно “приватное” приложение, когда и так полно форков?»

Гибкое ПО поглотит SaaS

Победителями эпохи ИИ станут не те инструменты, к которым привыкаешь ты, а те, что подстраиваются под тебя.

Linear — красивый, но жёсткий: ИИ может лишь ускорить рутину, но не изменить процесс.
Fibery — сложный, но гибкий: ИИ превращает недели настройки в несколько запросов. Когда «как» исчезает, побеждает «что».

От решения к проблеме

Раньше: описал задачу → сам собрал решение.
Сейчас: описал задачу → ИИ собрал решение. Барьер входа упал, прототип готов за минуты.

Почему гибкое ПО выиграет

До ИИ кастомизация была уделом гиков. Простые вертикальные продукты побеждали, потому что «как» было дорого.
Когда «как» стало дешёвым, нет смысла мириться с чужим процессом. Нужно изменить инструмент — ИИ подстроит его за минуты.

Траектория

• 2025–2027 ИИ сглаживает крутые кривые обучения; миграции ускоряются.
• 2028–2030 Вопрос покупателя: «Насколько легко изменить потом?» Жёсткие инструменты теряют позиции.
• 2030–2035 Настройка = диалог; большинство вертикальных SaaS становятся нишевыми.

Жёсткие решения не исчезнут полностью, но большинству достаточно ПО, которое гнётся, но не ломается.

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

Кратко: автор высмеивает идею «поставь себе счётчик, и машина поедет быстрее» — когда проблему многозадачности и выгорания сваливают на самого работника.

Почему мы тут оказались:

• Люди «тормозят» не из-за личной рассеянности, а потому что им одновременно вбросили кучу нерасставленных по приоритету задач.
• Руководство поощряет реакцию на каждый пинг вместо сосредоточенной работы, а потом удивляется, что все вымотаны.
• Статьи вроде «просто не отвлекайся» — это перекладывание вины: «ты сам виноват, что система сломана».

Инструменты:

• Trello, Asana и им подобные — не инструменты производства, а инструменты отчётности, переложенные на подчинённых.
• Настоящие инструменты (git, CI, IDE) — без них работа встает; без доски задач — нет.

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

• Менеджеры не могут расставить приоритеты, поэтому команда прыгает между задачами без фокуса.
• Постоянные «срочные» фичи ставятся выше качества и стабильности, разрушая архитектуру и мотивацию разработчиков.
• Инструменты вроде Jira превращаются в цель сами по себе, убивая продуктивность и душу команды.
• Недоверие и неуверенность руководства порождают микроменеджмент и бесконечные проверки «а точно ли ты занят тем, что нужно?».
• Когда ценят отчёты больше, чем результат, страдают и продукт, и карьеры разработчиков.

Therac-25: катастрофа, о которой должен знать каждый разработчик

21 марта 1986 г. в онкоцентре Восточного Техаса оператор установила пациента под 25-мегаэлектронвольтный пучок Therac-25. После лазерной привязки она повернула поворотный столик в положение «электронный режим», ввела параметры и нажала «Ввод». Машина выдала ошибку «MALFUNCTION 54» и остановилась. Оператор, привыкшая к частым глюкам, нажала «П» (продолжить) — стандартный шаг в инструкции.

Через секунды пациент вскрикнул: «Вы меня сожжёте!» Он получил дозу в сотни раз выше нормы, эквивалентную взрыву гранаты в теле. Через 21 день он умер от радиационных ожогов.

За 18 месяцев случилось ещё пять подобных инцидентов: трое погибли, двое получили тяжелейшие травмы. Причина — баг в коде: гонка между потоками ввода и механическим поворотом столика. Если оператор успевала изменить параметры до окончания поворота, программа «забывала» установить ограничитель и выдавала 25 МэВ электронов вместо 200 кэВ рентгеновского излучения.

Компания-изготовитель AECL отрицала проблему, пока не столкнулась с неопровержимыми доказательствами. Расследование показало:

• отсутствие независимого контроля безопасности;
• игнорирование жалоб;
• инструкции, учившие игнорировать ошибки.

Therac-25 стал учебным примером: безопасность должна быть встроена, а не добавлена «потом».

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

• Учёный из Climate & Development Lab Брауновского университета опубликовал отчёт, в котором показал: антиветровые организации финансируются нефтяной индустрией и связаны с юридическими фирмами, лоббирующими интересы ископаемого топлива.
• Эти группы распространяют дезинформацию, чтобы замедлить развитие дешёвой морской ветроэнергетики и сохранить зависимость США от нефти и газа.
• После публикации исследования учёного начали преследовать: нефтяные структуры пытаются заглушить критику и помешать дальнейшим расследованиям.

• Участники обсуждают, что нефтяные компании финансируют «общественные» группы, чтобы саботировать ветроэнергетику через суды и пропаганду.
• Приводятся аргументы противников ветряков: «портит вид», «убивает птиц», «шум», «нестабильная сеть»; многие считают их надуманными.
• Сторонники ветра отвечают: ущерб природе временный и обратимый, а после демонтажа землю можно вернуть экосистеме.
• Упоминаются примеры Дании, Германии, штатов США, где ветер уже даёт 30-50 % электроэнергии без коллапса сети.
• Участники сетуют на NIMBY-отношение, лоббизм и то, что «кризис» выгоднее политикам, чем реальное решение.

Краткий путь в геймдев

1. Делай игры.
   Не жди вакансий — пили прототипы, моды, демо. Любой код, который запускается, уже плюс в карму.

2. Показывай.
   Заливай на GitHub, пиши посты, записывай гифки. HR ищут не диплом, а живые примеры.

3. Учись у сообщества.
   Discord, Reddit, форумы. Задавай вопросы, ревьюь чужой код, участвуй в джемах.

4. Специализируйся.
   Выбери узкое: AI, рендер, сетевой код. Глубина ценится выше широты.

5. Отправляйся в инди.
   Маленькие студии берут джунов без опыта, если видят портфолио. Зарплата ниже, но опыт растёт быстро.

6. Не сдавайся.
   Отказов будет много. Каждый «нет» — шанс улучшить портфолио и попробовать снова.

Формула: игра в релизе > тестовое задание > резюме.

• Войти в индустрию сейчас проще технически, но сложнее выделиться: рынок переполнен, зарплаты и студии сокращаются, особенно в США.
• Работодатели требуют показать небольшие законченные проекты (от «Виселицы» до «Тетриса») и подтвердить навыки онлайн-вниманием.
• Специализация в дефицитных нишах (физика, рендер, движки) повышает шансы, как и платформы вроде Roblox с готовой аудиторией.
• Корпоративная разработка игр требует «рабского» ритма; многие советуют остаться инди или вообще не лезть в AAA.
• ИИ и «holodeck-генераторы» пока вызывают споры: кто-то видит конец профессии, кто-то — лишь новый инструмент.

Неприятные вопросы о верификации Android-разработчиков

Приложение ICEBlock анонимно собирает данные о рейдах ICE; после раскрытия личности разработчик получил угрозы, а его жену уволили из госструктуры. Это показывает, что анонимность бывает жизненно важна.

Вопросы к Google по новой программе верификации разработчиков:

1. Анонимные разработчики
   Как быть автору гипотетического Android-аналога ICEBlock («ICE Scream»), который по опыту ICEBlock вынужден скрывать личность?

2. Экспертиза гражданского общества
   С какими организациями (EFF, AccessNow и др.) Google консультировалась и какие изменения внесены?

3. Политика конфиденциальности
   Почему политика Google позволяет передавать «персональные данные» любым «доверенным лицам или компаниям» без ограничений?

4. Отладочные ключи
   С 2027 г. для разработки нужны debug-keystore, но они не входят в процесс верификации. Как тестировать на сертифицированных устройствах?

5. Дублирующиеся package-name
   В обучающих целях часто используют одинаковые package-name, но они запрещены. Как запускать примеры из книг и курсов?

Есть вопросы — заполните форму или пишите:

• гражданским организациям: dev.verification@commonsware.com
• самой Google: did.you.really.need.a.written.invitation@commonsware.com

• Участники резко критикуют Google за введение обязательной верификации разработчиков для сайдлоада, называя это «фашистским контролем», отказом от идеи открытого Android и шагом к полному закрытию экосистемы.
• Поднимается вопрос права собственности: «ты покупаешь устройство, но фактически арендуешь его у OEM», сравнения с запретом ставить любые шины на купленную машину.
• Люди боятся цепочки «сначала телефон, потом ПК», приводят примеры macOS Gatekeeper и даже ограничения мощности VW по подписке.
• Некоторые уже ищут выходы: LineageOS, PostmarketOS, «де-гугловские» китайские OEM, но признают проблемы с драйверами, SafetyNet и банковскими приложениями.
• Сторонники отмечают, что анонимная разработка важна для журналистов, активистов и просто безопасности разработчика, а требование раскрывать личность — удар по свободе ПО.

Привет, я Прафул.
к статьям

• Участники обсуждают, как ИИ-ассистенты меняют ритм и удовольствие от программирования: скорость растёт, но нагрузка становится выше и «музыкальный флоу» исчезает.
• Одни считают, что промпт-редактирование и постоянный code-review утомляют сильнее, чем обычная печать кода.
• Другие всё ещё слушают музыку, но подбирают жанры без слов или «фоновый шум», чтобы не мешать глубокому мышлению.
• Кто-то отказывается от ИИ в личных проектах, сохраняя «кодинг для удовольствия», а на работе использует LLM как инструмент.
• Общий вывод: ИИ ускоряет доставку, но требует нового уровня концентрации и пересматривает привычные ритуалы программиста.

• Счёт (32 стр.)
• Генераторы целых (24 стр.)
• Экзотические операторы (40 стр.)
• Ограничения (19 стр.)
• Деревья (39 стр.)
• Графы (41 стр.)

---

Комментарии

• Joe Celko: деление использую часто для анализа «корзин» продаж.
• Михаил: спасибо за книгу! В ссылке на 2-ю главу лишняя «f».
• AntC: UNION CORRESPONDING = внутреннее объединение реляционной алгебры, обратное Nat Join.
• Vadim: UNION CORRESPONDING не знал — спасибо!
• Dave: в примере из главы 1 скалярный подзапрос возвращает 0, хотя должен быть предшественник.

• Старые приёмы уступают место ROW_NUMBER() и CTE, убирая декартово произведение.
• Кто-то советует думать о структуре данных, а не о SQL, другие считают это плохим советом: производительность требует учёта конкретного диалекта и индексов.
• DISTINCT часто воспринимается как «запах кода» — его злоупотребляют вместо правильных JOIN-ов.
• SQL всё же красив и компактен, особенно с макросами, но его «декларативность» не освобождает от понимания плана запроса.
• Разные СУБД имеют синтаксические нюансы (Oracle vs ANSI), что усложняет переносимость.