Or, in which Generative AI meets OER meets Reusable Learning Objects.
I’ve been working on fleshing out the architecture for Open Educational Language Models and have reached a point where it’s time to share a progress update. I’ve discussed the idea with several people and gotten some really excellent feedback, and building prototypes has helped me further refine my thinking.
Lessons from the Past: Separating Content from Presentation
I created my first website in the early 1990s, back when all we had was HTML. There was no CSS, no Javascript. Actually, there weren’t even images in those first webpages. I was just surfing the web with Lynx, hitting the / key to read the source code of other people’s sites, and learning how to build my own. The introduction of CSS – and the idea of creating a clean separation between content and presentation – was a revelation that totally changed my thinking and the way I designed website. (In fact, my first print publication was a series of chapters about CSS in a book on “Dynamic HTML” in the late 90s.)
In working on the OELM prototype, I realized that there was an opportunity to do something similar to HTML and CSS with the OELM architectural design. If you think about learning activities as a way of “presenting” learning content, then you can start thinking about how to cleanly separate learning content from learning activities.
Now, it’s not anything new to create content without thinking about the activities learners might engage in as they try to learn that content. For example, people typically write textbook chapters without thought for learning activities beyond reading and highlighting. However, it is wildly different to try to imagine creating learning activities without making any specific references to content. For example, how would you write a practice quiz without referring to any content? How would that even work?
It turns out this can work pretty well in much the same way HTML and CSS do – via incorporation by reference. To begin, you (1) create some content that includes a list of learning objectives and aligned expository information. Then you (2) write a learning activity description that does not include any content itself but includes references to content that will be appended just-in-time (the way HTML files point to CSS files). Then you (3) create a coordination service that merges the content and the activity description with a system prompt (and perhaps some custom instructions) before delivering the final, complete prompt to the model to kick of a specific learning activity on a specific topic.
As with all things, an example should make this easier to understand.
A Toy Example
Here’s a toy example from a hypothetical university microeconomics course.
The system prompt stub for the course, in a file called system_prompt.txt, might include:
You are an upbeat, supportive, empathetic economics tutor. Your greatest joy is helping students understand economics concepts. Help the user – who is a student in a college microeconmics course – as follows.
A content file called demand.txt might include:
<objectives>
– Explain demand and the law of demand
– Identify and explain a demand curve
…
</objectives><content>
Demand refers to the amount of some good or service consumers are willing and able to purchase at each price. What a buyer pays for a unit of the specific good or service is called the price. The total number of units purchased at that price is called the quantity demanded. The inverse relationship between price and quantity demanded is called the law of demand…
</content>
A learning activity, specified in the file retrieval_practice.txt, might include these instructions:
I’ve just finished studying and want to do some retrieval practice. Give me a quiz where you ask me one question for each learning objective specified in the <objectives> section. Ask me one question at a time and wait for my answer. After each answer, give me feedback on my answer and explain anything it seems like I don’t understand. Then ask if I’d like additional information on that question. When I indicate I’m finished, ask me the next question.
Use the information in the <content> section when evaluating my answers and providing feedback. If I get distracted or try to change the topic of our conversation, politely but firmly refuse to talk about topics not contained within the <content> section.
A complete OELM would include many other content files – a supply.txt, equilibrium.txt, elasticity.txt, utility.txt, etc. – enough content to cover an entire course. From the perspective of a traditional textbook, one of these files might correspond to an entire chapter, or it might correspond to a single section in a chapter. (Questions about our old friend granularity have returned, this time wrt the model’s context window)! This content should be concise, hitting just the high points – more like a chapter summary than an entire chapter. Remember, the purpose of this content is not to directly support student learning – students will never see these files. The purpose of the content is to keep model responses accurate and reduce hallucination. This means the content can be much more to the point than typical OER.
A complete OELM would also include several other learning activity files – for example, a reciprocal_teaching.txt, worked_examples.txt, debate.txt, flash_cards.txt, etc.
Separated out like this, content and activities can be mixed and matched in both directions. For example, a learner can use different activities (like retrieval practice, reciprocal teaching, or worked examples) to study a single topic (like supply). Similarly, they could reuse a single activity across multiple topics (sometimes even across multiple courses). Cleanly separating content from presentation (like HTML / CSS does) greatly increases the reusability of the learning content and the learning activities.
And of course the “open” in OELMs means that the model weights, system prompt stub, content for context augmentation, learning activity prompts, and code for the coordination service are all openly licensed. If you don’t like any of these the way you find them, you can revise or remix them before reusing them.
From an open education perspective, the key characteristic of this design is that it harnesses the power of generative AI using learning content (OER) and activity designs (also OER) that an average instructor can create, revise, remix, and share without any special technical knowledge. In other words, the OELM design balances and combines the technical power of generative AI with the participatory power of OER.
Observations from Playing with the Prototype
Building and playing with the prototype has been extremely instructive. Here are a few observations.
You can imagine at least two ways of interacting with such a system. The first we might call “exploratory.” Here the learner sees a list of courses, topics, and study activities, and chooses what to study and how. I like this pattern because it exposes learners to names and explanations of different evidence-based study techniques, and has the potential to make them more effective learners even when they’re learning information for which an OELM isn’t available.
The second we might called “designed.” Here the instructor or instructional designer pre-selects combinations of topics and activities and creates links to these bundles and places them strategically throughout the course. When the learner clicks on a link, the specified activity simply begins.
You’ll notice that the OELM design explicitly sidesteps RAG. Rather than performing searches over content embeddings and hoping the right content is retrieved for context augmentation, the designer or instructor does this alignment step manually by associating specific OER with a topic. Again, here we’re trading off some more advanced technical capabilities of LLMs in order to keep the system simple enough for average instructors to work with.
While there may be some overlap across courses (for example, retrieval practice is broadly applicable), the list of learning activities will differ from course to course because effective pedagogy differs from course to course. The specific activities created or reused for each course should be selected and created based on SoTL and other research about effective pedagogy in the discipline. In other words, there will be some discipline-specific activities in each OELM that are not very reusable but are critical for learning in that discipline.
In this design, the specific language model being used can be swapped out easily as it’s simply an API call. Current SOTA models that can run locally (e.g., Llama 3.1 8B or a DeepSeek R1 distillation) do pretty well as part of this setup. The next generation of open weights models (e.g., Llama 4) should put us in a place where OELMs can be run very effectively on local hardware, which is a key part of the OELM strategy, and another reason for preferencing simpler designs (e.g., avoiding RAG).
As currently conceived, OELMs supplement existing learning materials like textbooks and courseware – they don’t replace them. This part of the design is also strategically important. Instructors will not adopt OELMs in place of the textbook or courseware they already use because generative AI is too unfamiliar to them. But I’m developing what I think is a very solid strategy for talking about OLEMs in a way that will make it relatively easy for instructors to adopt OELMs as supplemental materials. More on that in a future post.
Finally, developing OELMs should include a collaborative process in which groups of faculty and students work together on the OER curation and adaptation, activity type selection, and activity specification / instruction writing. Again, more about this in a future post.
I’m cleaning up the prototype code and will share via GitHub soon. Interested in working together on OELMs? Let me know!
You must be logged in to post a comment.