AI for Construction & AEC
Capable · M18 · lesson 18 of 25 · queued
Preview — browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll →
Getting Useful Output from AI: Few-Shot With Your Own RFI Log
📖
now learning

Getting Useful Output from AI: Few-Shot With Your Own RFI Log

15 min

The fastest way to make AI write like your firm is not to describe how your firm writes; it is to show it. Tell a model "write a professional RFI" and you get a generic, internet-average RFI that sounds nothing like the ones your team actually issues. Paste three of your own past RFIs first and then ask, and the model writes in your voice, your structure, your level of detail, because it now has examples to imitate instead of a description to interpret. This technique is called few-shot prompting, and for AEC work it is the single highest-leverage move after the scaffold, because your documents have a house style and house conventions that no general instruction can capture but three real examples convey instantly. This lesson shows you how to use your own RFI log to make the model draft like your best PE.

Show, Don't Tell: Why Examples Beat Instructions

Start with why this works, because the principle generalizes far beyond RFIs. A model learns from patterns, and an example is a far denser carrier of a pattern than a description is. If you try to describe your firm's RFI style in words, "be concise but thorough, professional but not stiff, cite the sheets but do not over-explain," you are giving the model a vague target it will interpret loosely, and the result lands somewhere in the average of everything it has read. But if you show it three of your actual RFIs, every one of those qualities is present in the examples concretely, the exact concision, the exact tone, the exact way your firm cites sheets, and the model imitates what it sees rather than guessing what you meant. Showing is higher-bandwidth than telling.

This maps onto how you would actually train a new hire. You do not hand a new project engineer a paragraph describing how to write an RFI; you hand them a stack of the firm's past RFIs and say "write yours like these." The examples carry the institutional knowledge that the description cannot, the conventions nobody ever wrote down but everybody follows. Few-shot prompting is exactly that move applied to the model: instead of explaining your house style, you demonstrate it with real artifacts, and the model picks it up the way a sharp new hire would from the same stack. The technical name sounds fancy; the practice is just "here are three of ours, make yours match."

An example is a denser carrier of a pattern than any description. You do not hand a new PE a paragraph about RFI style; you hand them three real RFIs. Few-shot prompting is that exact move, applied to the model.

How to Few-Shot an RFI From Your Log

The mechanics are simple and worth doing precisely. You select a few representative RFIs from your firm's log, three is usually plenty, paste them into the prompt as labeled examples, and then give the model the new situation and ask it to draft an RFI in the same style. The examples should be good ones, because the model imitates whatever you show it, including the flaws, so you pick RFIs that exemplify how you want the work done, not just whatever is at the top of the log. You are effectively voting for a style with your example selection, so vote for your best.

A practical question is how many examples to use, and the answer is usually fewer than people expect. Three is a good default, because it is enough for the model to see a pattern rather than copy a single instance, and few enough to keep the prompt lean and leave room for the actual task. One example risks the model treating that single RFI as a rigid template to clone rather than a style to imitate, while ten examples consume context for diminishing returns and can crowd out the new situation you are asking about. Label each example clearly so the model knows these are references to learn from and not part of the question, something as simple as "Example RFI 1 from our log:" before each, so the model does not confuse your examples with the task. Get the count and the labeling right and three good examples do almost all the work.

The examples also do something the scaffold alone cannot: they teach the model your firm's specific conventions for the things that matter most, especially citations. If your firm cites RFIs with the sheet number, the spec section, and the revision in a particular format, three examples that all do this train the model to do it too, far more reliably than an instruction to "cite the sheets" ever would, because the model sees the exact citation pattern repeated and reproduces it. This is where few-shot becomes a quality-and-safety tool, not just a style tool: by showing the model how your firm grounds its references, you push it toward grounding its references the same way, which directly reduces the vague, ungrounded citations that lead to fabrication. The examples are teaching format and rigor at the same time.

Demanding Grounded Citations and Honest "I Could Not Find"

