Второй мозг: ператварэнне стенографіяў з саецедзяў у граф аднароджэння знанняў, які можна шукаць

Проблема

Практычна кожная арганізацыя паводліва зустрэчам, каб працаваць да прынесення рэзультатаў — планаваць дыскусіі, ведаць календарныя размовы з кліентамі, аналізаваць рэзультаты справачных циклаў, арганізаваць рабочыя сесіі для выканання доследжэнняў. Кожна з гэтых дзеянь стварае стабільны прыпłyў рашэнняў, пунктав акцый, рызыкаў і зобав’язанняў. І практычна без выключэння гэтая інфармацыя проста зникае пасля таго.

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

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

Патрэбна была система, якая могла б масштабавана прыймац транскрыпты зустрэчаў, автаматычна выделяць структураваныя данні і давац людзям можлівасць запытваць гэтыя данні на простай англійскай мове — пры тым ствараючы жывую карту асоціяцый, якая становіцца багатейшай з кожной дадзенай зустрэчай. Гэтая система была названая Second Brain.

Візыя: Жывая графа знанняў для кожнага проекту

Основная ідея простая. Кожны раз, калі завантажваецца транскрыпт зустрэчы, система яго аналізуе, ўбачваючы, хто говорыў пра які проект, какія рашэнні былі прыняты, якія рызыкі выйшлі на паверхню і хто адпавядае за кожны наступны крок. Усё гэта заносится ў Azure Cosmos DB. З таму можна задаць запыт на натуральнай мове і атрымаць адпаведны ўтварэнны, падкрэслены адпаведнымі даннемі адказ.

Калі накапліваецца больша колькасць транскрыптаванняў, граф знанняў па-прыродны чынам ствараецца — гэта развіваючаяся сетка, якая спаўнае людзей, рашэнні, дзеянні і рызыкі з усіх запісаных сесій.

Інтерфейс рашэння

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

Больш дакладна пра складовыя

1. Extract_Entities_Tool — паралельнае выкарыстоўванне

Гэты інструмент выконвае основную частку работы. Прымуўшы сырой текст, ён дзеліць транскрыптаванне на часткі, групаваныя па абаротках, паралельна выконвае выкарыстоўванне элементаў у кожной частцы за дапамогою ThreadPoolExecutor, а пасля з’едынае рэзультаты, оцінюючы кожную адмінную значэння за ступенем паверыльнасці выкарыстоўвання і частотай яе павтарэння.

Значыць сема типаў адзначаюцца за дапамою формата, разлучанага тычкамі, які мовны модель можа адносна правільна выкарыстоўваць.

У результате модель стварае выходны тэкст у формате "Review architecture | Owner: Archana | Due: Next sprint" — строку, якую прылада можа пасля чаго аналізаваць і ператвараць у структураваныя словнікі {task, owner, due}, гатовыя для детальнай візуалізаціі і стварэння рэгулярных звязкаў у графе.

Автонамна адкрыцьце тэрмінаў домены

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

2. Text2SQL_CosmosDB_Tool — Адзыў у нейтральнай мове

Этый компанент прымае запит на англійскай мове разам з падказкай, якая апісвае схему Cosmos, ператварае яго ў запит Cosmos SQL, выкананы яго і дае адпаведную адказ на базе рэзультатаў. Складнасць заключаецца у тым, што діалект SQL NoSQL базы дадзеных Cosmos DB не дазволяе безпасяродна выклікаць CONTAINS() для полей-масоў. Рашэнням было даць інструменту чыстае падказкавае апісанне схемы, якае паказвае, як следуе выканаць запыты для масоў.

3. Cosmos DB як сама «галава»

Этая база дадзеных знаходзіцца ў цэнтры всей системы. Яна не функцыонуе як кэш або храніліща логаў — Cosmos DB фактычна ёсць «Другая галава», шар стойкай памяці, дзе кожны выкараны фрагмент знанняя зберагаецца, накапліваецца і становіцься доступным для запытавання.

Кожны дакумент з выкарыстоўванням метадаў з суфармованых зустрэчах храніць кожную аб’ектнасць два разы: аднажды як просты масіў страк, што дазволяе выкарыстоўваць запытанні на базе SQL, і аднажды як масіў структураваных об’ектаў, што дапамагае атрыбутавану вывод у інтерфейсе і стварэнню ребер графа. Гэта подвойнае храненне дадае незначную допаможнюю плошчу на дакумент, але ўбачае неабходнасць параскладвання якоў-небудзь матэрыялу на роўні прыемліка пасля таго, як даныя вернуліся з базы дадзенаў.

Аналагія з мозгам — два режымы памяці

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

Ключовыя інжынерныя рашэнні

Некалькі свядомых выбораў паўтарыліся ў стварэнні прыроды функцыонавання системы: ад рашэння абмовіцца ад ручной настройкі домэнаў на корыстцу автаматычнага адкрыцья, па храненню ентытаў у дублікатах для патрэб SQL і UI, па звярненні ролі LLM на выключна выкарыстоўванне для выкарыстоўвання дадзэнняў і стварэння запытоў, а не на форматаванне тэкста чы правіла бізнесу.

