Experimenteren met generatieve AI - Development-iteratie #294

In de afgelopen sprint hebben we geëxperimenteerd met generatieve AI om te onderzoeken wat voor Tweakers zou kunnen werken en waar we (technisch) tegenaan lopen. Daarnaast hebben we het grid van de Pricewatch verbreed en een nieuw ontwerp getest.

AI-toepassingen op Tweakers

Om meer te leren over generatieve AI hebben twee tijdelijke scrumteams, de Turing Titans en de Quantum Questers, zich in sprint #294 volledig gestort op het experimenteren met mogelijke toepassingen. Hierbij hebben we uitsluitend gewerkt met content die door onszelf geschreven of gemaakt is, en dus niet met content van gebruikers.

Binnen DPG Media is een 'AI-omgeving' beschikbaar waarvan alle collega's gebruik kunnen maken. Voor bijvoorbeeld Tweakers-redacteuren zit dit echter niet in hun standaardworkflow, omdat het een andere plek is dan waar ze hun artikelen schrijven. Om te ontdekken hoe eenvoudig het zou zijn om de AI-omgeving vanuit DSP (de achterkant van Tweakers) aan te roepen, hebben we een aantal proof-of-concepts gedaan. Deze uitwerkingen worden niet naar productie gebracht, waardoor de code niet aan onze gebruikelijke kwaliteitseisen hoeft te voldoen. Hierdoor konden we meer doen in dezelfde tijd en dus sneller leren.

Zo hebben we geleerd dat het maken van de juiste prompt een samenwerking moet zijn tussen de (interne) gebruiker en de devver. Er gelden namelijk niet alleen inhoudelijke eisen voor het resultaat van een large language model, maar ook technische, zoals het resultaat teruggeven in JSON-formaat. Daarnaast heeft een llm natuurlijk niet alle kennis van de data van Tweakers. Als een redacteur een achtergrondartikel wil schrijven en daarvoor een samenvatting wil lezen van wat we tot nu toe op Tweakers hierover hebben geschreven, moeten we de llm wel van de juiste context kunnen voorzien. Dit vereist een manier van het bevragen van onze database die we nog niet ondersteunen.

Tot slot liepen we tegen beperkingen van de gebruikte llm's zelf aan. Zo zagen we bijvoorbeeld dat er telkens andere output verscheen bij het opnieuw uitvoeren van dezelfde opdracht, ondanks expliciete instructies om hierop te letten en het aanpassen van de instellingen hiervoor. Voor het genereren van tekst hoeft dat niet direct een probleem te zijn, maar in een taak waarbij productspecificaties vergeleken moeten worden, blijkt AI hiervoor niet geschikt.

Breder grid in Pricewatch

Begin augustus hebben we het grid verbreed in een groot deel van de Pricewatch, waaronder op de pagina's waar je producten kunt filteren en vergelijken. Deze stap is onderdeel van een groter project om de Pricewatch zowel visueel als onder de motorkap te verbeteren. Eerder al hebben we de technische werking van de filters vernieuwd. Met het verbrede grid maken we optimaal gebruik van de schermruimte op de desktop. Dit biedt mogelijkheden om meer en relevantere informatie te tonen.

In navolging van de verbreding van het grid hebben we een a/b-test gedraaid met visuele veranderingen. In deze test hebben we gezien dat de veranderingen niet goed uitpakken op mobiele schermen. Op andere schermformaten presteerde de nieuwe lay-out significant beter dan het huidige ontwerp van de Pricewatch, met enkele aandachtspunten. Meer daarover kun je lezen in dit topic. In een volgende iteratie gaan we het nieuwe ontwerp verder verbeteren en vervolgens weer testen.

Reacties van HQ onder artikelen

In de reacties onder artikelen hebben we de herkenbaarheid verbeterd van mensen die voor Tweakers werken. Tot voor kort gaven we in de reactiedraadjes alleen een 'auteur'-label weer. Nu zijn alle mensen die voor Tweakers werken herkenbaar. Dat doen we net als op het forum door het gebruik van een rode nickname en waar nodig ook de weergave van een functietitel daarbij.