Few-shot makes the model write like you; the next layer makes it cite like a professional, and that requires two explicit demands on top of the examples. The first is to require that every reference trace to something real: tell the model to cite the specific spec section, drawing number, and revision for any claim, and to do so only when it actually has that reference from what you provided. The examples show the format; this instruction enforces the grounding. Together they push the model strongly toward references that are both correctly formatted and actually anchored, which is exactly the combination that a fabricated citation lacks.

The second demand is the one that does the most to prevent fabrication, and it is counterintuitive: explicitly require the model to say "I could not find this" rather than invent an answer when it lacks the information. Left to its own devices, the model will always produce something, because producing plausible text is what it does, so a missing spec reference becomes a fabricated one. But a model explicitly instructed that "I could not find a governing spec section in the provided documents" is an acceptable and preferred answer will often take that exit instead of inventing, because you have made the honest response a valid output. This single instruction converts a class of silent fabrications into visible gaps you can fill, which is enormously safer, because a gap that says "not found" gets your attention while a confident fake citation sails through. Making "I do not know" an allowed answer is one of the most protective things you can do in an AEC prompt.

The Honest Trade-Off and When Few-Shot Is Worth It

Few-shot is powerful but not free, so it helps to be clear about the cost and when to pay it. The cost is the upfront effort of selecting and pasting good examples, and the context space they consume, which on a very long document can crowd the workbench. For a one-off, trivial task, that overhead is not worth it; you would just use the scaffold and move on. But for the documents you produce repeatedly and care about, RFIs, submittal transmittals, NCRs, anything with a house style and a citation convention, the few-shot examples pay for themselves immediately and then keep paying, because once you have assembled a good set of examples you reuse them every time.

This is why few-shot pairs naturally with the prompt library idea from the last lesson: your three best example RFIs become a permanent part of your RFI prompt, pasted once into the saved prompt and reused on every RFI thereafter, so the selection effort is a one-time investment that improves every future draft. The decision rule is simple: if it is a document you write often and want to look like your firm's, invest in few-shot examples once and reap the benefit forever; if it is a genuine one-off, the scaffold alone is enough. For the high-volume, house-style, citation-heavy documents that make up most of an AEC professional's writing, few-shot is almost always worth it, which is why it sits at the center of getting truly useful output rather than merely adequate output.

What Few-Shot Cannot Fix, and Why It Still Needs Verification

Few-shot is powerful enough that it can create a dangerous illusion, so it has to be said plainly: few-shot makes the model write more like you, it does not make the model more correct about your project. The examples teach style, structure, and citation format, the how of the document, but they cannot teach the model the facts of your specific situation, the what. A few-shot RFI that perfectly matches your house style and cites in your exact format can still ground that citation in a sheet number the model inferred rather than one you provided, and now you have a fabrication wearing your firm's polish, which is arguably more dangerous than a generic fabrication because it looks even more trustworthy.

This is the trap to guard against: the better the output looks, the more tempting it is to skip verification, and few-shot makes the output look truly better. So the discipline is that few-shot raises the floor on style and lowers the rate of ungrounded citations, especially paired with the honest-"not found" instruction, but it does not remove the verification step, it makes the verification step more important to actually perform because the output is now convincing enough to lull you. Every citation in a few-shot draft still gets checked against the source exactly as it would in any draft, because the model imitating your citation format is not the same as the model having your actual sheets. The polish is real and valuable; the facts inside it are still the model's predictions until you verify them. Hold both truths at once and few-shot is a pure gain; forget the second and it becomes a better-disguised version of the same fabrication risk.

Advanced Few-Shot: Teaching the Edges, Not Just the Center

Once the basic move is comfortable, two refinements make few-shot noticeably better. The first is choosing examples that match the situation, not just the document type. If you are drafting an RFI about a structural conflict, examples of past structural-conflict RFIs teach the model more than examples of, say, finish-schedule RFIs, because they show how your firm handles this kind of question specifically, the relevant references, the typical resolution structure, the right level of technical detail. A small, well-matched example set often beats a larger, generic one, because relevance carries more pattern than volume does. Curating a few example sets by RFI type, structural, MEP, architectural, is a modest investment that sharpens every draft.

