Будут хорошо читаться и строиться как LLM, так и SLM. В TOON, как и в json довольно большая полисемия, LLM будет по-любому путаться на больших контекстах.
В триггерной методике это всё не особо важно. Когда Вы собрали фиксированную конфигурацию установки со всеми кабелями, то дальше остается только калиброваться на относительно мощный сигнал и ловить временную корреляцию между опорным импульсом (например, импульс запуска лазера или выход синхроимпульса от него же) и импульсом сигнала на ФЭУ. Когда пойман пик корреляции - дальше уже дело техники и не самой сложной программной обработки. Судя по тому, что он не использовал специализированных корреляторов, а только не самый быстрый осциллограф, точность корреляции у него не лучше 1нс, это примерно 33 см пространственного разрешения. Судя по осциллограмме, импульс от ФЭУ длинный, с фронтом несколько десятков нс, добавляем еще порядок на быстродействие детектора. То есть явно будет значимое для пространственного разрешения блуждание импульса по времени, но это неважно, так как угловые координаты определяются зеркалом, и системе не надо точно определять расстояние, а только энергию. Для этой задачи высокая временная точность не нужна, надо только отстроиться по амплитуде от шумов и ловить по времени импульс сигнала от конкретного синхроимпульса. Это можно было бы сделать и на 100МГц осциллографе. Интереснее посмотреть на его циклограмму временных сдвигов для захвата всего кадра.
Еще пока писал, обнаружил пару неточностей:
Ни о какой частоте измерений 2ГГц речи нет, на скрине идет 2кГц, это типично для короткоимпульсного диодного лазера.
2ГГц полосы и 2гигасемпла - это всё-таки немного разные вещи.
График выглядит мохнатым из-за того, что-то результат наложения множества реализаций, без этого была бы кривулина как на следующей картинке.
Осциллограф на 2ГГц, если он действительно на 2ГГц - не обычный, а ОЧЕНЬ дорогой прибор.
Так всегда. Если у Вас эргодический процесс, то есть нет суровых нелинейностей с большими временами релаксации, то фотографируя с разным сдвигом разные реализации процесса, Вы можете восстановить общий ход течения процесса в динамике. Например, Кэкак рассеивается свет в веществе, как нагревается вещество, как проходит ударная волна и тд. Всё это потом можно сравнить с результатами симуляций и уточнить модель и теорию, ведь главный критерий истины - всё-таки эксперимент.
Так это надо правильно работать с контекстом. Давай агенту граф кода для обзора, использовать разметки, иметь документацию. Агенту очень важно не только что написано, но и почему, а также как код, с которым он работает, связан с остальным приложением. Тогда и код пропадать не будет. Хотя для Claude ещё нужны прям директивные промпты, лучше с xml разметкой, иначе он всё напутает.
Есть один существенный нюанс. Разработка с ИИ неплохо масштабируется, то есть можно делать массивные шаблонные задачи с минимальными трудозатратами. Создать десятки моделей из графа бд - легко. Тесты для десятков ручек - пожалуйста. Один раз написал промпт, запускаешь несколько раз. Эффективнее Ctrl+C/Ctrl+V.
Так с ИИ надо работать нормально. Выступать архитектором. Спроектировать архитектуру, исходя из понятых тобой бизнес-процессов, подобрать нужный стек, создать граф приложения, спеку на его создание, тестовые критерии, а потом уже генерировать код. Тут аналогия скорее не "строить дачу своими силами из подручных материалов", а "создать ТЗ, заказать по нему проект дома с КД, сметами и прочим, и отдать в работу строительной компании".
Вы по сути описали семантическую разметку кода, которая по современным практикам интегрируется напрямую в код, создавая для ИИ семантически богатый граф, по которому можно легко навигироваться и получать недостающий контекст, например цель кода, тестовые критерии и тд, напрямую из разметки, а не после анализа кода. Такой подход снижает потребление токенов, увеличивает надёжность разработки. ИИ уже не будет дропать код, так как он точно понимает его назначение и связи с другими частями приложения без дополнительного парсинга файлов проекта.
У меня тоже есть личный опыт использования ИИ. Я ИИ долго не пользовался, считая его игрушкой (на самом деле не умея с ним работать). Я не так давно пришёл на новое место работы: новая предметная область, новый язык, обширное легаси. Подумал, что надо подключить к этому ИИ. Сначала было сложно, он(я) тупил, давал нерелевантные результаты, кривой код и всё такое. Где-то месяц я мучился, потом нашёл человека, который в этом разбирается, и взял несколько уроков. Потом практика, практика и ещё раз практика. Я научился с ИИ эффективно решать все задачи цикла разработки: архитектурное моделирование, аналитику, проработку тз, генерацию кода (около 90%). Выросла ли моя производительность? — да, на порядок, а это значит, что я могу решить задачу быстрее, чем без ИИ, и заниматься своими делами. Хуже ли я знаю язык, чем узнал бы вручную? — да, но не критично. Много читаешь код, разбираешься в best practices, правишь мелочи, язык сам прилипает. Качество кода нормальное. А главное, меняется мышление. Становится более системным и аккуратным даже на маленьких задачах, иначе как ты объяснишь ИИ что делать?
Вы можете загнать одну и ту же задачу в разные модели параллельно на lmarena.ai и оценить их пригодность для своих задач. Мне вообще больше всего Gemini 2.5 Pro нравится.
Забавно, но за последнюю неделю встречал абсолютно противоположный вывод: БЯМ отлично отличают текст, написанный ИИ, от написанного человеком и, более того, выше всего оценивают текст, написанный этой же БЯМ.
Брать python:3.12-slim или python:3.12-alpine, но только если понимаешь, как с ним работать и для чего ты его выбираешь.
Отличная статья, спасибо. Хочу внести небольшое дополнение. По опыту для большинства python приложений достаточно slim образа + pyproject.toml. Если надо поставить какую-нибудь сложную библиотеку, типа pytorch, cupy или подобное - ищем образ от вендора, проиграешь по объёму, выиграешь по скорости развертывания и сэкономишь много нервных клеток. Alpine, конечно, намного компактнее, но там могут быть неожиданные проблемы с чем угодно: другой пакетный менеджер, свои версии системных зависимостей, нюансов много.
Полностью согласен с поговоркой про физиков. Сам физик, и после 6 лет занятий наукой я понял, что хочется чего-то более простого и денежного. В вебкам я не мог пойти по физическим соображениям, в закладки - по моральным, поэтому выбрал ИТ. Я неплохо знал питон и математику, но не представлял себе, что потребуется в индустрии. Походил по собесам, попробовался в яндекс как дата-сайентист, в другие места как разработчик, в итоге за три месяца нашел хорошее место, релевантное моему опыту. Рост зарплаты составил почти 4 раза относительно средней за последний год. Прекратились переработки, появилась финансовая стабильность, задачи проще, свободного времени больше. Что еще надо человеку?
У меня как раз был ранний EliteBook 14', и он был великолепен. Пользовался им около 7 лет, потом отдал родственникам, которые его года за 4 добили. Легкий, прочный, отличная клавиатура, хорошая производительность, IPS экран. Поменял только потому, что нужен был аппарат с ГПУ, и до сих пор вспоминаю его с ностальгией.
Ага, так что даже при использовании существующих математических пакетов приходится писать кучу кода под конкретную задачу. Причём он будет плюс-минус одинаковый вне зависимости от базового пакета: шаблоны, типы, костыли.
Я решал похожую задачу, правда, в квантовой теории поля, как раз с помощью Mathematica. Встроенная функция FullSimplify работает хорошо только с простыми выражениями. Если запихивать в неё какую-нибудь трехэтажную крякозябру, то надо заниматься тем же, чем уважаемый @Hemml занимался в своей работе: поиском шаблонов, рекурсивной подстановкой, указанием типов всех констант и переменных, оптимизацией к неподвижной точке и т.д. Да ещё и скорость всего этого добра оставляет желать лучшего. И синтаксис там ужасный :)
Я живу в одном из упомянутых домов МОСС-Тема. Не знаю, что насчёт конструктивных достоинств, но недостаток есть огромный: слышно соседей по горизонтали, по вертикали и по диагонали, передача звука через несущие конструкции отличная. Если прислушаться, то можно услышать как плачет ребёнок через этаж сверху и как играет живая музыка на 3 этажа подо мной. Связано ли это с металлическим каркасом? Не знаю...
А как с длинными последовательностями в TOON? Например, LLM-native XML практически не даёт путаницы на 50-100к токенов, например данные в формате
<users><user_1 name="Alice" role="admin” /></users>
Будут хорошо читаться и строиться как LLM, так и SLM. В TOON, как и в json довольно большая полисемия, LLM будет по-любому путаться на больших контекстах.
В триггерной методике это всё не особо важно. Когда Вы собрали фиксированную конфигурацию установки со всеми кабелями, то дальше остается только калиброваться на относительно мощный сигнал и ловить временную корреляцию между опорным импульсом (например, импульс запуска лазера или выход синхроимпульса от него же) и импульсом сигнала на ФЭУ. Когда пойман пик корреляции - дальше уже дело техники и не самой сложной программной обработки. Судя по тому, что он не использовал специализированных корреляторов, а только не самый быстрый осциллограф, точность корреляции у него не лучше 1нс, это примерно 33 см пространственного разрешения. Судя по осциллограмме, импульс от ФЭУ длинный, с фронтом несколько десятков нс, добавляем еще порядок на быстродействие детектора. То есть явно будет значимое для пространственного разрешения блуждание импульса по времени, но это неважно, так как угловые координаты определяются зеркалом, и системе не надо точно определять расстояние, а только энергию. Для этой задачи высокая временная точность не нужна, надо только отстроиться по амплитуде от шумов и ловить по времени импульс сигнала от конкретного синхроимпульса. Это можно было бы сделать и на 100МГц осциллографе. Интереснее посмотреть на его циклограмму временных сдвигов для захвата всего кадра.
Еще пока писал, обнаружил пару неточностей:
Ни о какой частоте измерений 2ГГц речи нет, на скрине идет 2кГц, это типично для короткоимпульсного диодного лазера.
2ГГц полосы и 2гигасемпла - это всё-таки немного разные вещи.
График выглядит мохнатым из-за того, что-то результат наложения множества реализаций, без этого была бы кривулина как на следующей картинке.
Осциллограф на 2ГГц, если он действительно на 2ГГц - не обычный, а ОЧЕНЬ дорогой прибор.
Так всегда. Если у Вас эргодический процесс, то есть нет суровых нелинейностей с большими временами релаксации, то фотографируя с разным сдвигом разные реализации процесса, Вы можете восстановить общий ход течения процесса в динамике. Например, Кэкак рассеивается свет в веществе, как нагревается вещество, как проходит ударная волна и тд. Всё это потом можно сравнить с результатами симуляций и уточнить модель и теорию, ведь главный критерий истины - всё-таки эксперимент.
Да это же по сути обычный радар.
Так это надо правильно работать с контекстом. Давай агенту граф кода для обзора, использовать разметки, иметь документацию. Агенту очень важно не только что написано, но и почему, а также как код, с которым он работает, связан с остальным приложением. Тогда и код пропадать не будет. Хотя для Claude ещё нужны прям директивные промпты, лучше с xml разметкой, иначе он всё напутает.
Есть один существенный нюанс. Разработка с ИИ неплохо масштабируется, то есть можно делать массивные шаблонные задачи с минимальными трудозатратами. Создать десятки моделей из графа бд - легко. Тесты для десятков ручек - пожалуйста. Один раз написал промпт, запускаешь несколько раз. Эффективнее Ctrl+C/Ctrl+V.
Так с ИИ надо работать нормально. Выступать архитектором. Спроектировать архитектуру, исходя из понятых тобой бизнес-процессов, подобрать нужный стек, создать граф приложения, спеку на его создание, тестовые критерии, а потом уже генерировать код. Тут аналогия скорее не "строить дачу своими силами из подручных материалов", а "создать ТЗ, заказать по нему проект дома с КД, сметами и прочим, и отдать в работу строительной компании".
Вы по сути описали семантическую разметку кода, которая по современным практикам интегрируется напрямую в код, создавая для ИИ семантически богатый граф, по которому можно легко навигироваться и получать недостающий контекст, например цель кода, тестовые критерии и тд, напрямую из разметки, а не после анализа кода. Такой подход снижает потребление токенов, увеличивает надёжность разработки. ИИ уже не будет дропать код, так как он точно понимает его назначение и связи с другими частями приложения без дополнительного парсинга файлов проекта.
У меня тоже есть личный опыт использования ИИ. Я ИИ долго не пользовался, считая его игрушкой (на самом деле не умея с ним работать). Я не так давно пришёл на новое место работы: новая предметная область, новый язык, обширное легаси. Подумал, что надо подключить к этому ИИ. Сначала было сложно, он(я) тупил, давал нерелевантные результаты, кривой код и всё такое. Где-то месяц я мучился, потом нашёл человека, который в этом разбирается, и взял несколько уроков. Потом практика, практика и ещё раз практика. Я научился с ИИ эффективно решать все задачи цикла разработки: архитектурное моделирование, аналитику, проработку тз, генерацию кода (около 90%). Выросла ли моя производительность? — да, на порядок, а это значит, что я могу решить задачу быстрее, чем без ИИ, и заниматься своими делами. Хуже ли я знаю язык, чем узнал бы вручную? — да, но не критично. Много читаешь код, разбираешься в best practices, правишь мелочи, язык сам прилипает. Качество кода нормальное. А главное, меняется мышление. Становится более системным и аккуратным даже на маленьких задачах, иначе как ты объяснишь ИИ что делать?
Вы можете загнать одну и ту же задачу в разные модели параллельно на lmarena.ai и оценить их пригодность для своих задач. Мне вообще больше всего Gemini 2.5 Pro нравится.
Забавно, но за последнюю неделю встречал абсолютно противоположный вывод: БЯМ отлично отличают текст, написанный ИИ, от написанного человеком и, более того, выше всего оценивают текст, написанный этой же БЯМ.
Отличная статья, спасибо. Хочу внести небольшое дополнение. По опыту для большинства python приложений достаточно slim образа + pyproject.toml. Если надо поставить какую-нибудь сложную библиотеку, типа pytorch, cupy или подобное - ищем образ от вендора, проиграешь по объёму, выиграешь по скорости развертывания и сэкономишь много нервных клеток. Alpine, конечно, намного компактнее, но там могут быть неожиданные проблемы с чем угодно: другой пакетный менеджер, свои версии системных зависимостей, нюансов много.
Полностью согласен с поговоркой про физиков. Сам физик, и после 6 лет занятий наукой я понял, что хочется чего-то более простого и денежного. В вебкам я не мог пойти по физическим соображениям, в закладки - по моральным, поэтому выбрал ИТ. Я неплохо знал питон и математику, но не представлял себе, что потребуется в индустрии. Походил по собесам, попробовался в яндекс как дата-сайентист, в другие места как разработчик, в итоге за три месяца нашел хорошее место, релевантное моему опыту. Рост зарплаты составил почти 4 раза относительно средней за последний год. Прекратились переработки, появилась финансовая стабильность, задачи проще, свободного времени больше. Что еще надо человеку?
У меня как раз был ранний EliteBook 14', и он был великолепен. Пользовался им около 7 лет, потом отдал родственникам, которые его года за 4 добили. Легкий, прочный, отличная клавиатура, хорошая производительность, IPS экран. Поменял только потому, что нужен был аппарат с ГПУ, и до сих пор вспоминаю его с ностальгией.
ProtonVPN в России не работает, по крайней мере у меня, причём довольно давно.
Ага, так что даже при использовании существующих математических пакетов приходится писать кучу кода под конкретную задачу. Причём он будет плюс-минус одинаковый вне зависимости от базового пакета: шаблоны, типы, костыли.
Я решал похожую задачу, правда, в квантовой теории поля, как раз с помощью Mathematica. Встроенная функция FullSimplify работает хорошо только с простыми выражениями. Если запихивать в неё какую-нибудь трехэтажную крякозябру, то надо заниматься тем же, чем уважаемый @Hemml занимался в своей работе: поиском шаблонов, рекурсивной подстановкой, указанием типов всех констант и переменных, оптимизацией к неподвижной точке и т.д. Да ещё и скорость всего этого добра оставляет желать лучшего. И синтаксис там ужасный :)
Справедливости ради, ошибки от непопадания пальцами по клавиатуре сильно отличаются от типичных орфографических ошибок неграмотного человека.
Я живу в одном из упомянутых домов МОСС-Тема. Не знаю, что насчёт конструктивных достоинств, но недостаток есть огромный: слышно соседей по горизонтали, по вертикали и по диагонали, передача звука через несущие конструкции отличная. Если прислушаться, то можно услышать как плачет ребёнок через этаж сверху и как играет живая музыка на 3 этажа подо мной. Связано ли это с металлическим каркасом? Не знаю...
Ну как же, большая часть физической литературы, по крайней мере в моей области, как классической, так и современной,
издаётсякачается именно в djvu.Основные преимущества - компактность и возможность полнотекстового поиска.