Dit maakt het in de reacties bijvoorbeeld duidelijker dat een reactie is geplaatst door een Tweakers-redacteur als dat geen reactie is van de auteur van dat artikel. Ook is het daarmee consistent met hoe je op het forum gewend bent om moderators en andere mensen die voor Tweakers werken te herkennen.

En verder

• In Vraag & Aanbod hebben we de tips om veilig te handelen verduidelijkt. Bij elke advertentie wordt nu een blauw blok met deze tips getoond. Met zowel zichtbare als onzichtbare maatregelen proberen we de kans op oplichting zoveel mogelijk terug te dringen.
• Op het prijsdalingenoverzicht is de maximale referentieperiode verhoogd naar 30 dagen. Dit is in lijn met de aangescherpte regels van de ACM, die webwinkels aanpakt als ze nepkortingen communiceren.
• Naar aanleiding van de invoering van de tijdslimiet op het wijzigen van forumposts ontvangen gebruikers voortaan een notificatie wanneer de 'edit lock' is opgeheven. Gebruikers kunnen voor specifieke topics zo'n unlock aanvragen via ons moderatieteam.
• Benchmarkgrafieken hebben ondersteuning gekregen voor eenheden met een logaritmische schaal. Zo is nu bijvoorbeeld in de grafieken zichtbaar dat het verschil tussen 30 en 40dB in werkelijkheid een verdubbeling is en wordt de eenheid erbij getoond.
• Uiteraard hebben we ook weer een aantal bugs geplet. Zo werd er onder andere een verkeerde tekst getoond in bepaalde prjisalerts, werden er onbedoeld Pricewatch-filters aangezet, werkten de dealsfilters niet naar behoren, ging de positionering van banners in artikelen in sommige gevallen fout en bleken modbreaks uit beeld te lopen.

Reacties (30)

[mOrPhie]

Mooi dat jullie zijn gestart met het experimenteren met AI, maar ik zou wel starten met welk probleem je op zou willen lossen, want dat geeft wat richting aan de oplossing in plaats van AI om het AI. Is daar over nagedacht? Dingen waar ik bijvoorbeeld aan zou denken:

• Efficientie in het moderatiemodel van Tweakers: bijvoorbeeld een LLM die reacties beoordeeld op ons moderatiebeleid en voor promods alvast een indicatie afgeeft.
• Zoeken op een forum met lange topics is lastig. Een vraag stellen of in gesprek gaan met een AI over een lang topic zou kunnen helpen.
• Omdat de FP steeds meer verbreed omwille van het vinden van meer publiek, kom ik ook steeds meer content tegen waar ik zelf weinig mee heb. Wellicht kan AI helpen de FP meer persoonlijk op mij af te stemmen. Deze zou ik wil opt-in houden.

[Kees]

Vanwege legale redenen en het feit dat we openai gebruiken hebben we bewust ervoor gekozen om niets met 'user generated content' te doen (ook al heeft openai dat allang allemaal gejat gescraped).

Het doel van deze experimenten was niet zozeer om iets op te leveren, maar om te onderzoeken wat de mogelijkheden zijn en hoe we het zouden kunnen gebruiken, hoe de performance is, wat het mag kosten, hoe we het in de code zouden kunnen verwerken enzovoorts.

Een FP maken speciaal voor jou van openai zou tergend langzaam zijn als we dat met elke pageview zouden moeten maken en bovendien erg duur zijn

[Reactie gewijzigd door Kees op 10 september 2024 10:06]

[mOrPhie]

Vanwege legale redenen en het feit dat we openai gebruiken hebben we bewust ervoor gekozen om niets met 'user generated content' te doen (ook al heeft openai dat allang allemaal gejat gescraped).

Volledig eens natuurlijk, maar de tekst van @jelle. deed vermoeden dat het om een DPG-managed omgeving ging. Dat moet je me vergeven.

