Professional Documents
Culture Documents
May 2014
Executive Overview
Spend Classification is the process of transforming raw data from payment and purchasing
systems and cleansing, enriching, and classifying it into common, meaningful categories. A
good Spend Classification and Analysis tool helps organizations to identify saving
opportunities and monitors compliance with corporate policies and negotiated contracts.
Statistics show that organizations with good spend visibility easily save between 0.25 and 1%
on total spend every year.
One of the unique selling propositions of Oracle Spend Classification is on-premise installation
and classification. This presents a challenge to the implementers as they need to build a
Knowledge Base specific to the business requirements and that adapts well to the changing
business needs. The application makes use of powerful Data Mining algorithms to provide
predictive capabilities to the Knowledge Base. However, history has shown that business
users frequently do not understand how the Knowledge Base is used to classify transactions.
This white paper throws some light on how the Knowledge Base functions, guidelines on
creating an effective Training dataset and provides guidelines on using Spend Classification
optimally.
Terminology
Apply operation: Refers to the Knowledge Base creation/ enrichment process
Build operation: Refers to the classification process
Class: The Commodity/ Category code. An example could be HARDWARE.LAPTOP for a 2
level taxonomy.
Classification Batch: The group of records submitted for a classification run using a Knowledge
Base..
Document: Concatenation of text fields of each input row, either for a Training Dataset or
Classification Dataset.
Enrichment of Knowledge Base: A process by which the learning acquired by the Spend engine
using previous training process is completely erased, and new learning is gained with the help of a
revised training dataset. It is not an incremental process, but a complete refresh of the Knowledge
Base.
Knowledge Base: An Oracle Data Mining (ODM) Model that is created using sophisticated
mathematical algorithms to segment data and discover patterns. This, in turn, aids in the
prediction of likely outcomes.
Taxonomy: A method of categorizing or classifying any data.
TF-IDF: Term Frequency Inverse Document Frequency, is a numerical statistic that indicates
how important a word is to a document in a collection or corpus of documents. It is often used as
a weighting factor in information retrieval and text mining. These statistical values increase
proportionally to the number of times a word appears in the document; however they are offset by
the frequency of the word in the corpus, which helps to control the fact that some words are
generally more common than others.
Training Dataset: A representative sample of the spend data brought in from disparate legacy
systems into Oracle BI Applications.
Unclassified Data: All of the spend data brought in from disparate legacy systems into Oracle BI
Applications that have never undergone the classification process even once using a Knowledge
Base.
Introduction
In todays dynamic business environment and intense competitiveness, global organizations
are facing tremendous business pressures to manage spend effectively. Organizations need to
achieve their savings goals, and ensure that the quality of supply is improved over time. The
need of the hour is to consolidate spend with fewer, more strategic suppliers and report a more
granular level of spending. In this era of globalization, the focus is to identify sources of
contract leakage globally and ensure spend visibility across systems. Organizations will not be
able to get an accurate picture of their overall spend unless spend data is classified accurately.
Hence, organizations definitely need an effective spend classification and analysis tool to
improve strategic sourcing, meet performance targets and ensure compliance with internal
policies and government regulations. According to Forrester research data, enterprises in
multiple markets across multiple industries with multiple ERPs benefit the most by using spend
classification tools.
Key Challenges
The key challenges faced by the organizations with spend analysis and classification is as
follows:
Taxonomy Errors: Frequently, the Taxonomy definition is incomplete, or it only meets the
financial reporting requirements. Sometimes, the Taxonomy is not defined to the granularity
level needed for getting accurate picture of actual spend.
On the other hand, Oracle Spend Classification provides a fully integrated end-to-end
classification solution with Oracle Procurement and Spend Analytics and Oracle iProcurement.
Unclassified data is seamlessly read from Procurement and Spend Analytics and classified
using Oracle Data Mining engine. When you are satisfied with the accuracy of the
classification, approve the classification run. After approval, classified data is immediately
available in Procurement and Spend Analytics for further analysis.
Following are the advantages of using Oracle Spend Classification over third party
classification service providers:
Intelligence based Learning System: The application learns from spend data using
powerful Data Mining algorithms and improves its capability with your feedback. You can
enrich the Knowledge Base to increase classification accuracy.
On-Premise Installation: You need not transfer spend data to service providers, thereby
eliminating data privacy concerns. You can classify data as and when required. Out of the
box integration with Procurement and Spend Analytics ensures immediate availability of
classified spend data after the classification process.
Assisted Classification: Users have an option to override category codes predicted by the
system.
Inline Classification: The application helps in classifying the Non Catalog Requests in
Oracle iProcurement, thereby correcting classification code at the point of entry. Users need
not worry about trying to figure out the category code of the transactions.
No
Analyze Spend
Data
Start
Create Training
Dataset
Create Taxonomy
Training Dataset
Satisfactory
Yes
Create Knowledge
Base
End
No
Unclassified
Data exists
Approve
Classification
Batch
Yes
Classification
Results
Satisfactory
Classify Data
No
Yes
Perform Manual
Corrections
No
Large Volume of
Manual Corrections
Required
Yes
Changes in
Taxonomy/ New
Data Sources
Yes
Modify Training
Dataset
Enrich Knowledge
Base
No
Analyze Spend Data: Prior to the implementation of the application, it is very important that you
know and understand the data that needs to be classified. This helps in identifying the transactions that
need to be part of the Training Dataset. A good Training Dataset represents the entire population of
spend data that needs to be classified by the application. For a new implementation, a good starting
point is the classified dataset organizations have received from third party classification service
providers in the past, if available. Else, you will need to create the Training Dataset manually using
sample transactions for each spend category.
Create Taxonomy: The next step is to create the taxonomy, or modify the existing taxonomy, to fit
the reporting requirements of the global organization. Spend Data is generally captured and stored in
multiple systems. Frequently, these systems utilize different classification schemes (that is, taxonomies)
to categorize expenditure. Usually classification schemes are designed to aid financial reporting, and are
not adequate for procurement and spend analysis and reporting. Hence, it is essential to create (or use)
a standard taxonomy across the enterprise to categorize spend data. Often, most organizations end up
creating custom taxonomies that address their business processes and reporting requirements. Oracle
Spend Classification is well equipped to handle custom taxonomies.
Create Training Dataset: Next, you need to provide the correct category codes for all the
transactions that are part of the Training Dataset, against the auto code column of taxonomy being
used. This is a very important step, as the application completely relies on the richness and accuracy of
the Training Dataset in order to predict classification codes accurately. For more information, please
refer to section Guidelines on Creating an Effective Training Dataset.
Create Knowledge Base: Once the Training Dataset is in place, create the Knowledge Base. When a
Knowledge Base is built, it understands the knowledge or patterns present in the training dataset
through inspection. During the Classification process, the Knowledge Base applies this learning for
predicting the classification code. A Knowledge Base can be created using a single Taxonomy. Users
have the following options for creating a Knowledge Base:
Standard Knowledge Base A Knowledge Base created using the standard Oracle Spend
Classification application. It utilizes the hierarchal Support Vector Machine algorithm for
creating the Model.
Advanced Knowledge Base A Knowledge Base that is created outside the standard
Oracle Spend Classification application. The available algorithms are linear Support
Vector Machine, Nave Bayes and Generalized Linear Model. For more information
about these algorithms, please refer to Oracle Advanced Analytics user guide.
For more information on Knowledge Base creation process, please refer to Appendices A and B.
Classify Spend Data: Once the Knowledge Base is in place, classify the spend data. Essentially, all the
spend data is treated as unclassified data at the time of the first classification run. Thereafter, addition
of new source transaction systems or incremental data load for existing source systems result in
unclassified data. For more information on Classification process, please refer to Appendices A and B.
Perform Manual Corrections: If the predicted category codes of some transactions are not as per
expectation, you can perform manual corrections and overwrite the predicted category codes, prior to
approving the classification batch. Please note that users cannot enter classification codes manually for
unclassified data. This is possible in Oracle Spend Classification only after a Classification run
Approve Classification Batch: If the classification results are satisfactory, approve the Classification
Batch. This, in turn, updates the Oracle Business Intelligence Applications (OBIA) base tables with the
classification codes of the concerned taxonomy. Please note that it doesnt override the existing
commodity code value present in unclassified data.
Enrich the Knowledge Base: In situations where a lot of manual corrections need to be done to the
predicted category codes, or new transaction data sources are added over a period of time, users need
to scrutinize the existing Training Dataset and make the required modifications. The existing
Knowledge Base can then be enriched using the modified Training Dataset.
Users can enrich the Knowledge Base in the following scenarios:
To improve the accuracy of classification, in scenarios where the knowledge base is not
picking up certain keywords correctly or providing unwanted weightage to other
keywords.
Reclassify Spend Data: In scenarios such as classification runs with very low classification accuracy,
reset the predicted category codes of classified transactions and reclassify them against the enriched
Knowledge Base.
Understand the Template: You need to download the Template file from the application, and
repurpose the training data in the format as specified in the Template. The Template contains the
following different kinds of attributes:
o
Creation of Item Text: During the Knowledge Base creation and classification process, the
application constructs a string object by concatenating all the text-based attributes used by the Oracle
Data Mining (ODM) engine, except for Line Amount. This string object, along with Line Amount is
what gets passed to the ODM engine. Hence, the association between the attribute-value pair gets lost
and the ODM engine looks at those text inputs simply as keywords. For e.g., a sample transaction is
listed below:
Line Description
Supplier Name
Supplier Site
SSTRMBOSTRACROSER001
Currency
USD
10
Line Amount
276.41
Cost Center
7097068
The application concatenates the text based attributes into a single attribute called Item Text, and
passes the Item Text and Line Amount to the ODM engine. In the above sample, the Item Text gets
constructed as: SUPERIOR KITCHEN SERVICE INC CBR REAL ESTATE SERVICES
SSTRMBOSTRACROSER001 7097068. Therefore, the ODM engine cannot distinguish as to what
comprises the supplier name, line description, etc.
Stop List: Words that are part of the Stop List are not sent to the ODM engine either during
Knowledge Base creation or Classification. A stop list is a list of words that do not get indexed. These
are usually common words in a language such as this, that, and can in English. There are different Stop
Lists for different languages, such as English, Chinese, Danish, etc.
Data Cleansing: Ensure that you clean the text strings in the data to remove acronyms and spelling
errors. Standardize and normalize the information on item, item description and supplier, if required.
Attribute Overloading: Sometimes you might feel that there are certain additional attributes that
could help the ODM engine in better predicting the commodity code (e.g., GL Code). However, the
application only allows a fixed set of columns to be considered for Classification and Knowledge Base
creation. In such cases, you can add such attributes to an existing text-based attribute that is not being
used, or overload an existing text-based attribute and append the additional attribute values to an
existing attribute in case all the attributes considered by the ODM engine have already been utilized.
Since the ODM engine doesnt know about the relationship between an attribute-value pair and works
based only on keywords, this could be a possible workaround to introduce additional attributes.
However, you would need to do some customization so that the information about these additional
attributes is passed to the ODM engine during the Classification process.
The aim is to have a minimum of 35 records covering all possible variations of words that can occur at
each leaf node of the taxonomy.
At the end of classification run, typically transactions classified with high confidence are expected to be
more accurate, compared to those classified with medium and low confidence. However, if
transactions are classified with low confidence, it doesnt imply that the predicted category codes will
be incorrect.
It is not possible for users to specify classification rules manually. The system utilizes Oracle Data
Mining classification algorithms to learn/ identify the trends present in training dataset, and applies this
knowledge on unclassified data. This learning resides in the Knowledge Base, and cannot be viewed in
a user interface. The only way to comprehend if the Knowledge Base can classify the transactions (or
concerned commodity codes) correctly is after a classification run
Points to Remember
Ensure that the Dataset name should be different from the seeded ones AP Invoice, Purchase
Requisitions and Purchase Orders.
11
In case the Training Dataset consists of transactions for a single commodity code, the Knowledge Base
creation process will fail. The ODM engine requires at least two distinct commodity codes in order to
create the Knowledge Base.
It is mandatory to enter values into one or more of the Auto code columns (depending on the
Taxonomy), or else the Knowledge Base creation process will fail.
The category code columns, such as EBS Category Code etc., are ignored during Knowledge Base
creation process.
In order to analyze why a transaction is not getting classified accurately, note the keywords that are
assigned the maximum weightage and analyze the transactions in the Training dataset belonging to the
category code predicted by the application and the correct category code. This will help in discovering
the reason why the keywords in training data for the correct category code are not getting picked up.
12
records with category codes of the new Taxonomy. Create a new Knowledge Base using the new
Training Dataset. Reclassify all historical transactions, based on your business requirements.
Implementation Considerations
The following guidelines should be kept in mind while setting up Oracle Spend Classification:
Understand Your Data: This is the most important aspect of any implementation, and is helpful in
creating a rich and comprehensive Training Dataset. You need to understand and explore the nature of
spend in the organization, major areas of spend (by amount as well as volume), supplier data etc. In
most situations, direct spend data is relatively easier to train and classify than indirect spend.
Perform a Keyword Analysis: You need to analyze and associate the keywords that users would use
for spend categories. Keywords could range from supplier names to transaction or item specific words,
or a combination of other attributes, such as Operating Unit. If you can associate a set of unique
keywords with a particular category code, the classification accuracy for such transactions will be very
high.
Eliminate Noise: It is important to identify and eliminate superfluous attributes and keywords that do
not influence the prediction of category codes. Keywords that occur across all transactions in a
Training Dataset should be removed from the Training Dataset. For example, if the currency USD
occurs in most of the transactions in a Training Dataset, it is very likely that it would get a very high
weightage during the classification process, and this may not be a desired outcome.
Update the Training Dataset: If certain category codes are being classified incorrectly, you need to
revisit the Training Dataset and modify the training data to reflect the intended behaviour. You should
use only those keywords in these transactions that are deemed important from a classification
perspective. As explained earlier, weightage is given to keywords, depending on the interaction of these
keywords across category codes in the Training Dataset. This activity becomes especially important
when the organization decides to introduce new category codes and no corresponding transaction data
exists in the ERP/ legacy systems.
Decide on the Taxonomy Structure: Before creating the Training Dataset, it is important that the
business identifies the Taxonomy to be used. The number of levels and the kind of Taxonomy (ERP/
UNSPSC/ Custom) should be decided and should be in place (which in turn would depend on the
business and reporting requirements of the organization). Also, it is of utmost importance that the
Taxonomy is well-defined and detailed enough, without any duplication or any other factors that could
bring in inaccuracies. For example, using category codes such as HARWARE.HARDWARE, along
with other sub-categories under the HARDWARE parent category is not a judicious decision. This is
because anything that can be classified under a different sub-category under the HARDWARE parent
13
category can also be classified under HARWARE.HARDWARE. This would create irrelevant results
by the system and also leave room for misinterpretation by users.
Conclusion
In this white paper, we see how Oracle Spend Classification scores as compared to third party
classification service providers. Oracle Spend Classification helps global organizations in organizing
spend into logical categories; automating the expensive data management process and adapting to
changing spend patterns over time.
Setup considerations for implementing the application were also described, along with preimplementation and post implementation steps. Please refer to Metalink Note 1450275.1 in order to
access the latest Oracle Spend Classification Process Guide. Additionally, you can also refer to the Oracle
Advanced Analytics guides and Oracle Text guides to better understand the Data Mining process.
14
the various steps involved in the build and apply operations of an Oracle Spend Classification
Knowledge Base creation. Data from a sample dataset is used as an example.
document in the input Dataset. In this process, the keywords in each document are assigned a weight
(TF-IDF). This process is repeated across the corpus of documents, which in turn constitutes the
input Training Dataset. Few of the parameters that can influence the indexing process include the
Lexer and the Stop List. The Lexer preference specifies the language of the text to be indexed,
whereas Stop lists identify the words in your language that are not to be indexed. For more
information on these entities, please refer to the Oracle Text documentation.
2. Factors affecting TF-IDF Calculation: The keywords and their weightage (TF-IDFs) for each
document, derived in the previous step, are extracted and then fed as an input to the Knowledge
Base build process. Each of the keyword weight pairs is considered to be an independent
predictor. Consider the following example, where PROD_DESC field is considered as the text or
document field. In this example, we would build a Knowledge Base having a single level hierarchy,
such that PROD_CATEGORY is the target column.
PROD_ID: 44775
PROD_NAME: Vunelli Bb-956
PROD_LIST_PRICE: 79.95
PROD_DESC: this is the famous Vunelli Bb-956 in color 69.90 of size Bcbg 3/4 Length Cargo Trouser
PROD_CATEGORY: Women
PROD_SUBCATEGORY: Shoes Women
Actual TF-IDF Values: The keyword/weight (TF-IDF) pairs that Oracle Text computes from the
PROD_DESC field for this row are:
KEYWORD
-----------VUNELLI
956
BB
LENGTH
69.90
BCBG
4
CARGO
3
TROUSER
FAMOUS
SIZE
COLOR
VALUE
---------.374162
.374162
.374162
.346139
.346139
.326257
.270213
.270213
.256344
.148989
0
0
0
Note that the words this, is, the, in and of present in the PROD_DESC column are not
considered to be keywords because they are part of the Stop List. Notice that the characters hyphen
15
(-) and forward slash (/) are treated as keyword delimiters so that the appearance of 3/4 in the
document is translated into 2 different keywords, 3 and 4; similarly the appearance of Bb-956
is interpreted as 2 different keywords. The same is not true for the string 69.90 which is indexed
as a single keyword. These behaviors may or may not be desirable based on the business situation.
You would need to take the decision based on business requirements. In this case, since Bb-956 is
most likely a model number for the item and 3/4 appears to be a size indication, it is logical to not
have these characters treated as keyword delimiters while leaving the treatment of 69.90 (a color)
as is. This can be achieved by specifying these 2 delimiter characters in the PRINTJOIN attribute to
the Lexer that is passed to Oracle Text during indexing. Please refer to Oracle Text documentation
for more information on the Lexer attributes.
Effect on TF-IDF Values after modifying PRINTJOIN Lexer Attribute: Once the modification
to the PRINTJOIN attribute is complete, the following keyword/weight pairs are produced by Oracle
Text:
KEYWORD
-----------BB-956
VUNELLI
3/4
LENGTH
69.90
BCBG
CARGO
TROUSER
COLOR
SIZE
FAMOUS
VALUE
---------.398528
.398528
.398528
.398528
.368681
.347504
.287809
.158692
0
0
0
As a word of caution, even though the hyphen (-) and forward slash (/) characters are not
considered to be keyword delimiters in this document, it may not be correct to assume that the same
applies to all documents. The PRINTJOIN attribute passed to the Lexer impacts all documents that
are indexed. For example, here are some other hyphenated keywords from the input data set that
would be affected by this delimiter change:
RELAXED-FIT
SATIN-TRIM
SCOOP-NECK
SEAM-DETAILED
SHADOW-PLAID
SHIRT-JACKET
SHORT-SLEEVE
SHORTS-4
STRAIGHT-COLLAR
SWEATER-2T
16
For most of these keywords, changing the hyphen character to be non-delimiter clearly seems
appropriate. But for others like SHIRT-JACKET, SHORTS-4 and SWEATER-2T the
correct treatment is not always very clear.
Impact of Adding Keywords having TF-IDF value Zero to the Stop List: As mentioned earlier,
there is a theoretical, mathematical algorithm behind the assignment of TF-IDF values for each
keyword. But the fact that keywords FAMOUS, SIZE and COLOR received a value of 0
indicates that these keywords have no discriminatory value between documents. To validate this, an
examination of the input data set reveals that all three of these keywords appear in 100% of the input
documents. You might conclude that because of this, it might be better to include these terms in the
Stop List. The following keyword/value pairs results after this is done, but notice that TF-IDF values
for the non-zero keywords do not change.
KEYWORD
-----------VUNELLI
3/4
BB-956
LENGTH
69.90
BCBG
CARGO
TROUSER
VALUE
---------.398528
.398528
.398528
.398528
.368681
.347504
.287809
.158692
Not only do the assigned weight values remain unchanged, even if the keywords with TF-IDF value
equal to zero are not removed and get passed to SVM model build as valid predictors, the SVM build
process ignores these as non-attributes and does not assign them coefficients. Therefore, they do
not affect the classification process. In cases where the text column in the input data set is
sufficiently large so that the number of resultant keywords approaches the MAX_DOCTERMS
limit, it might make sense to either add these as stop words or possibly increase the value of
MAX_DOCTERMS.
The values extracted from Oracle Text in this step for keywords and weights, and the
PROD_NAME and PROD_LIST_PRICE are the mining attributes or predictors input to
knowledge base build operation. Up until this point, the value in the keyword/value pairs is specific
to the individual document. Once the SVM model is built in the next step, the coefficients in the
keyword/coefficient pairs will represent global values that are used in a linear computation during
prediction to compute the highest probability target or class. Each keyword will have one
corresponding coefficient for each of the predicted classes in which it was seen. In our example
dataset, there are 4 different classes (PROD_CATEGORY):
CLASS
------------------Women
Men
Boys
Girls
17
3. Calculation of Global Keyword/ Coefficient Pair: The system extracts the keyword/coefficient
pairs from the Knowledge Base and sets them aside in a separate details table for use by the apply
operation. Notice that the keyword/coefficient pairs are now constant for this model and are used
when a prediction operation is performed on a data item.
If we look in the details table at the keyword VUNELLI found in our example row, we see that a
coefficient is present only for two classes Women and Boys. By going back to the
keyword/weights generated in the previous step for all input rows, it can be observed that the
keyword VUNELLI was seen only in rows where the target class was Women or Boys. Another
keyword, LENGTH was seen for all target classes, and is therefore represented by
keyword/coefficient pairs for all target classes in the model details table.
SA$MODEL_ID
----------1
1
1
1
CLASS
---------------------------------------Women
Men
Girls
Boys
KEYWORD COEFFICIENT
------------ ----------------LENGTH
.096640336
LENGTH
-.00717371
LENGTH
-.05882683
LENGTH
-.01990017
Classification process
In an apply operation, steps 1 and 2 of the previous section are repeated on the input dataset.
However, the global values of keyword/ coefficient pairs generated during the build process are reused instead of being re-generated. This operation first generates keyword/weight pairs, or TF-IDF
values, specific to each row. These are then fed into the data mining prediction operation. Inside the
prediction operation, a linear expression is calculated for each class by multiplying each of the attribute
values with their corresponding coefficients. The class with the greatest value for the linear expression
is considered the top prediction.
Now consider the apply operation on the row shown below:
PROD_ID: 45
PROD_NAME: Vunelli Bb-956
PROD_LIST_PRICE: 79.95
PROD_DESC: famous Vunelli 3/4 Length Cargo Trouser
PROD_CATEGORY: Women
PROD_SUBCATEGORY: Shoes Women
The predicted class in this case is Women, therefore the keyword coefficients in the keyword mapping
table are generated as follows:
1. Assign TF-IDF Values: The keyword/weights generated are :
KEYWORD
18
VALUE
-----------VUNELLI
LENGTH
4
CARGO
3
TROUSER
FAMOUS
---------.532484
.492604
.38455
.38455
.364813
.212032
0
2. Global Co-efficient Values and Related Keywords: Since Women was the predicted class, you
can use the global coefficient values for the keywords from the Knowledge Base details table for this
class. These are shown below:
SA$MODEL_ID
-------------------1
1
1
1
1
1
CLASS
-------Women
Women
Women
Women
Women
Women
KEYWORD COEFFICIENT
-------------- ---------------3
-.12492003
4
-.10921244
CARGO
.096394381
LENGTH
.096640336
TROUSER .154780699
VUNELLI
.02028074
3. Calculate & Rank Multiplication Products: The keyword weight (TF-IDF) from text (step 1) is
multiplied by its corresponding coefficient (step 2) from the Knowledge Base for the predicted class,
and these multiplication products are ranked in descending order with only the top 5 (default) taken.
SA$MODEL_ID
-------------------1
1
1
1
1
SA$CASE_ID
-----------------
CLASS
--------
RNK
---------
45
45
45
45
45
Women
Women
Women
Women
Women
LENGTH
CARGO
TROUSER
VUNELLI
4
1
2
3
4
5
.047605416
.037068459
.032818461
.01079917
-.04199765
4. Calculate Normalization Number: The sum of the absolute values of the top 5 coefficients is
CLASS
-------Women
SUM_COEFFICIENTS
---------------.170289152
5. Calculate Normalized Keyword Co-efficient Values: Finally, the multiplication product from
step 4 is divided by the normalization number to produce the final keyword weighting coefficient.
These will not necessarily sum to 1 as the sign from the coefficient in step 5 is retained. But the
absolute value of the coefficients will sum to 1. So in the example, the final keyword coefficients are:
SA$CASE_ID
19
TLEVEL
PREDICTION
KEYWORD COEFFICIENT
---------------45
45
45
45
45
--------0
0
0
0
0
----------------Women
Women
Women
Women
Women
-----------LENGTH
CARGO
TROUSER
VUNELLI
4
----------.279556364
.217679511
.192721972
.063416663
-.24662549
20
The keyword weightages are the product of the global SVM coefficients (constant) and the TF-IDF
values assigned by Oracle Text (transaction-specific), therefore they will most likely always be
different between transactions. Additionally, the coefficients in the keyword map are normalized,
which might thereby lead to different weights in the transactions.
3. Can you change the number of keywords to be considered by the application for build and
apply operations?
The application allows you to specify MAX_DOCTERMS and MAX_FEATURES in the options
parameter passed to the build procedure. MAX_DOCTERMS is the upper limit on the number of
keywords that can represent one document. MAX_FEATURES is the upper limit on the number
of distinct keywords for the corpus of documents. Oracle Spend Classification uses the defaults (30,
5000). The lower number for MAX_DOCTERMS was chosen as the description field (document)
for a spend item is typically much smaller than what you would expect for a several page literary
document. The larger MAX_FEATURES was chosen to provide for a much richer feature set of
unique keywords that could be expected to be seen in spend item descriptions. It also allows for a
larger training set to be provided to the build process.
4. How do the calculations work out in case of multi-level Taxonomy?
The linear equations in an SVM model (or Knowledge Base) are not really equations, but rather set
of attribute/coefficient pairs plus a bias factor. There is one set per target class. The prediction
function puts the linear equation together by looking at the attribute/values of the incoming row,
matching it with the attribute/coefficients in the model and calculating the sum of multiplication
products for each attribute present in the row, one for each target class. The target class with the
largest final value is the predicted class.
Also, each SVM model has its own set of coefficients. In the Oracle Spend Classification
hierarchical model, at each node in the tree (Taxonomy), there is an SVM model. The SVM model
predicts the class at that level. Based on the predicted class, the tree is descended to the child node
for that class for which there is another SVM model. This is repeated until the tree leaf node is
reached.
5. Can there be scenarios where no keywords in a document get any weightage? How are such
situations handled?
The only scenarios where there could possibly be no keywords associated with a classification are
the cases where the item description is null, or contains words that are in the Stop List. When no
keywords are generated for a particular spend item, the prediction would be achieved using any
non-text attributes/values. In cases where the non-text attribute values are null for the given spend
item, the scoring function uses a missing value replacement mechanism instead. For numerical data
types, this number is simply the mean for all values for this attribute seen during training. For
categorical data types, this value is the mode (the most frequently seen) value during training.
Missing value replacement is not done for nested types which is how the document keywords are
represented, thus the fact that there are no keywords implies that the prediction will be made solely
on the non-text attributes (Line Amount in our case).
21
To fine tune your Knowledge Base take a training data set with populated categories and run a
Spend Classification TRAIN/TEST operation by specifying (SPLIT,TEST) in the build options.
This operation first performs a stratified split of the dataset allocating 60% to train, and 40% to
test. The system then builds the Knowledge Base using the training subset and thereafter runs an
apply operation on the test subset. Please ensure that you specify a value for the test_result_ds
parameter to build, because the test results get stored here. When the operation is completed, take
a look at the test result table. The content of the test result table for a sample run (for data with a 2
level Taxonomy) are listed below.
The class values where TLEVEL=0 are the PROD_CATEGORY predictions (or, Parent
Category). The class values below these where TLEVEL=1 are the PROD_SUBCATEGORY
predictions (or, Sub Category). The Training Dataset was populated with the correct category
codes for the Parent as well as the Sub category under the parent. The TEST operation first
performs an apply operation, and then cross-checks the predictions in the apply results table with
the actual values in the test dataset. This check is how the CORRECT and INCORRECT numbers
are calculated. From line 1, we know that in the test dataset there were 61 cases where the Parent
category was Boys, and the apply operation got 60 correct and 1 incorrect. The ID column is the
model id; hence the rows for ID=1 are the root level predictions, or predictions on
PROD_CATEGORY (which is why the FILTER column is NULL). The rows for ID=2, 3, 4, 5
are second level predictions, one each for the 4 classes from the root level. The more under
represented a particular class is the training data, the lower the percentage of correct predictions. If
you look at the cases where the percent is zero or low, we observe that the total number of
occurrences being scored is low. The input dataset had a stratified split (meaning the split attempts
to ensure that a proportionately equal number of target classes end up in the training dataset as in
the test dataset), thus you can surmise that these sub-classes are underrepresented in the training
dataset.
ID PARENT FILTER
TLEVEL
--- ------ ------------------------------1
0
1
0
1
0
1
0
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
2
1 "SA$PROD_CATEGORY"='Boys' 1
22
CLASS
-------------------------Boys
Men
Women
Girls
Shorts - Boys
Outerwear - Boys
Sleepwear - Boys
Shirts - Boys
Trousers And Jeans - Boys
Shoes - Boys
Underwear - Boys
Sweaters - Boys
Casual Shirts - Men
Outerwear - Men
Shirts - Girls
Outerwear - Girls
Sleepwear - Girls
1
6
9
6
0
0
0
0
0
0
0
1
1
1
1
2
2
98.4
93.1
91.8
85
100
100
100
100
100
100
100
66.7
0
0
0
0
0
2
3
3
3
3
3
3
3
3
3
4
4
4
4
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
5
5
5
5
23
1 "SA$PROD_CATEGORY"='Boys' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Girls' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Men' 1
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1 "SA$PROD_CATEGORY"='Women'
1
1
1
1
1
1
1
1
1
1
1
1
Trousers - Men
Outerwear - Girls
Trousers And Jeans - Girls
Dresses - Girls
Shorts - Girls
Skirts - Girls
Sleepwear - Girls
Shirts - Girls
Underwear - Girls
Shirts And Jackets - Women
Casual Shirts - Men
Dress Shirts - Men
Sportcoats - Men
Shorts - Men
Trousers - Men
Jeans - Men
Outerwear - Men
Sweaters - Men
Underwear And Socks - Men
Shirts And Jackets - Women
Shorts - Boys
Shoes - Women
Sweaters - Women
Knit Outfits - Women
Tees - Women
Dresses - Women
Shoes - Women
Skirts And Shorts - Women
Shirts And Jackets - Women
Easy Shapes - Women
Trousers - Women
Dresses - Girls
Outerwear - Women
Jeans - Men
0
1
4
5
5
6
3
2
4
0
5
6
4
6
22
12
11
7
5
0
0
0
1
12
9
16
14
5
9
8
12
0
0
0
2
0
0
0
0
0
1
1
2
1
0
0
0
0
0
0
1
1
1
2
1
6
0
0
1
2
2
1
2
2
4
1
1
2
0
100
100
100
100
100
75
66.7
66.7
0
100
100
100
100
100
100
91.7
87.5
83.3
0
0
0
100
100
90
88.9
87.5
83.3
81.8
80
75
0
0
0
Best
Practises
for
Creating
Spend
This document is provided for information purposes only, and the contents hereof are subject to change without notice. This
document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in
law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any
Sandeep Sood
liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our
prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
Worldwide Inquiries:
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
Phone: +1.650.506.7000
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0114
Fax: +1.650.506.7200
oracle.com