Как я пытался сжимать смыслы вместо байтов
Два часа ночи. Я пытаюсь впихнуть документацию проекта в контекст Claude. 847 страниц. Где-то 1.2 миллиона токенов. Контекстное окно — 200 тысяч.Делаю то, что делают все: режу, суммаризирую, выбрасываю «неважное». Каждый раз теряю что-то критичное. Это уже третий час, кофе кончился, и в голову приходит идея, которая кажется гениальной.Спойлер: она такой не была.
ИИ решил задачу Эрдёша — но есть нюанс
DeepMind прогнали своего агента Aletheia по 700 открытым задачам из списка Эрдёша. Результат: одна из них теперь закрыта — это вторая математическая проблема, решённая ИИ без участия человека. Теренс Тао уже обновил трекер.Но давайте на цифры. Агент вернул 212 «уверенных» ответов. После проверки людьми: — 137 (68,5%) — фундаментально ошибочны — 13 (6,5%) — реально решают то, что имел в виду ЭрдёшКаждый шестнадцатый. Остальное — галлюцинации или решение не той задачи.Авторы честно пишут: «Любой из этих вопросов мог бы легко решить нужный эксперт». Проблема не в сложности — до этих задач у людей просто не доходили руки 40 лет.
Пишем игру-головоломку под macOS на SwiftUI [StarDust Collector]
В прошлой статье я поделился опытом, как писал с помощью ИИ кастомный TO-DO-лист под macOS. Опыт оказался противоречивым, но приложение всё-таки получилось и даже работало.Поэтому я решил добавить немного фана и реализовать мечту любого программиста — написать собственную игру. Так как у меня уже появилось небольшое понимание экосистемы десктоп-приложений под macOS и SwiftUI, я решил использовать именно её.
Про GEO доказательно: +40% видимости в AI-выдаче, нейропоиске и ответах LLM-SGE (аналитика + стратегия)
Наконец, научное обоснование (или разоблачение?) про GEO/Generative Engine Optimization. Статья-этакий бенчмарк...)
За пределами LLM: детерминированный движок рассуждения на конечном алфавите
Часть 1. Детерминированный движок рассуждения на конечной таблице операции (в перспективе — замена LLM)Когда речь заходит о больших языковых моделях, все сразу отмечают их талант к сочинению и пересказу текстов. Но вот встроить такую модель в реальный продукт — задача куда более каверзная, чем кажется на первый взгляд. На практике вылезают три системных «подводных камня», из‑за которых работать с ними бывает откровенно неудобно.
Распространенные ошибки при создании приложений с генеративным ИИ
Поскольку мы все еще только осваиваем создание приложений с использованием базовых моделей, ошибки вполне нормальны. Это краткая заметка с примерами некоторых из наиболее распространенных ошибок, которые я видел как в публичных кейсах, так и в своем личном опыте.Эти ошибки являются распространенными, поэтому, если вы работали над каким-либо продуктом, связанным с ИИ, вы, вероятно, уже сталкивались с ними.1. Использовать генеративный ИИ там, где он не нужен
Алгоритмический тупик: почему платформы продвигают мусор, имея инструменты для его фильтрации
Мы живем в 2026 году, когда технологии позволяют оценить глубину и оригинальность текста, но крупные площадки по большей части все еще живут по старинке и судят о качестве по числу лайков и частоте публикаций. Отсюда мы наблюдаем фундаментальный системный сбой, который медленно убивает сложный технический контент.
LLM — это афера на доверии, которая длится 400 лет
В 1623 году немец Вильгельм Шиккард создал первые известные чертежи механического калькулятора. Спустя двадцать лет Блез Паскаль разработал машину улучшенной конструкции, чтобы помочь справляться с огромным количеством утомительных арифметических расчётов, необходимых в его работе сборщика налогов.Интерес к механическим вычислениям не ослабевал последующие века: поколения людей по всему миру продолжали дело Паскаля и Шиккарда, разделяя их убеждение, что перекладывание умственной нагрузки на машину принесёт облегчение.Аферу на доверии можно разбить на три этапа:начала выстраивается доверие;
Достаточно надёжный и научно обоснованный алгоритм проверки текста на LLM
Кажется, я изобрёл алгоритм, при помощи которого можно достаточно надёжно отличить авторский текст от LLM‑текста.
Как я пытался создать «конструктор налоговых проверок» для повышения эффективности работы ФНС
Для начала - немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм-канал и теперь работаю в налоговом консалтинге.Эта статья - история о том, как я попытался решить огромную проблему государственной системы с помощью домашнего ноутбука и нейросетей. О том, как я переоценил свои силы, недооценил масштаб задачи, но все-таки попробовал создать инструмент, который мог бы изменить работу инспектора.