Het doel van deze experimenten was niet zozeer om iets op te leveren, maar om te onderzoeken wat de mogelijkheden zijn en hoe we het zouden kunnen gebruiken, hoe de performance is, wat het mag kosten, hoe we het in de code zouden kunnen verwerken enzovoorts.

Sure. Helemaal goed natuurlijk. Maar het helpt als je weet waar je het voor doet.

Een FP maken speciaal voor jou van openai zou tergend langzaam zijn als we dat met elke pageview zouden moeten maken en bovendien erg duur zijn

Ja, dat zou ik dan ook zeker niet elke pageview doen. En er zijn meerdere manieren te bedenken natuurlijk. Bijvoorbeeld door de LLM te vragen welke tags bij mij passen en daarop automatisch filteren.

[ACM]

Het is ook een door DPG-managed omgeving. Maar die heeft vooral als doel om dan te beperken wat OpenAI met de "prompts" mag doen.

Dat staat los van of wijzelf zomaar wat met de content van gebruikers mogen. Onze juristen waren niet voldoende overtuigd dat dat binnen de huidige Algemene Voorwaarden mag, dus gaven ze ons het advies om daar nu niet aan te komen.

Sure. Helemaal goed natuurlijk. Maar het helpt als je weet waar je het voor doet.

We hadden diverse gebruikerswensen geformuleerd. Maar deze experimentele sprint was ook bedoeld om te bekijken wat daar voor nodig was. Helaas bleken de initiële wensen deels te lastig en/of door eerder genoemde juridische beperkingen toch niet kon.

Normaliter doen we die stappen niet allemaal tegelijk in een sprint. Maar deze specifieke situatie wel.

[Robbierut4]

Onze juristen waren niet voldoende overtuigd dat dat binnen de huidige Algemene Voorwaarden mag, dus gaven ze ons het advies om daar nu niet aan te komen.

Dus, tijd voor nieuwe algemene voorwaarden die je verplicht moet accepteren waarbij alle gebruikersdata gebruikt kan worden?

[ACM]

Dat weet ik niet, het kan ook zijn dat ze tot de conclusie komen dat het wel mag. Maar die vraag was simpelweg nog niet met een volmondig 'ja' beantwoord, waardoor dat genoemde advies kwam

[Caelorum]

De vraag is dan ook of je dit moet uitbesteden aan een extern bedrijf, of dat je een server zelf neer zet, met een wat sneller, minder resource intensieve LLM. Want sentimentanalyse, checken of iets aan bepaalde voorwaarden voldoet, enz. kan zelfs met de 'mindere' llm modellen wel.

En diensten zoals Azure OpenAI zijn een drop-in replacement voor openai's api, maar met de garantie dat de data niet wordt gebruikt door Microsoft. Dat gezegd hebbende, zou openai zelf de input ook niet moeten gebruiken voor traningsdoeleinden (wel voor als de politie het wil hebben)

[Reactie gewijzigd door Caelorum op 10 september 2024 10:25]

[Kees]

Klopt helemaal, maar we hebben in eerste instantie gekeken naar wat er mogelijk is met generatieve ai omdat ons moederbedrijf daar al een omgeving voor heeft. Om het niet al te ingewikkeld te maken hebben we nog even niet naar lokale oplossingen gekeken.

[Verwijderd]

Soms moet je gewoon experimenteren en helemaal geen doel hebben een probleem op te lossen. Gewoon een beetje aankloten, dingen uitproberen, zo kom je aan een hoop nieuwe ideeën en inzichten.

[mOrPhie]

Is ook zo. Daar is deze site groot mee geworden. Waarom? Omdat het kan.

Maar imho geldt dat meer voor 's avonds en in het weekend en voor jezelf. Niet als je significant developmentwerk doet in een team. Dan helpt wat richting.

[P_Tingen]

Het is juist mooi dat een werkomgeving hier ook ruimte voor biedt. En zo lang duidelijk is dat het experimenteren is, is er niets aan de hand. Je kan het time-boxen om te voorkomen dat het uit de hand loopt, in een aparte omgeving doen om te voorkomen dat de code doorlekt in productie en zo als team bedenken wat voor nieuwe dingen je kan doen

