2025-06-04: KnowledgeConf - снова отдельная конференция

Короткая ссылка: KnowledgeConf-2025

Ссылки сюда (3) →

О других конференциях

В понедельник 02.06.2026 был на KnowledgeConf — конференции по управлению знаниями в ИТ. Конференция первый раз прошла в 2019 в двухдневном формате, в 2020 была вынуждена уйти в онлайн, потом несколько лет шла как отдельный трек на Teamlead, а сейчас прошла отдельно. Один день, три трека докладов и один мастер-классов. 300 очных участников, что вполне неплохо. Визуально на площадка казалась пустоватой, но это потому, что залы — большие, на 100—150 человек, а большой зал мог вместить всех, и когда люди рассредоточивались по нескольким, казалось пустовато. Конференцию организовывал Онтико, так что оргвопросы и питание вопросов не вызывали.

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

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

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

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

Я публиковал заметки с докладов прямо в ходе конференции, а теперь собрал их в единый отчет. Отдельно отмечу: на конференции было много докладов про использование LLM — тема актуальная. Но в докладах, которые я услышал, именно в работу с LLM не погружались, говорили о процессах организации и других подобных вопросах. То есть освоение инструмента перешло на следующую стадию. Я помню, что так же было с вики-системами: первые доклад были про начало использования, отличия в работе с документами при использовании вики, про особенности организации страниц и других аспектах организации информации. А потом использование все освоили, и фокусом докладов была эффективная организация использования: как обеспечить быстрый поиск и хорошую навигацию, как наполнять, как вплетать в основные процессы, как следить за актуальностью и регулярным обновлением и так далее. Так и с LLM: они устойчиво вошли в повседневную практику.

Галина Ширанкова. Как мы начали учить LLM-модели в несколько раз быстрее, просто поменяв роли в процессе

Следующий такт освоения LLM-моделей — построение эффективных процессов обучения конкретных моделей. Речь шла про LLM, которая отвечает за продавцов. Есть метрика, что ответ в первый час после вопроса сильно повышает вероятность сделки. У них целевая метрика — именно повышение вероятности сделки, но если человек из ответов быстро поймет, что ему это не нужно — тоже хорошо — он пойдет искать другое. Дополнительно проверили гипотезу на простеньком боте, который умел отвечать на вопрос «Еще продаете?» — оказывается, это очень частое начало разговора. А дальше надо было отвечать на содержательные вопросы. У авито очень широкая линейка продуктов, и вопрос «какой размер?» про одежду, электронику или собаку предполагает совершенно разные ответы. Для ответа используют формальные характеристики и текстовое описание продукта, например, если продавец указал размер обуви 39, но в тексте написал «маломерки», то это — часть ответа.

За квартал 2024 год они обучили 4 тематических модели, и поняли, что это — медленно. Потому что чем дальше — тем уже группы вопросов. нарисовали схему процесса, и увидели узкое место: LLM-инженер по ТЗ продукта делал датасеты, но он не мог оценить результаты обучения, так как был не погружен в тематику. А еще у него много проектов, и поэтому на обратную связь продукта он тоже реагирвоал медленно. Решение — забрать процесс обучения себе, к аналитикам. Аналитик погружен в контекст, он сам может оценить датасет — уходит время задержки, петля обратной связи становится быстрой.

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

Результат — 23 модели, обученных за полквартала, с качеством ответа 91 % против 93 % у тщательно обученных первых четырех. и 88 % у ChatGPT, используемой как baseline. Они сравнивают с ChatGPT и DeepSeek, при том что у них — маленькая LLM, чтобы понять возможный уровень ожидаемого результата. Такая история.

Дарья Вьюнова. Как создать самообучающуюся команду

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

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

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

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

Самообучающаяся команда — это всегда культура. И эту культуру можно делать в рамках команды, даже если в организации в целом ее нет. Субкультура — это нормально, если не превращается в контркультуру. У нее был опыт в OTUS, когда культуру команды отличалась, а сейчас она пробует сделать то же в рамках ВУЗа. Пока — получается, но это — вызов, результаты будут понятны через год. Но важно, что культура команды, а не отдельного человека, нужна поддержка. В этом я хочу пожелать Дарье успехов!

Дарья Мулык. Как грамотно общаться с экспертами, от которых вам нужны знания

Это доклад про наши реалии. Когда эксперты имеют личный опыт, который позволяет делать задачи, но не могут его изложить, не умеют разделить на важное и второстепенное — в общем, не владеют методами мышления, которые делют его ясным и структурным. И потому их приходится вести по пути извлечения для создания курсов, статей или других материалов, и человек, который это делает — тоже особо не погружен в контекст. И никаких глубоких know-how в этом процессе тоже нет: надо установить контакт, сформулировать решаемую проблему, выработать план. Проверить, что контент изложен адекватным языком, понятен для не-специалистов из целевой аудитории, что идет от простого к сложному. А главное — что результат закрывает поставленные задачи. В целом это тоже начальный уровень для извлечения знаний, потмоу что на практике занимаются этим не профи по работе со знаниями. И, в общем, это особенность текущей ситуации, о которой у меня была статья "Реальность цифрового мира: проекты делает некомпетентная команда (https://vc.ru/hr/167620)". Так что если вам надо извлекать знания из экспертов, а вы этим не занимались — послушайте доклад Дарьи. А пунктиром я его содержанеи написал.

Алексей Обровец. Ключевые коммуникационные инструменты эксперта по управлению знаниями

