Искусственный интеллект

Мы уже устали от потока статей на тему "ИИ или статистический попугай?". Но тема "возможно ли сознание в машине?" не перестаёт быть одной из самых важных для человечества по состоянию на сегодня, май 2026 года.

Представляю перевод одной из наиболее интересных работ на эту тему. Дэвид Дж. Чалмерс, австралийский философ, профессор, специализирующийся в области философии сознания (и один из наиболее известных учёных, сосредоточенных на проблеме сознания), на конференции 28 ноября 2022 года прочитал доклад о том, как же всё-таки попытаться найти способ "измерения сознания" у LLM?

Это перевод первой из цикла 3 статей Дэвида Чалмерса о возможности сознания (и возможности его измерения/обнаружения) у LLM. Автор излагает свои мысли и аргументы простым и понятным языком, чтение его работ позволит вам совершить увлекательное и познавательное путешествие по сложными вопросам сознания...

“А давайте все с помощью ИИ разрабатывать” - эту фразу в разных вариациях я слышу во многих командах разработчиков. И вижу огромное количество попыток заставить программистов использовать ИИ. Как правило в результате получается одно из двух:

За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?

Две недели мы пытались обогнать собственную базу. Файнтюном. Потом ещё раз файнтюном на переделанном корпусе. Потом — RAG. Все три раунда база выиграла.

Это статья про отрицательный результат. Я считаю, он полезнее победы — потому что воспроизводимый и объясняет, какой инструмент под какую задачу. Дальше — цифры, стек и три разбора «почему не взлетело».

500 гипотез за 3.5 месяца. 470 — мусор. 30 — правда, которую я не хотел знать. Например: я по 4 часа «анализирую новости», а по факту — избегаю одного телефонного звонка.

Система находит паттерны поведения, которые ты не видишь, потому что находишься внутри них. 10 аттракторов, корреляции метрик, AGENTS.md и открытый код на GitHub.

Перед вами то самое руководство, которое можно прочитать самому или скормить ИИ, а он проведет вас за ручку. Всё: от npm install до CI/CD в продакшене, с готовыми конфигами, мнениями и паттернами.

На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Сегодня разбираем самое больное место разработки ИИ-агентов — как доказать, что они реально умнеют, а не просто пускают пыль в глаза.

В статье я покажу изнанку нашей системы оценки: — Как 10 000 живых переписок превратились в эталоны для тестов. — Почему стандартные метрики безжалостно валили нашего агента (и зачем нам понадобился Венгерский алгоритм из 1955 года). — И что делать, если метрика падает просто потому, что ИИ оказался умнее вашего устаревшего эталона!

Читайте полный разбор с цифрами, кейсами и откровенными провалами…

Современные VLA-модели (RT-2, π0, Helix) научились впечатляюще двигать роботом, но не понимают, что он держит. Помидор для них — кластер пикселей, статистически связанный с типичной траекторией хвата, а не сущность со свойствами. Поэтому они сыпятся на краевых случаях: подгнивший бок, нестандартное освещение, незнакомый объект. Наращивание датасетов и тактильных сенсоров лечит симптомы, но не причину — у архитектуры просто нет уровня, на котором объект существовал бы как объект. Следующий шаг — агенты с внутренней моделью мира и метаболическим контуром, где неправильное действие имеет реальную стоимость для самого агента, а не штраф в loss-функции.

На странице finalspark.com/live висят четыре снимка. На каждом — чип, к которому подключено четыре круглых комочке человеческой нервной ткани: каждый около полумиллиметра в диаметре, по десять тысяч нейронов внутри. Комочки лежат на электродах в круглосуточном инкубаторе в швейцарском Веве, и любой исследователь, подключенный к платформе, может через Python-API послать в эти электроды сигнал и прочитать отклик.

Делает все это компания FinalSpark, и на главной странице ее сайта написано: «Биокомпьютинг — следующий эволюционный скачок ИИ» и «В миллион раз меньше энергии».

За маркетинговыми формулировками стоит публикация в рецензируемом журнале, около пяти лет инженерной работы, открытая база данных на тридцать с лишним терабайт нейронных записей и несколько университетов, которые ведут на платформе свои эксперименты. Внутри проекта одновременно идет реальная работа и звучат громкие обещания, а отделить одно от другого — самая интересная часть этой истории.

