Upptäck hur ABAP-utvecklare kan förbättra sina RAP-färdigheter med hjälp av NotebookLM, Googles AI-drivna forskningsassistent.
Den här artikeln är den andra delen av LeverX undersökning av hur NotebookLM och dess integrerade Large Language Model (LLM) kan påskynda inlärningsprocessen för Restful ABAP Programming-modellen (RAP). Du kan hitta den första delen av vår forskning här.
Om du ännu inte är bekant med NotebookLM rekommenderar vi starkt att du läser den första artikeln för att lära dig mer om dess funktioner och potential.
I denna del presenterar LeverX en ny samling avancerade inlärningsscenarier som utvecklats för att fördjupa RAP-förståelsen ytterligare.
Kort ansvarsfriskrivning
Den här artikeln återspeglar LeverX personliga experiment och utvärdering av huruvida det är värt att integrera NotebookLM i ett personligt inlärningsarbetsflöde. Det korta svaret är: ja, det är det - men med vissa förbehåll. Åtminstone är det värt ett försök.
Scenario 1: Gåtor - engagerande kognitivt resonemang
Det här scenariot är i princip motsatsen till "Termdefinitionsspelet" som diskuterades i del 1.
Denna övning engagerar en annan typ av kognitivt resonemang. I stället för att presentera en term för definition bad vi LLM att skapa en beskrivande gåta om en specifik aspekt av ett RAP Business Object (BO). Vår uppgift var att härleda och identifiera det underliggande RAP-konceptet som ingick i svaret.
För att illustrera detta bad våra experter LLM att skapa tre gåtor, som vi sedan försökte lösa. Vi gav en kritisk instruktion om att undvika att inkludera några explicita ledtrådar i gåtans text som skulle kunna avslöja svaret alltför lätt, eftersom modellen ibland introducerar ledtrådar som gör lösningen alltför uppenbar.
Vår uppmaning: skapa gåtor
NotebookLM svarade med gåtor relaterade till validering, ETag och åtgärd.
NotebookLM svar: Skapade gåtor
Vår uppmaning: svara på gåtorna
Medan de flesta av våra svar var korrekta, uppstod en stunds tvekan vid det tredje, då vi var osäkra på om konceptet var Action eller Function. Frasen "manipulera data" missades till en början, vilket visade sig vara en viktig skillnad.
NotebookLM: s svar: gåta, delvis korrekt svar
LLM:s svar identifierade inte bara ett helt felaktigt svar utan även ett delvis korrekt svar. I förklaringen beskrevs både likheterna och skillnaderna mellan Action och Function. Dessutom gavs vägledning om hur man kan tolka gåtan mer effektivt, och frasen "manipulera data" lyftes fram som en kritisk indikator. Denna fras innebär att data ändras, vilket är en definierande egenskap hos en åtgärd i RAP och bidrar till att skilja den från en funktion.
Scenario 2: Förklaring av dokumentationssyntax - avkodning av formellt språk
Att läsa ABAP-nyckelordsdokumentation för RAP kan ibland vara överväldigande, särskilt på grund av den mycket formaliserade syntaxen. Till exempel innehåller de officiella definitionerna av standardoperationer för RAP Business Object, som create, update och delete, ofta ett stort antal modifierare och valfria klausuler. Det kan vara en utmaning att navigera bland alla dessa variationer, särskilt när man försöker få fram den väsentliga innebörden.
Exempel på: RAP BO standardoperationer
För att testa detta användes ett utdrag ur den officiella dokumentationen som indata, vilket LLM analyserade och sedan förklarade rad för rad. Till en början var svaret alltför mångordigt, så vi uppmanade den flera gånger att ge ett mer koncist svar. Slutresultatet blev en mycket mer strömlinjeformad förklaring.
Vår uppmaning: förklara dokumentationssyntaxen
I det här scenariot användes den formella definitionen av en RAP Non-Factory Action som indata.
Utmatningen var:
NotebookLM Svar: Dokumentationssyntax, Åtgärd del 1
I sitt svar gjorde LLM ett berömvärt arbete med att förklara inte bara de RAP-specifika nyckelorden - t.ex. interna eller statiska tillägg relaterade till åtgärder - utan även delar av ABAP-dokumentationssyntaxen, t.ex. användningen av omslutande parenteser (...). Den tog dock inte upp alla aspekter av den formella syntaxen. Konstruktioner som parenteser [], hakparenteser {}, {I} och andra sammansatta notationer utelämnades.
Omvänt kan du göra tvärtom och fråga LLM om den formella syntaxen i dokumentationen av ABAP-nyckelord så att allt blir tydligt för dig.
NotebookLM-svar : dokumentationssyntax, åtgärd del 2
I huvudsak går LLM igenom den tillhandahållna syntaxen och ger en ord-för-ord-förklaring. Det är dock viktigt att granska utdata noggrant. Under experimenten upptäcktes flera fall där formuleringen saknade precision och behövde förfinas. Det rekommenderas att spara svaret som en anteckning, revidera det för att lösa eventuella tvetydigheter eller inkonsekvenser och använda den polerade versionen som en resurs för att stärka din förståelse av RAP.
Scenario 3: Kodförklaring - Förstå logik steg för steg
Målet här är att förse NotebookLM med en kodsnutt och få en detaljerad, steg-för-steg-förklaring tillsammans med en uppdelning av de specifika RAP-koncept som är inblandade. Var och en av dem kan granskas ytterligare individuellt.
Vår uppmaning: förklara koden
Exempelkoden hämtades från beteendeimplementeringen av /DMO/I_TRAVEL_M. I slutändan returnerade LLM en strukturerad genomgång av logiken enligt följande:
NotebookLM svar: сode förklaring, validate_agency
Förklaringen från LLM är i allmänhet sund och följer logiken i koden i rimlig detalj. En formulering stod dock ut som oprecis, särskilt uttalandet: "agency_id finns inte i en annan tabell eller databasresultat som heter agencies_db". Denna formulering känns något konstlad.
Den troliga orsaken är att LLM försökte att självständigt tolka uttrycket NOT line_exists(...), tillsammans med det specifika uttalandet NOT line_exists( agencies_db[ agency_id = travel-agency_id] ), och sedan slog samman de två tolkningarna. Resultatet är en hybridförklaring som saknar klarhet och precision.
Detta exempel belyser en vanlig begränsning av LLM-genererat innehåll, vilket understryker vikten av att kritiskt granska alla resultat. Med detta sagt kan sådana avvikelser vara lärorika, eftersom de leder till ett djupare engagemang i materialet. När du ställs inför en felaktig förklaring kan du faktiskt utmana modellen direkt genom att fråga varför den kom fram till den slutsatsen och använda felet som en möjlighet till lärande.
Scenario 4: RAP-konceptextraktion - Identifiering av viktiga inlärningsområden
Som en fortsättning på föregående fråga begärdes att NotebookLM skulle extrahera och lista RAP-koncept som fanns i kodprovet.
NotebookLM-svar: extrahering av koncept, validate_agency
Detta gav en strukturerad lista över ämnen som var värda att utforska ytterligare. Till exempel kan man nu ställa uppföljningsfrågor som:
- Vad är den transaktionella bufferten? Vilken roll spelar den i RAP?
- Vem implementerar transaktionsbufferten?
- Hur skiljer den sig mellan hanterade och ohanterade implementeringar?
Denna teknik hjälper till att identifiera studieprioriteringar och fokusera din läsning av officiell SAP-dokumentation.
Bonusscenario: Integration med andra LLM:er - utöka din AI-verktygslåda
NotebookLM kan också fungera som en promptgenerator för andra LLM:er som ChatGPT, Perplexity, Gemini eller Claude.
NotebookLM-svar: generering av prompt
Dessutom kan man experimentera med olika frågestilar. LLM kan t.ex. ombes att generera en serie kedjefrågor som successivt fördjupar sig i ett specifikt RAP-koncept. Hela frågeställningen kan skickas in som ett enda block, eller så kan man gå vidare steg för steg och ta itu med varje fråga för sig. Den här metoden är mycket anpassningsbar och kan användas för att generera skräddarsydda frågor för alla LLM-program, till exempel Perplexity, Google Gemini, Claude och andra.
En annan värdefull integrationsstrategi är att använda ChatGPT för faktakontroll. Som tidigare nämnts ger NotebookLM en uppskattad noggrannhet på cirka 90% (baserat på personlig erfarenhet snarare än formell benchmarking). För att säkerställa tillförlitlighet kan du korsreferera dess utdata med ChatGPT och använda det som ett sekundärt valideringslager för att fånga upp potentiella felaktigheter.
ChatGPT-prompt: begäran om faktagranskning
En fusklapp om RAP-numrering finns tillgänglig. Historien om detta fuskblad finns i vår tidigare artikel.
ChatGPT-utdata: resultat av faktakontroll
Tänk också på att du måste kontrollera allt manuellt.
Slutsats
I del 1 beskrevs en fullständig lista över för- och nackdelar och förslag på arbetsflöden. Vänligen hänvisa tillbaka till den för en detaljerad uppdelning.
Här är det viktigt att upprepa kärnprincipen:
NotebookLM är ett kraftfullt AI-förstärkt inlärningsverktyg, men dess resultat måste kritiskt granskas och verifieras före användning. AI är inte en ersättning för utvecklarens expertis utan en multiplikator för dem som är villiga att vägleda den.
Är detta tillvägagångssätt att rekommendera? Ja, med viss försiktighet. Det är definitivt värt att prova, särskilt om du använder LLM som en inlärningspartner snarare än att blint förlita dig på den.