Этот доклад — на ту же тему, что у Дарьи. Но при этом совсем другой по содержанию, по акцентам. Основной фокус: работаем со смыслом, а уже потом — с эмоциями. При этом вы как профессионал должны быть готовы к работе в разными людьми над общими целями. Вы знаете, что работаете с экспертом. Но эксперты все разные, одни общаются через переписку и будут благодарны за отсутствие встреч, а с другими надо встречаться и общаться. То же касается мотивации по-взрослому: в работе есть разные задачи, не все могут нравится, и к этому тоже надо быть готовым. И в этом отличие от доклада Дарьи.

При этом в обоих докладах — громадное количество полезных практик, тут они дополняют друг друга. У Алексея много рекомендаций по начальному контакту. Важно, представит CTO или HRD: для инженера авторитетом являются инженеры. Важно не врываться с личным общением — разработчик занят текущей задачей, и оторвав — вы выбросите в корзину текущие мысли, ему придется начинать заново. Поэтому — письмо. И в письме сразу заявить: он — общепризнанный эксперт (так сказал СТО), и потому прилетела задача вынуть экспертные знания в такой-то форме, и предложить варианты: встреча, переписка, ответ на вопросы и так далее. В письме превентивно действуешь против низкой самооценки, потому что это — очень распространенная проблема, эффект Данинга-Крюгера.

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

Атмосфера сама себя не создаст. Все сделать, чтобы облегчить. Любимое упражнение Вдох — Улыбка — Инвестиции.

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

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

Встречаемся на работе — не для того, чтобы дружить. Если ты идешь на работе, чтобы полюбили — проблема вне офиса. Если идешь на работу доказать, что ты — эксперт, то это обычно не на работе. Цель работы — не понравится. Он делал эту ошибку несколько лет. Если вы хотите, чтобы на вас смотрели со страхом и открыв рот — идите в стоматологи.

Трудности коммуникации

• Человек пришел, но зажатый и бука. Он имеет на это право. Он проснулся с таким лицом и пришел. Не меряем коммуникацию эмоциями, меряешь ключевыми словами и экспертизой
• Если человек говорит активно, но не про то, уводит разговор — просто перебиваешь. «Оля, нам надо вернуться, иначе не успеем»
• Если кажется, что человек ненавидит и предвзято относится — можно игнорировать, если отдает экспертизу. А если не отдает — проблема в целеполагании, и к нему возвращаешься. К целеполаганию постоянно возвращаешься, валидируешь и можно передоговориться или разойтись

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

Меня нельзя обидеть, потому что Леша остался дома, а на работу пришел эксперт. Можно только сорвать сроки или не дать экспертизу. При этом эмоции — остаются, просто они — на втором плане.

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

Артем Варкулевич из Онтонет. Совместное мышление: усиливаем команду инженерными подходами в управлении знаниями

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

В целом концептуальная конструкция состоит в том, что мы с помощью моделей описываем продукт, как привычно в ИТ, а вот мир вокруг продукта описываем с помощью онтологий, а не используем описание бизнес-уровня на языке Archimate или аналогичном. Вероятно, это специфика самого разрабатываемого продукта — онтонет, который они для себя тоже используют. Это не слишком просто понять без примеров, а их в докладе было мало, был очень большой рассказ о том. каких результатов они достигли за счет своей методики, а вот сама методика раскрыта слабо, а примеры — фрагментарны. Я, в общем, из описания доклада онтологию в нем увидеть. Жаль.

Денис Кучеров. Ошибки в менеджменте знаний: в качестве аргументации — страшилки

Доклад о том, что во многих компаниях вместо базы знаний — файловая свалка знаний с исторически сложившейся структурой или нечто аналогичное, где даже автор документа ищет его 20 минут. А потому сотрудники пользуются шпаргалками и устным творчеством. В докладе это показано через топ-5 ошибок, но это, лишь разные аспекты свалки вместо базы знаний. При этом Денис работает в Minervasoft с реальными проектами, каждая проблема иллюстрирована кейсами из реальных проектов, помимо примеров из Корпорации монстров, которые оживляли доклад. Понятно, что для доклада кейсы-страшилки отбирались, но по моему опыту свалки знаний действительно часто встречаются.

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

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

Анна Лучник и Александра Зебелева. Опыт использования больших языковых моделей (LLM) в процессе управления знаниями

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

А еще с помощью LLM вы можете эффективно работать с теми знаниями, которые у вас есть в виде больших массивов информации: чаты, письма, таск-трекеры и так далее. Они помогут со структуризацией информации, со сборкой данных по неструктурированным источникам, позволят получать ответы по нечетким запросам. Локальные массивы данных можно подключить, в том числе с локальным хранением, как к облачным LLM, так и с развернутыми локально. В том числе для персонального использования, есть связка Obsidian + LLM. Правда, подробностей, как именно это сделать, в докладе тоже не было, хотя я бы тут ожидал как минимум обзор вариантов.

И про различие облачных и локальных LLM говорили совсем общим языком: облако может пропасть, как стали недоступны Miro и notion, и как физически пропадают хранилища многих стартапов, если стартап не взлетел, а локальное хранилище и локальная LLM требует больших вычислительных ресурсов и администрирования. Про большие ресурсы, кстати, неверно, сейчас есть LLM, которые можно развернуть не только на скромных корпоративных мощностях, но и на машине разработчика, например, для работы с кодом на естественном языке. И умения, которые для этого нужны, не отличаются от умений, например, требуемых для локального развертывания вики-систем.

А в целом от доклада хотелось больше конкретики: примеров, кейсов, обзора вариантов.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 15:49, 4 июня 2025 • нет комментариев