Терминология IT

Формирование атрибутивного состава объекта нормативно-справочной информации (НСИ) — это этап, на котором закладывается основа качества данных: ошибочный или избыточный набор характеристик делает справочник малофункциональным, а грамотно спроектированный — превращает его в надежный источник достоверных данных. Рассмотрим, почему даже полный перечень характеристик не гарантирует качества и что с этим делать, на кейсах SOFROS.

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

Атрибутивный состав ≠ шаблон описания

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

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

ИИ — Информационный Инструмент.

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

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

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

Определения:

1. Модель — LLM, нейросеть, генерирующая текст по запросу. Сама по себе stateless (не помнит предыдущие вызовы), не имеет доступа к внешнему миру и не способна к действию — только к порождению следующего токена или в итоге вероятного набора фраз по входному контексту.

2. Харнес — программно-инфраструктурная обвязка вокруг модели, превращающая её из генератора текста в систему, которая может производить "осмысленные" действия. Харнес обеспечивает модель функционалом: инструменты (доступ к внешнему миру), контекст-менеджмент (память, сессии, компактизация), правила/инструкции (поведение), разрешения и права (безопасность), опционально усиление — хуки, скилы, оркестрацию. Харнес — «тело», модель — «семантический мозг».

3. ИИ Агент — это модель, помещённая в харнес и потому способная действовать, то есть воспринимать состояние среды через инструменты, сохранять контекст между шагами, планировать и выполнять многошаговые задачи. Агент не компонент, а результат сочетания модели и харнеса.

Далее — как примерно происходило развитие идей и наполнение харнеса и к чему пришло.

Привет, на связи команда документирования СберТеха и авторы этой статьи — Маша Бурханова, Лида Ковач и Саша Яковлев.

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

Представьте, что у вас есть больше 700+ терминов, а в коде на каждую десятую строчку приходится ошибка. Исправлять вручную — всё равно что пешком подниматься на 150-этажный небоскреб. У нас родилась идея: проверять текст прямо во время написания, в редакторе.

Расскажем, как за несколько часов собрали прототип ИИ-агента технического писателя, с какими «подводными камнями» столкнулись при переходе к промышленной эксплуатации и почему в итоге написали собственное решение на Python.

Всем привет! Меня зовут Олеся, я руковожу отделом процессов и технологических стандартов ИТ на Московской Бирже.

Сегодня хочу поделиться опытом, который мы накопили при построении единой производственной системы SDLC (Software Development Life Cycle), включающей три компании Группы MOEX.

Это была не просто бюрократическая задача по написанию инструкций, а сложный инженерный и организационный вызов для нас!

Материал будет полезен CIO, руководителям ИТ-подразделений и архитекторам, которые сталкиваются с проблемой разрозненности в подходах к разработке внутри одной экосистемы.

Что полезного вас ждет в этой статье?

JSON Schema - стандарт для описания JSON. Standard JSON Schema - стандарт для… Нет, это не опечатка и не один и тот же стандарт дважды.

Кто на самом деле пишет ваш проект

Что происходит, когда разработку незаметно передают по цепочке — и почему проблема не в самом субподряде, а в потере контекста и ответственности.

Привет!

Заметка о правильности названий ETL процессов. Расставим точки над i.

Всегда было же нормально, коротко и звучно ETL. Теперь все чаще мелькает ELT, ETLT, EtLT.

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

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

Например, в потоке выполняется экстракция из базы данных, непосредственно при выборке происходят предварительные преобразования (отсечение миллисекунд у столбца времени), далее загрузка в цель - выполнился процесс ETL. Вторым этапом идут бизнес преобразования - процесс T, а вместе ETLT.

Таким образом и получается, что в большинстве случаев используется процесс ETLT, но исторически так сложилось называть все подобные процесcы просто и звучно ETL.
В аббревиатуре первая трансформация обозначается маленькой первой буквой t, и это не случайно. На данном шаге выполняются только предварительные преобразования данных: очистка, приведение типов. А вот уже вторая - это полноценная трансформация: бизнес преобразования, обогащения, расчеты и тд. Еще я встречал проставление индексов к буквам трансформаций ET₁LT₂.

Так же есть такое понятие как ETL++, но об этом в другой раз :-)

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

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

Я считаю, что революция искусственного интеллекта уже началась.

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

Революция — это процесс. И процесс уже идёт.

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

Именно так происходило раньше.

Меня зовут Константин Кузнецов, в ПСБ я занимаюсь, в числе прочего, поддержкой ИТ-инфраструктуры.

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

Если вы начинающий специалист в области ИТ-инфраструктуры, который видит своё будущее в ИТ-менеджменте — эта статья для вас. Думаю, вам будет полезно ознакомиться с вызовами и олдскульными способами их решения, основанными частично на ITIL, частично на devops.

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

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

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

Ведущий специалист Отдел исследований и разработки АО «Гринатом» Валерий Поздняков провёл не один час за ГОСТами, законами и другими документами, чтобы разобраться — кто же всё-таки он, наш искусственно интеллектуальный коллега?

В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.

Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.

В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.

В 2025 году мы работали над концепцией прикладного решения «1С Управление предприятием» для учебного курса УЦ №1 фирмы «1С». В основу легла процессная модель дискретного предприятия, которую мы много лет проверяли на реальных проектах. Видеоматериала получилось около 50 часов, а рабочих наработок — ещё больше.

Но в какой-то момент стало понятно: всё в учебную концепцию не войдёт. Хотелось показать и бизнес-предметы, и граф знаний, и объектно-ориентированный управленческий учёт, и связь ERP с будущим интеллектуальным предприятием. Но для входного курса это был бы перегруз.

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

Статья, которая поможет разобраться:
- такое tools, hooks и skills
- чем они они отличаются
- когда и что использовать

Привет! Меня зовут Павел Игнатё, я QA–инженер в платформенной команде Авито. Я занимаюсь развитием и поддержанием качества Backoffice as a Service (BaaS) — платформы, на которой строятся многие внутренние инструменты нашей компании. Моя работа — находить риски там, где их никто не ждёт, и превращать бесконечное ручное регрессионное тестирование в чёткие и стабильные автотесты.

Часто статьи про тестирование похожи на справочники: сложные термины, от которых закладывает уши. Но сегодня мы попробуем объяснить сложные вещи на примере обычного офиса. 

Эта статья не про то, как «написать побольше автотестов». И не про то, как заменить ручное тестирование автоматизацией. Она про другой вопрос: как тестировать платформу, от которой зависят другие продукты.

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

Предлагаю вашему вниманию перевод seL4 Whitepaper, который является хорошим введением в одно из самых известных микроядер для ОС — seL4 (лицензия GPLv2).

Здесь не только специфика seL4 и микроядер, но и много полезного материала в целом по безопасности, формальной верификации, виртуализации и системам жёсткого реального времени.

Третья часть серии о Linux для DevOps и DevSecOps – разбираем права доступа, модель UGO, биты rwx, числовое и символьное представление, chmod и chown.