[Verwijderd]

Nee hoor, juist mooi als een bedrijf een team de vrije loop laat. Dan komen juist de grote veranderingen/ontwikkelingen. Anders wordt alles maar ietsje beter dan een vorige versie, geen innovatie.

[jelle.]

Bedankt voor je suggesties! Zoals @Kees aangeeft was het doel hier om te leren, dus hebben we - anders dan dat we normaal werken - use cases bij AI-toepassingen gezocht. Gelukkig waren dat niet compleet onzinnige dingen en raakten ze wel deels aan bestaande gebruikersproblemen Voor een eventueel vervolg zouden we inderdaad een bestaand gebruikersprobleem als vertrekpunt nemen, waarbij je er dan ook achter kan komen dat AI helemaal geen geschikte oplossing is We weten nu in elk geval waar we technisch tegenaan kunnen lopen en daar was het ons om te doen.

[DaFeliX]

[...] bijvoorbeeld een LLM die reacties beoordeeld op ons moderatiebeleid en voor promods alvast een indicatie afgeeft.

Dit kan je waarschijnlijk beter - en goedkoper - met een 'gewone' machine learning doen, dan een LLM hiervoor gebruiken. Een LLM kan dit waarschijnlijk prima, en je kunt er snel mee itereren om wat verschillende dingen uit te proberen. Ik denk alleen dat het nogal een overkill is. Een eigen getraind model zou waarschijnlijk veel goedkoper en sneller zijn.

[SPee]

Ik zou eerder beginnen met ondersteuning van de artikel schrijvers of andere backend gerelateerde onderwerpen. Niet meteen beginnen met iets waar de volledige t.net bezoekers gebruik van (kunnen) maken, maar eerst rustig in een beperkt context kijken wat de impact is. En dan experimenteren of je hun werk gemakkelijker en/of sneller kunt maken.

Bijvoorbeeld:

• Samenvatting van het onderwerp of bedrijf waar het om gaat, met links naar gerelateerde (t.net, DPG, wikipedia) artikelen.
• Hulpmiddel voor taalgebruik (hoewel ook partijen zijn die dit als product aanbieden)

[Creesch]

In navolging van de verbreding van het grid hebben we een a/b-test gedraaid met visuele veranderingen. In deze test hebben we gezien dat de veranderingen niet goed uitpakken op mobiele schermen. Op andere schermformaten presteerde de nieuwe lay-out significant beter dan het huidige ontwerp van de Pricewatch, met enkele aandachtspunten.

Hier zal waarschijnlijk wel geen antwoord op komen, gezien de reacties in het genoemde topic. Maar, welke meetpunten hebben jullie gebruikt om tot de dikgedrukte conclusies te komen?

Zijn het verbeteringen voor tweakers (conversie, doorklik rate, etc) of voor de gebruiker (daadwerkelijk informatie voorziening, gebruiksvriendelijkheid, etc). Ik kan me namelijk heel goed voorstellen dat er naar meer producten is doorgeklikt tijdens jullie test, simpelweg omdat informatie in het overzicht niet helder meer zichtbaar was

Gezien de feedback in het topic zou ik zeggen dat er een flink aantal verbeterpunten zijn, niet enkele.

Sowieso bekruipt me bij deze A/B testen vaak het gevoel dat ze dusdanig groot in scope zijn dat ik me niet kan voorstellen dat je daadwerkelijk goed kan testen welk onderdeel van je verandering zorgt voor ander gedrag. Ook hier is dat het geval geweest met zoveel veranderingen in één test dat ik me haast niet kan voorstellen dat dit een zuivere A/B test is geweest.

Enfin, mijn 2ct. Ik hoop oprecht dat ik het mis heb en de volgende iteratie daadwerkelijk beter is en geen verarming ten opzichte van het huidige overzicht.

[jelle.]

