Is knowledge acquisition always manual?

No. Automated extraction and learning can contribute, while people may still define the task and validate results.

How is it different from knowledge representation?

Acquisition obtains and clarifies what the system should know; representation determines how that content is expressed for use. The two influence each other.

Why ask about exceptions?

Exceptions reveal hidden conditions and boundaries that ordinary examples may not expose.

AI Glossary / Graphs and symbolic AI / Intermediate

Knowledge acquisition

Definition

Knowledge acquisition is the process of obtaining, clarifying and validating the knowledge needed by an AI system. It can involve eliciting expertise from people, studying documents and cases, or deriving candidate knowledge from data. The goal is usable, appropriately scoped knowledge rather than merely a larger collection of material.

What it means

A system may need facts, categories, relationships, decision rules, exceptions and explanations. These are not always written down in a form that can be transferred directly. Experienced people often apply distinctions they have difficulty articulating until they examine a concrete case.

Knowledge acquisition therefore includes interpretation. A statement such as “urgent requests go first” leaves unanswered what urgent means, which requests qualify and which exceptions override the default. Encoding the sentence too quickly can give an apparently precise system an incorrect rule.

The process overlaps with learning and information extraction, but is not limited to either. An extracted statement or learned pattern still needs evaluation of its meaning, evidence and limits.

How it works

Begin with the questions the system must answer and the decisions it must support. Identify relevant experts, records, reference documents and examples. Ask people to explain both ordinary cases and cases where the usual answer changes.

Translate the findings into a proposed representation, such as defined terms, relations or rules. Keep the source and context attached. Review disagreements rather than quietly choosing the easiest statement to encode, and distinguish an exception from a contradiction or a change in policy.

Test the proposed knowledge on cases that were not used merely to formulate it. Return failures to the sources for clarification. Acquisition is iterative because a new example can expose an omitted condition, ambiguous word or outdated assumption. The resulting knowledge needs an owner and a maintenance path as well as an initial approval.

Three practical examples

A support-tool team interviews specialists to distinguish common request types and the evidence needed to route them.
An archive project compares written cataloging guidance with staff handling of unusual items.
A knowledge-graph curator reviews machine-proposed relationships against source material before integrating them.

Think of it this way

Think of learning a recipe from an experienced cook who says “add enough water.” Copying those words is easy; discovering how enough changes with the ingredients takes examples, questions and observation.

The analogy captures knowledge that is partly implicit. It does not imply that every domain can be reduced to a recipe or that an expert's first explanation is automatically complete and correct.

Worked example

Turning a broad statement into a testable rule

A fictional archive uses a demonstration system to route digitization requests. An initial interview produces the statement: urgent items go to the fast queue. The first encoded rule is therefore Urgent implies FastQueue.

Four invented test requests have these properties. A is urgent, ordinary and cleared for handling. B is urgent and fragile. C is nonurgent, ordinary and cleared. D is urgent but has no recorded handling assessment. The domain reviewer expects A to enter the fast queue, B to receive specialist review, C to enter the routine queue and D to wait for assessment.

The initial rule sends A, B and D to the fast queue. It does not express the ordinary nonurgent route at all. The problem is not that the rule engine ignored the rule; the acquired knowledge omitted conditions and alternatives.

Further discussion establishes three distinctions: fragile items require specialist review; an unassessed item needs assessment; an ordinary cleared item can enter a queue selected by urgency. The team represents handling status explicitly as fragile, ordinary-cleared or unassessed, rather than treating missing evidence as clearance.

Reapplying the revised routing specification gives FastQueue for A, SpecialistReview for B, RoutineQueue for C and AssessmentNeeded for D. These four matches only verify the invented examples. They establish no production accuracy. Further cases should test conflicting statuses, changed assessments and unclear urgency.

Illustrative case study

The fictional Alder Archive team initially plans to acquire knowledge by uploading its existing instructions. During review, two staff members interpret fast handling differently: one means earlier scheduling, while the other means skipping an assessment.

Alder records the disagreement and walks through the four test requests. The discussion separates scheduling priority from permission to proceed, and the team revises the vocabulary before adding more rules. Each rule links back to the reviewed statement and the example that clarified it.

The team keeps unresolved cases visible instead of silently treating them as ordinary requests. This fictional case illustrates improvements to meaning and coverage.

Common misconceptions and mistakes

Interviewing one expert once completes acquisition. Important exceptions and disagreements may emerge only through further cases.
Importing documents produces validated knowledge. Documents can be ambiguous, inconsistent or outdated.
A model-generated rule is established expertise. It requires evidence and review appropriate to its intended use.
Passing the cases used to write a rule proves general reliability. Those cases may miss important situations.

Business use

Knowledge acquisition helps make organizational expertise usable in decision support, search, automation and training tools. It can also reveal where a process depends on undocumented judgment or conflicting definitions.

Budget for expert time, example collection and revision rather than only for software implementation. Evaluate whether the acquired knowledge answers the intended questions and identifies its own limits. Track sources and review responsibilities so later changes can be assessed. A smaller, well-understood set of supported rules may be more useful than an extensive collection whose meaning and ownership are unclear.

Check your understanding

Why should request D not be treated as an ordinary cleared item?

Answer: Its handling assessment is missing. Absence of a recorded problem is not the same as evidence of clearance, and the acquired specification assigns an assessment step to that situation.

Related terms

Learn next

Choose a harmless process such as sorting library returns. Write one informal rule, then invent an ordinary case, an exception and a missing-information case. Ask what additional facts are needed before translating the rule into a decision table.

Sources

Reiter, Robertson and Sripada report acquisition difficulties including expert disagreement and unusual cases: https://arxiv.org/abs/1106.5264

Rahman and colleagues present an expert-in-the-loop approach to acquiring and integrating knowledge: https://arxiv.org/abs/2402.03291

Kass and Finin describe acquisition from observed advisory interactions: https://ocs.aaai.org/Library/AAAI/1987/aaai87-053.php

The archive rules and Alder Archive case are fictional.

Previous: Knockoffs (statistics) Next: Knowledge as a service