The second refinement is teaching the edges by example, especially how your firm handles uncertainty. If you include an example RFI where the original author wrote something like "governing detail not located, request design team direction" instead of guessing, you are showing the model your firm's actual convention for honest gaps, which reinforces the honest-"not found" instruction with a concrete demonstration of what that looks like in your house voice. The model then reproduces not just your style for confident statements but your style for admitting uncertainty, which is exactly the behavior you most want to encourage. Showing the model a good example of saying "I do not know" in your firm's voice is one of the most underused and most valuable few-shot moves, because it makes the safest behavior also the most natural one for the model to imitate, aligning the style incentive with the safety incentive instead of leaving them in tension.

The Applied Problem: Run the A/B Test on Citation Accuracy

Here is the exercise that proves the value with your own eyes, because few-shot's benefit is easy to assert and more convincing to measure. Take one real RFI question from your work and produce two drafts of it. For the first, use only the scaffold, a good prompt with no examples. For the second, use the same scaffold plus three real RFIs from your firm's log as few-shot examples, plus the grounded-citation and honest-"not found" instructions. Then compare the two drafts specifically on citation accuracy and house-style fit.

Look at concrete differences. Does the no-example version invent sheet numbers or spec sections that the few-shot version instead grounds or marks as "not found"? Does the few-shot version match your firm's actual RFI structure and citation format while the no-example version drifts toward a generic shell? Count the fabricated or ungrounded references in each, because that count is the number that matters: the few-shot version with the honest-"not found" instruction should produce noticeably fewer invented citations and more honest gaps, which is the safety improvement made visible. Note also the style fit, because a draft that already looks like your firm's needs far less editing to send.

The deliverable is the two drafts side by side with the citation-accuracy comparison written out, and the lasting product is the conviction that comes from seeing the difference yourself, plus a reusable set of example RFIs you have now validated. From here, few-shot stops being a technique you read about and becomes the default way you prompt for any house-style, citation-bearing document, which is most of what you write. Combined with the scaffold from the last lesson, you now have the two moves that turn the model from a generator of generic plausible text into a drafter of your firm's actual documents with your firm's actual citation discipline, which is the foundation every hands-on document lesson in this level is built on. The scaffold tells the model what to do and few-shot shows it how your firm does it, and the two together are why the same tool that produced a useless generic paragraph a few lessons ago now produces a draft a PE would recognize as one of theirs.

Key Takeaways

  • The fastest way to make AI write like your firm is to show it, not describe it. An example is a far denser carrier of a pattern than any instruction, so three real RFIs convey your house style instantly where a paragraph of description lands in the average.
  • Few-shot prompting is "here are three of ours, make yours match," the same move you make when you hand a new PE a stack of the firm's past RFIs instead of a paragraph about how to write them.
  • Pick good examples, because the model imitates whatever you show it, flaws included. You vote for a style with your example selection, so vote for your best, and the examples teach your citation conventions far more reliably than an instruction to "cite the sheets."
  • Add two explicit demands on top of the examples: require every reference to trace to a real spec section, drawing number, and revision; and explicitly allow "I could not find this" as a preferred answer over inventing one, which converts silent fabrications into visible gaps you can fill.
  • Making "I do not know" an allowed answer is one of the most protective moves in an AEC prompt, because a gap that says "not found" gets your attention while a confident fake citation sails through.
  • Few-shot costs upfront example-selection effort and context space, so it is overkill for a trivial one-off but pays for itself immediately on the high-volume, house-style, citation-heavy documents you produce repeatedly, especially once the examples live in your saved prompt.
  • The artifact: an A/B test producing the same RFI with and without few-shot, comparing citation accuracy and style fit, which makes the safety and quality improvement visible and yields a validated, reusable example set.