Vooropgesteld: ons doel is om de Pricewatch te verbeteren en daarbij gaan gebruiksvriendelijkheid en performance hand in hand. Neem het type verkeer dat we naar aangesloten webshops sturen, we zijn er juist bij gebaat dat dit van "hoge kwaliteit" is. Dat betekent dus dat gebruikers aan onze zijde ook zo goed mogelijk geholpen moeten worden in de Pricewatch, of zelfs nog eerder in hun oriëntatieproces (zoals reviews). Wij redeneren dus niet vanuit verbeteringen voor gebruikers "of" voor Tweakers, het één werkt immers door in het ander. Natuurlijk wringt het soms, bijvoorbeeld als het gaat om promoties of advertenties in de Pricewatch, maar daar proberen we dan ook altijd een balans in te vinden.

Wat betreft je vraag over metrics kijken we behalve de clickouts naar webshops ook naar het verlaten van de Pricewatch, de pageviews op de prijzenpagina, specificaties en reviews, het gebruik van de vergelijkingslijsten en nog meer. Maar eigenlijk nog veel belangrijker is dat we ook op andere manieren testen. Voorafgaand aan deze a/b-test (en de vorige testronde) hebben we een usabilitytest gedaan met gebruikers om kwalitatieve inzichten op te halen. In zo'n test komen we weer dingen tegen die niet altijd in data zijn uit te drukken, net als soms de feedback die we via het forum krijgen. Soms leidt deze feedback tot aanpassingen in het ontwerp die we vervolgens weer gaan testen, soms moeten we eerst beter begrijpen wat erachter zit en soms moeten we simpelweg een keuze maken. Je kunt je voorstellen dat daadwerkelijk vertoond gedrag in een a/b-test (met honderdduizenden gebruikers) dan doorslaggevend kan zijn. Mits de data en test zuiver zijn natuurlijk, dat ben ik helemaal met je eens

Hopelijk geeft dit wat meer inzicht in hoe we werken en vooral dat we niet over één nacht ijs gaan.

[rens-br]

In de reacties onder artikelen hebben we de herkenbaarheid verbeterd van mensen die voor Tweakers werken. Tot voor kort gaven we in de reactiedraadjes alleen een 'auteur'-label weer. Nu zijn alle mensen die voor Tweakers werken herkenbaar. Dat doen we net als op het forum door het gebruik van een rode nickname en waar nodig ook de weergave van een functietitel daarbij.

@jelle. Wat is de definitie van 'waar nodig'? Kortom wanneer wordt de functietitel wel of niet getoond?

[Reactie gewijzigd door rens-br op 10 september 2024 10:44]

[CH4OS]

Hier op voortbordurend, ik mis om heel eerlijk te zijn de meerwaarde hiervan. Ik ben namelijk bang dat het voor een tweedeling gaat zorgen op de FP ("zij" vs "ons") en dat lijkt mij best zonde. Ook zullen er vast gebruikers zijn die er zaken mee denken te kunnen/mogen ontlenen, want "medewerkers van Tweakers zeggen...". Nu weet ik niet of dat wenselijk is, maar dat lijkt mij niet.

[Reactie gewijzigd door CH4OS op 10 september 2024 12:23]

[DjoeC]

Ik ben het hier wel een beetje mee eens. Ik kan me voorstellen dat Tweakers medewerkers (in welke vorm/functie dan ook) niet altijd NAMENS tweakers reageren maar op persoonlijke titel.

Ik zou vooral de min of meer formele Tweakers reacties gemarkeerd willen zien, danwel een automatische vink dat het om een persoonlijke reactie gaat. Een devver zal - naar ik aanneem - nooit namens Tweakers regeren op een bericht over de nieuwbouw van een kerncentrale maar zou daar best kunnen/mogen reageren. Toch?

[Julianvvz]

