Summarize, Extract, Classify
Documents now go in reliably, so the question becomes what to ask of them. In practice, almost everything an office does with a model comes down to three verbs. Summarize: make it shorter. Extract: pull out the specific pieces. Classify: put each thing in a bucket. Three shapes of ask, one machine underneath.
Tessa tries all three on the same pile, and it is the pile that has been defeating Waymark for years: this season's 2,300 guest reviews, spread across booking sites and feedback forms. Nobody has ever read them all. Everyone has an opinion about what they say.
Picture what you would ask an assistant to do with a sack of mail. Give me the gist of it. Fill in this spreadsheet from it. Sort it into these four trays. Those are the three verbs, and the reason they feel familiar is that they are what people have always done with piles of paper.
Summarize: Shorter, but for Someone
"Summarize this" is a weak ask, and it produces a weak summary: shorter, generic, aimed at nobody. A summary is a decision about what to keep, and the model cannot make that decision well unless it knows what the summary is for.
So say. "Summarize these forty reviews for tomorrow's operations meeting: complaints only, grouped by tour, with the number of reviews behind each complaint." That is the same instruction craft as Chapter 2, applied to a new verb, and the difference in the output is not subtle.
Keep one caution attached to this verb. A summary is generated text, so it is fair on the gist and unreliable on specifics. If a number in the summary is going to be repeated in a meeting, get it from the reviews rather than from the summary.
Extract: From Prose to Columns
Extraction turns freeform text into fields. "From each review, give me: tour name, star rating, and a one-line complaint if there is one — as rows, one review per row." Out comes something Tessa can paste into a spreadsheet, from material that was never structured at all. This is the verb that quietly deletes the most tedium.
Ask for the shape you intend to use, which is Chapter 2's format habit doing real work here. Rows if it is going into a sheet. And say what to do when a field is missing, because that is where extraction goes wrong.
Here is the failure to expect, and it surprises people. Extraction feels like copying, so it feels like it cannot be wrong. It is not copying. The model is generating what it read, and a vague review can produce a confidently filled field that nobody wrote — a tour name that was never mentioned, a rating inferred from a cheerful tone. Tell it to leave a field blank rather than guess, and spot-check a handful of rows against the original reviews. Chapter 3's habits do not stop applying because the task looks mechanical.
Classify: Buckets You Define
Classification is sorting: each item gets exactly one label from a list you supply. "Label each review as praise, complaint, question, or mixed." Give the four buckets, give one short example of each (Chapter 2 again — showing beats describing), and the model sorts at a speed no human matches.
The buckets are yours, and this is not a detail. Ask a model to "group these reviews into themes" and it will invent its own categories — reasonable ones, and different ones next Tuesday, so nothing can be compared across batches. Defined buckets stay stable; invented ones drift.
Tessa does not start with 2,300. She runs 50 as a trial batch, reads all fifty labels herself, and finds two mistakes and one bucket that does not work: complaints about the weather are being filed as complaints about the tour. She fixes the bucket definitions and reruns. That trial is twenty minutes, and it is the difference between a labelled dataset and 2,300 confidently mislabelled reviews.
The Three Compose
The verbs are useful alone and better in sequence. Classify all 2,300 into the four buckets. Take the complaints and extract tour name and complaint type into rows. Then summarize the complaint rows per tour for the operations meeting. Each stage narrows the pile, and each stage produces something Tessa can look at before the next one runs — which is what makes the pipeline checkable instead of magical.
One thing about that afternoon is worth remembering, because the book pays it off later. Doing 2,300 reviews through a chat box means pasting batches by hand, over and over, for hours. It works. It is also obviously a job for something other than a person with a clipboard, and in Chapter 8 the same task runs in twenty lines of code that Tessa's contractor writes and she can read. Hold on to the tedium; it is the reason the second half of this book exists.
- "These three need three different tools." One model, three shapes of ask. What changes is the instruction and the shape of the output, not the machine doing the work.
- "Extraction copies, so it cannot be wrong." It generates what it read. A vague review can yield a confidently filled field nobody wrote — tell it to leave blanks, and spot-check a sample of rows.
- "The model will work out the right categories." It will invent categories if you let it, and different ones next time, so batches stop being comparable. You define the buckets; it fills them.
- "A summary of the reviews is a safe source for numbers." A summary is generated text about the pile. Quote-worthy figures come from the reviews or from an extraction you checked, not from a paragraph of prose.
- These three verbs cover most of the text work an office actually has, so naming them turns the vague question "what could I even use this for?" into a checklist you can run against your own week.
- The 2,300-review pile becomes this book's yardstick: what nobody had time to read becomes an afternoon's work here, and twenty lines of code in Chapter 8.
Knowledge Check
What makes a summary request strong rather than weak, on this page's standard?
- Naming a word count, so the model knows how far to compress the pile
- Asking it to keep only the parts that are genuinely important overall
- Summarizing twice over, so the second pass tightens what the first produced
- Saying who it is for and what it is for, so the choice of what to keep is guided
Why can an extracted spreadsheet row be wrong even though nothing was invented on purpose?
- The columns can come back in a different order from the one you actually asked for
- Extraction generates the fields, so a vague review can yield an invented one
- Rows past a fixed limit are dropped, so the last reviews never get a row
- The model rewrites the original reviews as it pulls the fields out of them
Why should you define the buckets instead of asking for themes?
- The model cannot invent categories of its own from a pile of reviews
- Invented categories drift between batches, so nothing stays comparable
- Named buckets keep the number of labels small, which invented ones do not
- Labels you choose yourself are the ones the model applies most accurately
Why does Tessa label 50 reviews before running all 2,300?
- To check the labels herself and fix the buckets before the full run
- To keep the cost down, because a smaller batch is a much cheaper request
- To stay inside the window, since fifty reviews is the most that fits at once
- To give the model practice, so its labels get better as the batches go on
You got correct