DCS 440: Artificial Intelligence
Project, Part 1
Due Nov 15

Contents
Framework
Format
Step 1
Step 2
Note
A framework for breaking up the project

Class projects this year cover an exciting and comprehensive range of domains. People are experimenting with game-playing, with understanding or producing natural language, with fault-detection and diagnosis in equipment, with scheduling and delivery, and with many other kinds of decision-making for specific problems.

The variety of domains masks an overall similarity among these projects. The techniques presented thus far in the class will apply in all of them in roughly the same way. Here is a suggestion for how this application goes.

  • To begin with (in part zero of the project), you formulated a scenario giving a specific example of your system in action. The scenario takes the form of a combination of decisions or actions taken by the system. From now on you will be using this scenario as a guide for focusing and testing your implementation. That is, you will be studying how to assemble that kind of combination of decisions.

  • At a high level, AI proposes -- and we have studied -- only a single way to assemble combinations of things: search. In this search, you provide rules that define what potential combinations need to be considered, and conditions that define when one of these potential combinations represents a solution to your problem. Then you search the states generated by the rules to find one that meets the conditions you need.

    In the majority of cases, then, your project will involve fleshing out and implementing your scenario using this kind of search process.

  • Setting up and managing a search problem draws on knowledge of the domain at many steps. You must be prepared to recognize the need for more knowledge, and to formalize the knowledge that you need, at any of these steps.

    A starting point is in representing the space: in setting up the combinations of things that your program will search over. There are three things to consider here. First, domain knowledge gives you the elements in the domain that can be combined and the rules for combining them. Second, domain knowledge may provide rules that determine what the right overall combination to choose is, once a key part of the combination has been provided. Third, domain knowledge may suggest an order for introducing possibilities in search that simplifies the structure of the search space.

    The coin distribution problem from the first midterm highlights all three factors. To start with, the problem provides coins that must be allocated -- these are the elements in the domain; allocating them means assigning them to Robin or Sandy. Second, the domain provides the constraint that any coin that Sandy doesn't get, Robin gets. That means that you only need to choose a set of coins for Sandy and then you can determine Robin's coins from that by rule. Finally, by choosing coins largest first (or smallest first) we have a way to represent each allocation by a unique node in the search space; we avoid having different nodes or different paths for each permutation of the coins.

  • Once you have set up the search space, different kinds of knowledge come into play in managing the search through that space. First, there is the question of what search algorithm to use. You may want to select depth-first search, or heuristic search, or you may decide you need one of the more specialized search techniques that we'll study in a few weeks (such as constraint-satisfaction search). We've seen that the choice depends on the search space in your domain; there are considerations like how large the search space is, how frequent solutions are, and what kinds of costs and benefits can be assigned to moves through the search space. In some cases, you may be able to use properties of your domain to use greedy or dynamic programming ``searches'' -- the result may seem a lot more like a conventional algorithm than an aimless search procedure. But by continuing to view what you're doing as a specific method for applying domain knowledge to search for a solution to a problem, you can continue to fit your project into this overall outline.

    There is also the question of actually designing a heuristic, if you choose to use a heuristic search algorithm. This is obviously a place where you have an opportunity to apply knowledge about your particular domain.

Thinking about this outline will be useful in several ways. Most importantly, it will make it easier to read and carry out further assignments as they are intended. These further assignments will refer to this overall outline in measuring out steps towards the completion of the project. If you are clear on how to break up your project you can use the assignments to make steady, even progress.

It should also help you to draw on the material we have covered in class -- and that we are continuing to cover -- where possible in completing your project.


Format

Part one of the project will ask you to work out, at a high level, how this outline applies to your project. This amounts to preparing an informal, high-level description of the tack you intend to take in carrying your project through.

Then you will identify a key step in the outline and a key source of knowledge that you intend to apply at that step -- try to pick the one where the biggest challenge is going to be in your domain. Write a collection of clauses in which that knowledge is encoded and can be made available to queries in the form that your key step in requires -- covering the cases needed to work through your scenario. The point is to get some experience programming, some experience representing information in your domain, and to make sure that you have identified some of the biggest pitfalls that may loom ahead in the completion of the project.


Step 1

Briefly discuss the main search problem that your project gives rise to. Explain where the search problem arises in the overall task the agent faces -- or how the answer found by search is to be used. Then describe at a high level what kinds of states will be encountered in this search process and what kinds of rules will relate one state and its neighbors. Finally, indicate what kinds of algorithms you intend to use to find answers in the search space (and why you intend to do this) and what specific kinds of knowledge you expect to be important in navigating through the search space in your specific domain.

The following starting points may help in formulating this answer. Many projects are focused around the construction of a complex object with interrelated parts -- for example a route, a string of words, an analysis of a sentence into a parse, or some other kind of collection of objects that go together. If you have rules for describing possible ways of building a whole out of parts, you can see the construction of this complex object as a search problem. Other projects involve anticipating into the future---to anticipate the state of a game, the consequences of an action, the results of a test or the outcome of some other kind of situation. Here you may want to see the search space as related to the states that you are anticipating.

If you still are having trouble explaining the role of search in your project, fall back on this idea. If you are writing a Prolog program for your project, you should be able to see the clauses you write as a description of the knowledge you need in your domain. In some sense, using this knowledge is always a search problem! This is a fallback because once you understand the role of search in your project from this perspective, it may take some more effort to explain that role in an intuive way. The ideas above, by contrast, allow you to account for search more directly.


Step 2

Based on your answer to Step 1, identify a particular aspect of the search problem you will face where domain knowledge will be especially important. Select a case where the domain knowledge will be represented explicitly -- ideally, in other words, as rules or facts -- and can be queried in that form at the right stage in your search process.

For example, in construction problems, it can be particularly difficult to describe what the legal structures are, or to formalize which possible structures are good structures that solve your problem. The ambiguity depends on how you cast your search problem: you can make more structures ``legal'' using a simpler or more straightforward definition; but then you will have to have a more complicated rule saying which of those structures are ``good''.

Planning and diagnosis problems require the knowledge of how actions affect the world -- this may be easy or hard -- as well as heuristics that assess how much progress has been made in getting the world the way you want it or in explaining why the world isn't how you want it. Formulating heuristics too can be easy or hard...and chances are there's a good chunk of work required either to formulate the effects of actions or to formulate your heuristics!

Collect several concrete cases where that domain knowledge must be queried, and identify the answers the domain knowledge must provide for those queries. You should use your current storyboard for inspiration with these queries and answers. Formalize the domain knowledge involved in general terms as a program (using appropriate terms and relations, of the sort you outlined in Part Zero of the project, and defining rules that will apply across an interesting range of situations in your domain wherever possible). Show that querying the program gives the answers that you need for the cases you are studying.


Historical Note

The syllabus uses the odd terms ``static formalization'' and ``dynamic formalization'' to describe the parts of the project. This description shows the initial way I was thinking about projects. I thought most people would be studying simple variants on the kinds of planning problems we're studying in class. To do this, you would first have to understand the objects and relations that hold at a single point in time; this corresponds to a static world and thus requires a static formalization. Then, you would need a description of the actions in the domain and their consequences -- this would move you to a dynamic world, with plenty of possible changes, and would therefore provide you with a dynamic formalization. If any particular search strategies were required for this planning problem they would be tackled in the last stage as you went from dynamic formalization to final project description and submission.

Obviously that only partly describes the projects that people have actually selected, so a more general, more flexible names and descriptions are required for the more general, more flexible projects that people are actually doing.