О том, что для нас есть большая разница между «заучить материал» и «натренировать мышечную память = обзавестись навыком» знают все. Каждый проходил это, ощущал это.

В этой статье я подниму вопрос, почему вайб-кодинг буксует, что же мир и ИИ-сообщество делает не так. Я покажу, в каких компонентах LLM запрятана та самая декларативная и процедурная память. Да - она есть в LLM, и в конце статьи есть ссылки на общеизвестные исследования, которые это эмпирически подтверждают.

И да, тут есть что-то полезное «на подумать». Я предложу путь / алгоритм, как собрать нужный датасет и научить LLM не просто «воспроизводить программный код», а привить навык «разработки программного обеспечения», хотя бы в базовом виде.

Локально запустить LLM сегодня можно за десять минут — например, с помощью LM Studio. Но как только модели нужно дать доступ команде, подключить RAG или встроить ее в сервис — такого подхода зачастую недостаточно.

В этой статье мы разберем, как развернуть LLM на сервере, какие ресурсы для этого понадобятся и с какими сложностями можно столкнуться.

В течение последних двух лет мы проделали большую работу по изданию неустаревающих книг, связанных с проектированием и развитием API. Как известно, сам вопрос «Что такое API?» довольно многогранен, и в своё время на Хабре развёрнутый ответ на него дала одна из наших топовых авторов Ольга Назина @Molechka — к настоящему моменту её статья собрала почти 1 350 000 просмотров и 1555 закладок. Книги Ольги Назиной не относятся к этой статье напрямую, но, если вы их ещё не читали, рекомендуем посмотреть все четыре. Будем исходить из того, что API — это предоставляемый программой интерфейс‑контракт, в котором заложены правила взаимодействия с ней, в частности, форматы принимаемых и выдаваемых данных. Нашим главным бестселлером в этой области является книга «Проектирование архитектуры API: Как правильно проектировать, развивать и эксплуатировать API» (вышла на русском языке в июне 2024 года), написанная великим Джеймсом Гофом в соавторстве с Дэниэлом Брайантом и Мэтью Оберном, а также ещё три крутые книги:

— «API как искусство: разработка, поддержка, интеграция» Сергея Константинова (вышла в мае 2024 года)
— «Архитектура бэкенда. API для надежных корпоративных приложений» Владислава Светлакова (вышла в августе 2025 года)
— «Web API. Сборник рецептов: Повысьте уровень JavaScript‑приложений» Джо Аттарди (вышла в сентябре 2025 года).

На этой в продаже появилась следующая книга, наполняющая эту нишу: «Прикладные API для искусственного интеллекта и Data Science» Райана Дэя — оригинал вышел в издательстве «O'Reilly“ в апреле 2025 года. Эта весьма оригинальная книга исследует работу с библиотеками Python и в качестве сквозного проекта рассматривает фэнтези‑футбол. Для нас это первый опыт издания книги с серьёзным включением FastAPI, но в перспективе мы не теряем надежд издать и исходно русскоязычную книгу об этом фреймворке.

В условиях жесткой конкуренции на рынке отделочных материалов любому магазину жизненно необходимо хоть какое-то осязаемое преимущество. Стандартными каталогами и скидками уже никого не удивить. Так у нас родилась идея: сделать онлайн-примерочную обоев. Кажется, звучит как киллер-фича — дать клиенту возможность до покупки увидеть, как конкретный паттерн будет смотреться в его реальном интерьере.

На тот момент на рынке вовсю хайповали генеративные модели (такие как «Nano Banana»). На первый взгляд казалось, что проблема решается в два клика. План был надежен, как швейцарские часы: получить API-ключ, отправить по эндпоинту фотографию интерьера и текстуру обоев, сопроводить это правильным промптом (с указанием учитывать перспективу, освещение и масштаб) и забирать готовый результат.

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

Существует множество известных RAG-фреймворков, проверенных на многочисленных бенчмарках, так что точность работы системы в наших реалиях не такая большая проблема. Однако, для любого, кто сталкивался с прикладной интеграцией RAG в рабочие пайплайны, не секрет, что рано или поздно сталкиваешься с постобработкой форматов, отличных от текста. Комбинируешь OCR, парсеры, ридеры…