Een sprint hieraan spenderen kan ik als ex-product owner en nu AI consultant wel waarderen. Enkele tips:
- Je kan ChatGPT forceren bepaalde JSON formats te gebruiken (zie: https://openai.com/index/...tured-outputs-in-the-api/)
- Als je de LLM meer achtergrond informatie wilt laten gebruiken als context (b.v. het gehele Tweakers Forum), dan kan je denken aan Retrieval Augmented Generation (RAG) toepassingen, of het model die je gebruikt pre-trainen op de data. Hiervoor zijn verschillende oplossingen.

Zoals aangegeven is het uiteraard het belangrijkste om een bestaand probleem te proberen op te lossen i.p.v. te zoeken naar een probleem voor je nieuwe fancy tool. Echter kan het ook helpen om te beginnen met een 'technology push' zoals het hier lijkt.

[ACM]

Dat je echt structured data kan geven hebben we gemist, dus dat was inderdaad nuttig geweest om vooraf te weten

Voor RAG wisten we wel dat dat bestond en hebben we uiteindelijk een PostgreSQL + Pgvector gevuld met via Cohere gegenereerde chunks/embeddings op basis van onze artikelen. En daar weer prompts mee samengesteld.

[Reactie gewijzigd door ACM op 10 september 2024 10:38]

[BramVroy]

Uit curiositeit, met welke LLMs hebben jullie getest? Toevallig een GEITje-variant of Fietje? Of vallen jullie terug op betaalde services van BigTech? En gebruiken jullie dan outlines om gestructureerde output terug te geven?

[Reactie gewijzigd door BramVroy op 10 september 2024 10:22]

[ACM]

We hebben ons beperkt tot wat intern al aangeboden werd via een afgeschermde laag rond OpenAI door DPG.

Dus wat llm's betreft was het vooral GPT4o en ik heb zelf nog gekeken of de mini-variant inderdaad heel andere resultaten gaf (ja: minder "mooi"). En van outlines wisten we niet dat het bestond. Dat was ook een van onze learnings; dat het lastig is om als "beginner" al dat soort handige dingen te ontdekken

[Skit3000]

In de reacties onder artikelen hebben we de herkenbaarheid verbeterd van mensen die voor Tweakers werken.

Dat wordt mijn custom-CSS voor
compactere reacties op de frontpage weer aanpassen, maar goede toevoeging!

[Forte]

Goed om te lezen dat jullie wel experimenteren met AI maar het gelukkig niet klakkeloos toepassen "omdat het kan" Generatieve AI blijft een toffe ontwikkeling alleen is het zo jammer om te zien dat meerdere partijen het nu een beetje halfbakken implementeren omdat ze voor hun gevoel iets met AI moeten doen. Laat ik verder maar niet beginnen over de duizenden AI startups die niet meer dan een OpenAI wrapper met vooraf ingestelde prompts zijn.

Misschien dat korte TLDR snippets onderaan/bovenaan artikelen nog wel een interessante use case kan zijn voor AI op Tweakers? Dus niet complete artikelen laten genereren, maar puur een extractie van de content die jullie zelf schrijven?

[Skit3000]

@jelle. hadden jullie specifieke ideeën die jullie uit wilden werken met AI? Zodra er iets om de hoek komt kijken dat meer analyse vereist dan enkel tekst (zoals bij productvergelijken) wordt het inderdaad lastiger voor LLMs om hier iets mee te doen, maar je zou (bij ChatGPT in ieder geval) wel function calling kunnen gebruiken om de LLM een probleem in kleinere stukjes op te laten lossen, al kun je met de gestructureerde data uit de pricewatch waarschijnlijk ook zelf al direct de juiste data verwerken voordat je het aan de LLM geeft en bijvoorbeeld laat beschrijven wat het verschil is tussen een nieuw en oud model videokaart of iets dergelijks.

[Verwijderd]

Volgens mij ligt het er ook aan welk model gebruikt wordt. Om een consistente output te krijgen heb je een paar instellingen, waaronder de seed die constant moet zijn, dan zou volgens de documentatie die ik heb gelezen, altijd hetzelfde antwoord gegeven worden.

[P_Tingen]

Ik zou in de podcast best iets meer willen horen over deze AI-experimenten, @WoutF & @arnoudwokke ...