Dhruv Deshpande egy nyári gyakornoki időszak alatt felépített egy kísérleti rendszert ContextCue néven. A cél az volt, hogy a felvételekből többet őrizzünk meg, mint egy egyszerű átiratot vagy összefoglalót: a beszélgetés szó szerinti részét, a képernyőn megmutatott vizuális kontextust, a meghozott döntéseket, az őket motiváló indoklásokat és a forrást, ahol ezek elhangzottak. A cél egy olyan megosztott kontextus létrehozása, amely a munka során együtt mozoghat a csapatok között.
Miért volt szükség erre
Deshpande tapasztalata szerint a kód sokkal gyorsabban mozgott a csapatok között, mint a mögöttes megértés. A szoftvert kilenc csapat fejlesztette három kontinensen, és gyakran előfordult, hogy egy ügyféltől induló igény több csapatot érintve járt körbe. Mire a munkát végül a mérnökök kezébe adták, az eredeti jelentés egy része gyakran elveszett.
A hagyományos AI-alapú meeting-összefoglalók — például a Microsoft Teams által generált — jellemzően egyetlen találkozóra koncentrálnak, és gyakran csak egy e-mailben érkeznek a résztvevőkhöz. Ez megfelel annak, aki ott volt, de kevésbé hasznos annak a csapatnak, amely később, más időzónában veszi át a feladatot. Egy átirat továbbá kihagyhat fontos vizuális elemeket: a képernyőn való rámutatás, egy oldalelem kiemelése vagy egy workflow rész megmutatása gyakran hordoz olyan jelentést, amit a szavak önmagukban nem adnak vissza.
Egy egyszerű példa
Egy ügyfél kérheti, hogy legyen „gyorsabb egy riport”. Az ügyfél megosztja a képernyőt, rámutat egy lassan nyíló oldalra, és elmondja, hogy a vezetők minden reggel megnyitják azt. Az eredeti csapatnál ez azt jelenti: gyorsabban nyíljon az oldal. Két nappal később egy másik csapatban, más időzónában ugyanazt a „faster report” megfogalmazást úgy értelmezhetik, hogy a riport végrehajtási idejét kell csökkenteni (backend munka). Mindkét találkozó összefoglalója ugyanazt a mondatot tartalmazhatja: "Make the report faster.", miközben két különböző értelmezés jön létre — és a különbség csak akkor válik nyilvánvalóvá, amikor az ügyfél meglátja az eredményt.
Sports hasonlat: az esemény és a környezete
Deshpande a sport példáján keresztül világította meg a problémát: egy kapu előtti helyzet leírása (lőtt, perc, játékos) hasznos tény, de egy edző a felvételből a környező eseményeket is látja — mikor adták túl korán a passzt, melyik lábra kényszerítették a csatárt, ki mozgott el, hogy helyet nyisson. Jake M. Hofman, Daniel G. Goldstein és David M. Rothschild Harvard Business Review-cikkében az AI-t három szerepbe sorolták — „steroid”, „sneaker” vagy „coach” —, és a „coach” metafora ragadt meg: az AI nemcsak produktivitást növelhet, hanem jobb döntéseket segíthet hozni az előzmények és bizonyítékok felidézésével. Ezt szerette volna ContextCue elérni a csapatoknál.
Mit épített Deshpande
ContextCue egy meeting-felvétellel indul. A médiakezelést FFmpeg végzi, a beszédátírást Faster-Whisper készíti el, és az átirat időbélyegzett szegmensekben marad, hogy később vissza lehessen mutatni pontos pillanatokra. A rendszer a megosztott képernyőből kiválasztott képkockákat is elemzi egy látásmodell, például Qwen VL használatával, ezzel megőrizve a vizuális kontextust.
A kimenet nem a találkozóra, hanem a kérésre vagy döntésre szerveződik. Példa formátum:
Request: Faster report
- What the customer meant: The report page opens too slowly. (Source: customer call, shown on screen)
- Why it matters: Managers open it before a morning meeting. (Source: customer call, spoken)
- What was planned: Make the report finish running sooner. (Source: team planning meeting)
- Open issue: The current plan does not match the original request.
A formátum egyszerű és Markdown-alapú, mert egy ember könnyen elolvashatja, egy nyelvi modell használhatja, és verziókövetéssel tárolható anélkül, hogy speciális felületre lenne szükség. Ha egy későbbi találkozó ugyanarról a kérésről szól, a lap frissíthető ahelyett, hogy új, elszigetelt összegzés jönne létre: a memória egysége így a "meeting" helyett a "topic" lesz.
Mire jó ez a termékfejlesztésben
Egy termékmenedzser felhasználói történet írásakor gyakran széttagolt forrásokból dolgozik: ticketek, meeting-megjegyzések, ügyfélvisszajelzés és mérnökökkel folytatott beszélgetések együtt adnak teljes képet. Ha az AI modellnek csak az utolsó találkozó összefoglalóját adják, akkor a modell csak egy szeletet lát a történetből. Egy ContextCue-oldal ehelyett az eredeti ügyfélkérést, az üzleti indokot, későbbi technikai korlátokat, termékdöntéseket és megválaszolatlan kérdéseket is tartalmazhat, ami jobb kiindulópontot ad a modellnek a user story generálásához.
A különbség nem a modellben van, hanem a bemenet minőségében.
Hogyan növekszik a kontextus
Új találkozók vagy frissítik a meglévő topic-oldalt, vagy újakat hoznak létre; idővel téma-szerinti nyomvonal jön létre arról, hogyan alakult a munka. A tárolt kontextus kereshető: Deshpande beágyazásokat (embeddings) és Qdrantot használt a releváns korábbi részek előkeresésére. Egy kérdés, mint "What did the customer mean by faster?" visszaadhatja a választ a megfelelő találkozóval és időbélyeggel együtt.
Egyes kérések egyszerűbbek ("Find Tuesday’s meeting" — keresés), mások összetettebbek ("Why did we change this requirement?" — több érintett találkozót kell kombinálni). ContextCue a Model Context Protocol (MCP) révén különböző lekérdezési műveleteket tehet elérhetővé, hogy egy nyelvi modell kiválaszthassa a feladathoz megfelelő eszközt.
Miért érdemes megőrizni a rögzített beszélgetéseket
Deshpande hivatkozik az Erik Brynjolfsson, Danielle Li és Lindsey Raymond által szerkesztett 2025-ös "Generative AI at Work" tanulmányra (Quarterly Journal of Economics), amely szerint egy ügyfélszolgálati munkát segítő AI-asszisztens a kevésbé tapasztalt munkavállalók eredményét javította leginkább, részben múltbeli beszélgetésekből származó tudás előhívásával. Egy cégben sokféle tudás sosem válik formális dokumentummá: megjelenik magyarázatokban, ügyfélhívásokban, tervezési megbeszélésekben, példákban és kis döntésekben. A rögzített találkozók egy ilyen, már létező tudásforrást jelentenek.
Első előnyök és gyakornoki nézőpont
Gyakornokként a legnehezebb dolog gyakran az, hogy megértsük, miért hoztak korábban egy adott döntést. A forráskód elolvasható, de nem mindig nyilvánvaló, miért választottak adott dizájnt. A jegy leírhatja mit kell építeni, de nem adja vissza azt a beszélgetést, ami a döntéshez vezetett. A közös kontextusréteg egyes kérdések megválaszolását könnyebbé teheti anélkül, hogy újabb találkozót vagy üzenetet kellene kezdeményezni.
Működött-e? És mi a nehézség még
A tesztelés eddig korlátozott volt. Deshpande egy kis kérdéshalmazzal dolgozott, ahol előre ismert volt a helyes forrás; ContextCue az esetek nagyjából kilencven százalékában (9/10) elsőként találta meg a helyes forrást, és minden tesztkérdésnél a top három találat között volt.
Ez bíztató volt, ugyanakkor rávilágított a gyakorlati nehézségekre:
- Egy vállalat több különböző meeting-eszközt használhat.
- Különböző csapatok eltérő szabályokat tarthatnak a felvételekről és azok megosztásáról.
- Bizonyos kontextusok vállalaton belül láthatók kell legyenek, míg mások csapaton belül maradnak.
- Az embereknek tudniuk kell, hogy rögzítik-e a találkozót és hogyan használják fel a felvételeket.
- Időbeli változások kezelése: egy döntés márciusi határozata áprilisban megváltozhat — a régi döntés nem tűnhet el, mert elmagyarázza az útját, de a rendszernek egyértelműen jeleznie kell, hogy az új döntés felülírta-e a régit.
Ezek jogi, jogosultsági, tulajdonosi és bizalmi szabályokat igényelnek, amelyeket ContextCue nem old meg önmagában.
Hova vezethet ez
Deshpande számára a legfeltűnőbb különbség az volt, hogy az AI milyen mértékben átalakította a kódírást, de viszonylag kevés hatása volt a kódolás előtti átadásokra és megértésre. A mérnökök már erős eszközökkel rendelkeztek, amikor egy követelmény világos volt; a lassabb rész gyakran az volt, amikor csapatok megpróbálták megérteni, mit kell építeni és miért, majd átadni ezt a megértést másoknak.
ContextCue Deshpande első kísérlete volt ezen a területen. A projekt még kicsi, és a technikai megoldásnak változnia kell, ha éles vállalati környezetbe kerülne. Az ötlet hasznos: a meeting-felvételek többé lehetnek, mint archívumok — közös történetet őrizhetnek arról, hogyan jutott el egy csapat egy döntésig. Ha az AI képes ezt a történetet megőrizni és a következő csapathoz továbbvinni, akkor nemcsak a kódolás sebességét javíthatja, hanem azt is, hogyan visznek megértést a szervezet különböző részei között.