Усвойленыя урокі

1. Працэўнасць Streamlit па перзапуску выклеква неабходнасць адказвальнага керавання станам. Кожны нажымак на кнопку выконвае весь скрыпт занова, ад самага пачатку. Усё, што должна застацца актуальным пасля кожнай перадпрацавкі, трэба запісаць у st.session_state прытаму, як толькі будзе прадстаўлена кнопка, якая запускае перзапуск, а не пасля ёй.
2. Діалект SQL у Cosmos DB не являецца стандартным ANSI SQL. Функцыя CONTAINS() працюе толькі з рэчамі, а не з масавымі даннымі, таму ў схеме неабходна чыстая інструкцыя ўказваць спосаб её выкарыстоўвання — уключаючы прыклад неправільнага напісання запиту.

Модэлі мовы не можна вважаць надзеянымі ў тым, што яны завжды будуць следаваць інструкцыям па формате выходных даных. Нават пры чыстах інструкцыях па синтэзе модэль часам вяртае толькі короткае вступнае рэчы, а не цэлавесны адказ. Чырвонай прычынай гэтага ёсць тое, што детерміністычны альтэрнатыўны падход, які стварае адказ няпасляўна з сырых даных, якія былі атрыманы, не ёсць проста допаможным элементам — гэта неабходная меры безпекі.

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

Для адаптавання графікаў Pyvis унутрь Streamlit неабходна запісь у тымчасовы файл, а не перадача строкі з памяці. Ожывайце tempfile.NamedTemporaryFile і не забудзьце пазніяй вычыстыць яго. Таксама варта згадаць, што st.components.v1.html будзе паступова выключаны з 2026-06-01, таму ў будучыні следует вжываць st.iframe.

Асновная ідея дизайна

Праўая „інтэлігенцыя“ такой системы не выходзіць з мовнага модэлю — яна выходзіць з базы дадзеных, якая стоіць за ўсім.

Сам модэль зовсім не мае памяці; ён за своей прыродай безстановы. Ён чытае частку транскрыпціі і стварае набор аб’ектаў. Ён чытае запитанне і стварае SQL-запыт. Нічога не застаёцца між вызывамі — кожны вызыв пачынаецца абсалютна з нуля.

Cosmos DB — гэта тое месца, дзе знаходзіцца рэальная памяць. Як толькі ўтварэнне зберагаецца ў «мозгу», тады тымчасова выкарыстоўваная інформацыя з модэлю ператвараецца на стойкі, структураваны і можна шукаць запис. Слоўнік тэрмінаў домэна продовжвае растаць. Сетка асоціяцый расширваецца. Знанні з часам накапліваюцца.

Усія системы працуюць на інфраструктуре, якая вялікай меры ўжо існавала — Azure VM-ы, Azure Functions, Azure Cosmos DB і Azure OpenAI — коордынаваныя через AGF Hub. Не было адкрывана новых служб, і не патрабавалася складная схема обробкі дадзеных. Тое, што дапамогла системе працаваць, — это рэтельна спроектаваныя сховішча памяці, чыстыя межы ў тым, за шта адпаведае кожны інструмент, і мовны модэль, задача якога проста — чытаць зустрэчы, ўбачымаючы людям неабходнасць цэлком самім гэта робіць.

Спадневана літэратура

• Чаму вартасць агентных AI-сістэм растае: модель калькуляцыі вартасці на адміністрацыю — Пяшчотлумачвае, чаму вартасць агентных LLM-сістэм трэба вылічваць за кожны завершаны задачы, а не за кожны вызов, і прыводзіць прыклады архітектурных методаў, такіх як маршрутызацыя модэляў, бюджеты контексту і кэшаванне, для контролю витакоў.
• Розумеўце AI-агенты: цялі, інструменты, память і цыкл агента — Прадступны апіс, як AI-агенты разлічаюцца ад чатботаў, з урахоўваннем ключовых складовых, цыклу прыняцтва рашэнняў, роўняў автонаміі і практычных прыкладаў ўжывання.

RAG vs Agentic RAG vs Graph RAG: Выбір правильной архітектуры выкарыстоўвання дадзейнасці — Дазвольце вам дазнацца, чым неяксуны RAG не паспелівае ў задачах з кальцамі і структураванымі дадзеннямі, а таксама як агентныя цыклы і выкарыстоўвання графа дапамагаюць падрыхтаваць рашэнняя ў разлічных ситуацыях.

Зменшэнне галюцінацый у праграме чат-бота на адной базе RAG для медыцыны — Дазвольце вам дазнацца, як гібрыдны пошук, переранжаванне рэзультатаў і строгая палітыка адмовы ад стварэння некалькіх інформацыйяў дапамагаюць стварыць болей надзеяны чат-бот для медычных даследжэнняў.

Раз'яснення прынцыпа Retrieval-Augmented Generation: Как усунуць прасоўкі ў знаннях LLM — Дазнаецеся, чаму LLMі ствараюць халюцинацыі і становяцца застарэлымі, а пасля пазнаеце па шагох как RAG запоўнюе прасоўкі, фрагментуе інфармацыю, ёй надае додатковых данаяў і такім чынам яе усувае.