Интегриране на PKG в предприятието

Как изкуственият интелект движи технологията за график на личните знания

В миналите си блогове съм писал за бързо разрастващата се тема „Графики на лични знания“ (PKG) и „управление на знания“. Този блог ще се съсредоточи върху предизвикателствата на интегрирането на PKG в по-големи екосистеми на знания, като например „графиката на корпоративното знание“ (EKG) на вашата компания или системата за управление на знанията в колежа и университета.

Целевата аудитория за тази публикация е архитект на решение, който е бил помолен да разбере компромисите между много изолирани PKG силози и по-интегрирани графики на фирмено знание, които споделят знания и избягват дублиране и несъответствие на знания. Ние разглеждаме ограничените опции за интеграция, налични днес, и прогнозираме голяма възвръщаемост на инвестициите, тъй като продуктите на PKG интегрират най-новите препоръки за големи модели за машинно обучение.

Ако сте нов в областта на PKG, силно препоръчваме да прочетете предишните статии за PKG, EKG и управление на знания, за да разберете напълно тези концепции.

Напрежението между личната и организационната повторна употреба

Преди да се потопим в терминологията, нека си припомним, че винаги има две противоположни сили, движещи PKG в една организация. Първата сила е необходимостта всеки човек бързо да записва бележки, които са в съответствие с личната му база от знания. Докато пишете, списъците с автоматични предложения ви позволяват бързо да се свържете със собствените си лични концепции във вашия собствен PKG. Когато въведете „[[“ в текстовия редактор, се показва списък със съществуващи концепции. Докато пишете, списъкът автоматично се стеснява, за да съответства на префикса, който вече сте започнали.

Втората сила е желанието на много компании да уловят това знание по начин, който да може да се използва от другите в компанията. Това означава, че големите организации често ще въвеждат допълнителни правила, които предотвратяват бързото събиране на знания. Искате ли да издадете билет в системата за помощ? Трябва да ни кажете за вашия компютър, какво се опитвате да направите, какво приложение използвате и малко информация за това как да възпроизведете грешката. Без тези задължителни полета да бъдат попълнени, бутонът Запазване е деактивиран.

Моят опит показва, че винаги ще виждаме компромиси. Кой плаща за софтуера, как се улавят знанията и как се пишат MBO за споделяне на знания често предизвиква безпокойство. Тук няма универсално решение и използването на големи инструменти за обработка на естествен език (NLP) за машинно обучение само прави решенията по-сложни. Ще обсъдим тази тема повече по-късно в блога.

Класификация на съвременните инструменти

За да започнем нашата дискусия, помислете за два настолни инструмента. Първият е самостоятелен инструмент за редактиране, като Microsoft Notepad(TM), който идва с вашите настолни приложения за Windows(TM). Мислете за това като за добавяне на нов лист на знанието към малка нова фиданка на дърво. Този инструмент ви позволява да въвеждате произволен текст от вашата клавиатура и да го запазвате в локалната си файлова система. Notepad е идеален за улавяне на нова информация, която е изключена от останалия свят. Дори не е необходимо да сте свързани към вашата корпоративна мрежа, за да го използвате.

Уикитата също ви позволяват да въвеждате текст в свободна форма, но винаги в рамките на страница, която има уникално име. Вашият текст може да съдържа препратки към други посочени страници. Някои Wiki страници могат да съдържат структурирани двойки ключ-стойност, често наричани информационни кутии. Основната разлика между Notepad и Wiki е, че Wiki страниците се съхраняват на сървър и се преобразуват в уеб страници с връзки.

Сега нека разгледаме PKG редактор като Roam или Obsidian. Те винаги са свързани със съществуваща база от знания и фокусът е създаването на бързи връзки към вашата вътрешна лична графика. Ето една метафора, която искаме да разберем ясно от Фигура 1. PKG са полезни, когато искаме да уловим нова информация, която разширява съществуващата структура на знанието. Например, когато въведете просто име на концепция, системата проверява дали това е нова концепция, а не дубликат на съществуваща концепция или псевдоним на съществуваща концепция.

В долния десен ъгъл на диаграмата има официални инструменти за редактиране на онтология като Protege и бази данни с графики като Neo4j или TigerGraph. Тези бази данни с графики имат много ограничения, като формални типове за всеки връх и ръб и строги правила за това какви типове върхове могат да се свързват един с друг. Ръбовете също трябва да имат тип.

Последното поле на фигура 3 е PKG с помощта на машинно обучение (ML-PKG), където NLP инструментите се използват за автоматично предлагане на текст във вашия PKG редактор. Тези инструменти все още не съществуват, но с бързата еволюция на широкоезични модели като BERT и GPT-3, очакваме да бъдат налични скоро.

В обобщение, ще има много правила в интегриран Enterprise PKG. Много от тези правила могат да бъдат полезни. Те могат да ускорят работата ви, като добавят знания с помощта на интелигентно контекстно автоматично довършване. Някои от тези правила ще ви попречат и ще забавят скоростта на улавяне на знания.

Основна терминология

Нека започнем нашата дискусия с някои основни термини и концепции. В PKG целта е ефективно да се позволи въведен поток от знаци за ефективно улавяне на концепции за знания и създаване на връзки с предишни концепции. В PKG използваме структура от данни, наречена графика на знанието. Графиката съхранява не само плосък списък от понятия, но и връзката между тези понятия. Техническият термин, който използваме за съхранение на концепции, е връх, а терминът за връзки се нарича край.

Нетипизирани срещу типизирани системи

Много от нас са запознати с концепцията за уики. Думата „wiki“ е хавайски термин за „бързо“. Синтаксисът на връзката към Wiki страница позволява на потребителите да минимизират броя на натисканията на клавиши, които свързват wiki „страниците“ една с друга. В wiki модела на данни всички концепции се съхраняват на wiki страница и целта на дизайна е да се следва правилото за една страница на концепция, така че концепциите да могат лесно да бъдат свързани заедно. Ако поставите две или повече концепции на страница, връзката към тази страница няма да покаже ясно модела от една концепция към една концепция.

Wiki's бяха прекрасна стъпка напред във воденето на бележки, защото концептуалните страници или концептуалните карти бяха споделени в уеб сървър. Докато вашите връстници добавят нови концепции, можете да създадете връзки към тези концепции. Докато добавяте нови концепции, вашите колеги също могат да се свържат с тях. Това беше огромен пробив в управлението на споделеното знание и е в основата на системи като Wikipedia.

Повечето хора обаче не мислят за wiki като за истински „графики на знанието“, защото те наистина са просто колекции от свързани нетипизирани документи, точно като световната мрежа. Дизайнерите на wiki искаха да разширят концепцията за „хипервръзки“ и да направят връзките по-лесни за въвеждане, отколкото запомнянето на сложния синтаксис на препратките към HTML котви. Фундаменталната разлика между wiki и истинската графика на знанието е фактът, че всички wiki страници са от един и същ „тип“ (тип документ/карта/концепция), а връзките също имат един тип (свързани с ).

Графите на истинското знание позволяват на всеки връх и ръб да има специфичен тип. Списъкът с възможни типове често се конфигурира от централизиран отдел. Например, някои върхове може да представляват служител, други могат да представляват продукти, които продавате, а някои може да описват бизнес събития, като например обаждане до бюрото за помощ на вашата компания. Ключовото при типовете е, че можем да свързваме правила с типове и тези правила налагат последователност, която прави графите на знанието лесни за заявки, точно както правим заявки към традиционна база данни с помощта на SQL.

Ако добавяте нов град към PKG, можете да кажете на системата, че върхът е от тип „град“ и също така да добавите връзка „разположен в“ към връх „състояние“. И върховете, и връзките имат типове.

В областта на стратегията за графики на знанието на предприятието ние използваме хипотезата на Джим Хендлър „„Малко семантика върши дълъг път. увеличете тяхната устойчивост и повторна употреба.

Много организации са открили, че споделените уикита са идеална система за съхранение и свързване на знания. Повечето организации обаче не отправят запитвания към уикитата, защото поставят приоритет на редактирането в свободна форма пред строгите правила. Винаги можете да опитате да наложите структура на уики страница, но тези структури често не са задължителни и малко уики системи ви пречат да запазите уики страница, ако задължителните полета липсват. „Инфокутиите“ на Уикипедия са пример за това как уикитата могат да бъдат модернизирани, за да добавят структурирани данни, които могат да бъдат заявени.

Налагане на уникалност на името

Въпреки че повечето уикита не ви позволяват да присвоявате типове на нови страници по време на създаване, те имат някои други правила, които графиките на знанието нямат. Когато създавате нова страница, трябва да й дадете име. Това име служи като идентификатор на страница с wiki. Сега две страници могат да имат едно и също име. В повечето PKG имаме подобно правило. Ако се опитате да въведете нова страница със същото име, софтуерът ще ви каже, че страницата вече съществува. Ако преименувате страница, за да има същото име като съществуваща концепция, системата ще ви попита дали искате да обедините имената. Добавянето на псевдоними (един или повече етикети за една и съща концепция) е друго предизвикателство, много PKG не се справят добре.

Прилагане на типизирани системи към цикли на събития за вземане на бележки

След като вече имаме представа за критичната разлика между уикита и графики на знания, нека зададем въпроса, как можем да ускорим способността да правим връзки, докато въвеждаме текст в PKG страница? Ще започнем с някои прости примери и след това ще се потопим в някои по-сложни теми.

Общият модел, който използваме, е да визуализираме символи, въведени на клавиатура. Докато потребителят въвежда всеки нов знак, ние прилагаме набор от правила, за да помогнем на потребителя да вземе решение, ако има възможност да добави предимство към съществуваща концепция. Ако има, потребителите ще използват знак, като например клавиш за табулация, за потвърждаване на връзките и автоматично попълване на останалите знаци за ръба. Ако не искат да приемат предложението, могат просто да продължат да въвеждат.

Ключът е, че когато потребителят въвежда, той често иска да сигнализира, че е необходима връзка към конкретна въведена концепция. Може вече да сте запознати с този процес, ако използвате социални медии и искате да посочите човек или концепция, използвайки „@“, за да посочите човек или акаунт в Twitter. Можете да добавите хаштагове, като използвате знака „#“ в края на публикацията в блога си, за да позволите на системите за препоръчване да обвържат публикацията ви в блога с хора, интересуващи се от конкретна концепция.

След като сигнализирате на авторската система, че искате да посочите съществуващ възел с тип, тя потвърждава това, докато пишете или предлага списък с автоматични довършвания.

Ключът е, че организациите разполагат с много видове данни, които искате да включите във вашата препоръка за edge. Нашият фокус е намирането на начини за интегриране на тези специфични за организацията типове в цикъла докато въвеждате в текстовите редактори за нашите PKG инструменти. Ако искате да посочите служители във вашата компания, „@“ може да извлече списък от вашия списък с имена на служители на компанията. Щракването върху връзката за този служител ще позволи на потребителя да отиде на страницата на PKG за този служител.

Друга често срещана точка на интеграция е свързването към стандартен фирмен речник на термини и акроними. Вместо да използвате специален символ на клавиатурата, можете да добавите префикс, разделен с двоеточие, към името на върха. Например, ако имате фирмен речник на термините, можете да накарате вашите потребители да използват „g:“ като префикс и автоматичното довършване ще съответства на тези термини. Ако използвате специфичен за индустрията речник, можете да посочите тези терминологични стандарти в префикса. Например в здравеопазването ние използваме речника „Just Plain Clear“, така че префиксът „jpc:“ автоматично да попълва термини от тази система.

Добавяне на потребителски типове

Моето предложение, когато създавате стратегия за интегриране на PKG, започнете с малко и надграждайте успехите си въз основа на стойността, която всяка интеграция добавя към вашата потребителска общност. Започнете с прости списъци на служители и термини от фирмения речник, които често се споменават. Опитайте да експериментирате с неща като „g:“ за фирмен речник или „w:“ за термин от Wikipedia и вижте колко често се споменават. Ако има слабо приемане на тези предложения, те трябва да бъдат премахнати. Не забравяйте, че хората винаги могат да добавят външни връзки към Wikipedia.

Наблюдение на степента на приемане

Вече има обширни проучвания за това как НЛП моделите на голям език като BERT и GPT-3 могат да бъдат използвани за подпомагане на разработчиците на софтуер чрез предлагане на код. Когато дадена система прави препоръки на потребител относно предложено автоматично довършване, ако потребителят приеме предложението, това се записва в регистър на събитията. Родителят на предложенията, които потребителят приема, наречен процент на приемане, е от решаващо значение за тяхното приемане на тези инструменти.

Като цяло, ако вашите потребители не приемат около 1/3 от предложенията за автоматично довършване, инструментите ще станат повече досадни, отколкото полезни. Потребителите ще деактивират инструментите и вие няма да получите обратната връзка, от която се нуждаете, за да постигнете успех. Така че е изключително важно да се стремите към 30% или по-висок процент на приемане, преди да пуснете тези инструменти в производство.

Постоянни връзки и PURL

Добавянето на пълни URL връзки от вашите бележки към всякакви вътрешни корпоративни ресурси също е нещо, с което трябва да внимавате. Много вътрешни системи за управление на документи, като Sharepoint(TM), зависят от връзки към конкретни файлове в рамките на йерархична файлова система. Когато разрешенията за тези папки се променят или документите бъдат преместени, тези връзки вече няма да работят.

По-добрият избор е да правите връзки във вашите PKG само към местоположения, за които вашата организация е поела ангажимент да не се променят - никога. Ние наричаме тези връзки постоянни връзки или PURL. Това може да стане чрез внимателно управление на вашата вътрешна система за име на домейн, така че връзката към http://glossary.mycompany.com/#term винаги да работи, дори ако сървърите, на които се хоства речникът, се променят.

Следващата стъпка е да се уверите, че вашият екип за интегриране на PKG разполага с инструменти, които могат да наблюдават повредени връзки и да работят проактивно, за да предотвратят прекъсването на връзките, докато съдържанието се движи из сървърите на вашата организация. Помислете за създаване на „стойност“ от един долар за работеща връзка и помогнете на хората под стойността на знанието, което се губи, когато връзките се счупят, и времето, необходимо за актуализиране на повредените връзки.

Повечето графи на знания поддържат двупосочни връзки. Ако промените името на концептуална страница, всички връзки към тази страница автоматично ще бъдат актуализирани. Това е ГОЛЯМА победа и се равнява на супер последователно и евтино управление на взаимоотношенията.

Като общо правило, 60% от стойността на графиката на знанието са възлите, а 40% от стойността са връзките. Неработещите връзки обезсърчават авторите да създават бъдещи връзки, а потребителите са по-неохотни да се доверят на системи с много повредени връзки.

Интегриране с NLP Frameworks

Едно от ключовите развития е възходът на евтини инструменти в реално време, които могат да анализират входящия текст и да търсят ключови думи и фрази, които са подходящи за дадена организация. Тези процеси включват автоматична класификация, извличане на именуван обект и извличане на факти. Например, ако сте въвели термина „вчера“, системата може да открие текущата дата и да вмъкне връзка към вчерашната дата във вашата хронология, така че да можете да видите какви бележки се позовават на тази дата.

Уместно е и кога интегрирането на NLP в работния процес за редактиране. Изводите в реално време върху големи НЛП модели могат да бъдат много скъпи. Проверките докато пишете трябва да се изпълняват бързо. Добавянето на ключови думи към документ в края на деня е много по-ниска цена. По принцип услугите за автоматично предлагане в реално време трябва да работят в 1/10 от секундата. Това са времена за реакция от 100 милисекунди и организациите, които предоставят споразумения за ниво на обслужване, може да имат тежки такси за връщане на такса, които вашият потребител не иска да плаща.

Други точки на интегриране

Интегрирането с автоматично предлагане в чартърния поток и интегрирането с NLP анализи в реално време са двете области, които ще доминират във вашите архитектури за интегриране на PKG и ще стимулират точките за вземане на решения за вашия PKG продукт. Има обаче няколко други области, които трябва да се вземат предвид.

Преобразуване на разширения Markdown

Почти всички PKG днес са съсредоточени върху разширяването на стандартните Markdown формати. За съжаление различни доставчици са избрали различни формати за тези разширения. Когато импортирате или експортирате Markdown между системи, може да се наложи да добавите конвертори между тези формати. Например, преобразуването от Obsidian в Roam или обратното ще изисква да заредите разширения за конвертор, за да свършите тази работа. За щастие, скриптовете за преобразуване са доста прости промени в синтаксиса и са добре документирани. Много малки програми на Python вече са налични за извършване на тези преобразувания. Нещата, които трябва да проверите, включват външни връзки, връзки към изображения, тагове с метаданни, подчертаване на текст и псевдоними.

Заключение

Винаги ще има естествено напрежение между бързото водене на бележки в свободна форма, необременено от правила, и желанието организацията да използва повторно знанията и да ги направи последователни. PKG, уикитата и графиките на корпоративните знания се развиват във връзка с експлозията на NLP инструментите и растежа на широкоезични модели, които предлагат текст в контекста на текстов редактор.