RAG-Anything устраняет ненужные телодвижения.

С помощью RAG Anything возможно обрабатывать подавляющее большинство ходовых форматов файлов(PDF, DOC, PPTX, XLS, JPG, BMP, GIF и др. )

В этой статье мы разберем механизм работы фреймворка и на примере посмотрим, как он работает.

Пока инфо-бизнесмены продают очередные курсы по промпт-инжинирингу, в индустрии пересобирают саму архитектуру ИИ-систем. Главные вызовы сегодня лежат в плоскости ML-инфраструктуры: как запустить автономных агентов на проде, снизить latency и не обанкротиться на обучении моделей с нуля. 

В майском выпуске разбираем свежие архитектурные подходы, новое железо и софт, которые меняют экономику современных нейросетей.

SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou всё активнее строят вокруг корпоративного ИИ семантические слои: knowledge graph, ontology, process intelligence, business data cloud, agent memory и агентные платформы.

Зачем им это, если языковая модель уже умеет читать документы, таблицы и API?

Потому что корпоративному ИИ нужен не только доступ к данным. Ему нужен смысловой слой предприятия: термины, объекты, экземпляры, статусы, источники, связи и правила качества.

Именно здесь начинается переход от отдельных ИИ-функций к системам, которые способны собирать комплексную управленческую позицию для действия.

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

На практике такие проекты часто не дают устойчивого результата. Модель может корректно генерировать текст, демонстрации выглядят убедительно, но в реальной работе ответы оказываются нестабильными, противоречивыми и не связанными с внутренними стандартами компании.

Основная причина — отсутствие единого слоя знаний.

В проекте для ресторанной группы с 10+ заведениями и историей более 15 лет мы сознательно начали не с агентов и не с интерфейсов, а с построения корпоративной RAG-инфраструктуры. Этот слой стал основой всей последующей AI-архитектуры.

TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск — потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса.

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

Всё работает настолько хорошо, что я даже задумался: а не запустить ли новый проект вообще без моего участия? Описать только PRD, проверить сгенерированную документацию и список задач, а на выходе просто принимать готовые фичи. Я даже пробовал запускать так несколько личных проектов (один из них — простенькая игра): формировал всю документацию через ИИ, но на определенных этапах допускал ошибки в планировании и в итоге терял контроль.

Эта статья про мои эксперименты с языковыми моделями, в которых не используется машинное обучение и аппаратное ускорение. Чтобы избежать недопонимания поясню, что я имею ввиду под языковой моделью (ЯМ).

ЯМ это совокупность алгоритмов, структур данных и собственно данных для генерации связного текста в ответ на запрос. Каким образом ЯМ генерирует ответы определяется способом её реализации. В канонической реализации ЯМ используются методы машинного обучения и мощные аппаратные ускорители. В моей реализации ЯМ я хочу получать связный текст в ответ на запрос без машинного обучения и без аппаратного ускорения.

Если свериться с Википедией на английском и на русском языках, или с многочисленными публикациями про (Large/Small) Language Models, то мои определение и понимание… несколько неканонические. Поскольку я экспериментирую для себя (я сам себе работодатель), то заранее соглашусь с любыми мнениями о неканоничности моего определения ЯМ.

Буду благодарен комментариям - если окажется, что подобное изложенному в этой статье уже было на просторах интернета. Как минимум такие подсказки избавят меня от хождения по тупикам. А как максимум, я надеюсь, позволят сделать мои дальнейшие эксперименты более успешными.

Последующий текст состоит из нескольких небольших частей. Сначала расскажу о своих мыслях, из которых возникли мои идеи для экспериментов. Далее, о своём текущем подходе к реализации ЯМ. Пока он совсем прост. Чем-то напоминает классический подходы Markov chains и n-grams, но без статистических и вероятностных методов.

В прошлых статьях я писал про то, что нейросеть ускоряет конвейер, но не несёт ответственности. Что лояльность дирижёра — единственный мультипликатор. Что уравнение мотивации сломалось.

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

И недавно появились прямые доказательства, что это случайность и не галлюцинация, а математика моделей.