Domain Knowledge Graph Construction Via A Simple Checker

The release of large language models (LLMs), e.g., Brown et al. (2020); Bommasani et al. (2021); OpenAI (2023), has motivated many semiconductor chip design companies to license the technology for in-house use and explore various applications. One interesting application area is for better organizing the tremendous amount of text data accumulated over the years. For a semiconductor company, these data can include specifications, test plans, bug reports, meeting notes, and so on. They are collected for generations of designs from various stages of a design cycle. There is a constant need to find ways to improve the within-the-company knowledge accumulation and sharing over those data.

In this context, we study the feasibility of using an LLM for knowledge graph construction. There are two important considerations. To protect proprietary information, the LLM has to be used in an in-house environment closed from the outside world. Because many of those companies might not maintain sufficient resources to conduct effective fine-tuning or retraining of an LLM, it is more practical to assume that the LLM would be used as it is. Furthermore, it is also desirable that the construction process of knowledge graph can follow an iterative fashion, where the graph is expanded gradually as more text items are processed.

We therefore consider our knowledge graph construction (KGC) as the following: Given an ordered sequence of text items $T_{1},\ldots,T_{n}$, KGC processes one $T_{i}$ at a time from 1 to $n$ and generates an individual knowledge graph (KG): $g_{i}=KGC(T_{i})$. Let $G_{i-1}$ be the KG after merging all $g_{1},\ldots,g_{i-1}$. We obtain $G_{i}=MERGE(G_{i-1},g_{i})$.

In this work, we use RISC-V unprivileged ISA specification (“the Spec”) Waterman and Asanovi´c (2019) as an example. We consider each paragraph as a text item. We choose GPT3.5 OpenAI as our LLM to use. For implementing the $KGC$ step, we rely only on prompting to the LLM.

Figure 1 shows an example of the KGC. The KG is represented in the Turtle Terse RDF Triple language (RDF TTL) Beckett and Berners-Lee (2011). The specific prompt in use is shown in the figure. The input paragraph can be seen in two parts: (1) definition of the SLTI instruction, and (2) definition of the SLTIU instruction.

Notice that the second sentence starts with “SLTIU is similar” by referencing to the first sentence. The RDF output is shown as four “Facts”. The most interesting aspect of the result is shown in “Fact 2” for SLTIU where the RDF duplicates all the predicates used in “Fact 1”, i.e. compareAgainst, comparesSignedNumbers, comparesUnsignedNumbers, and comparesWith. This indicates that the LLM does understand the phrase “is similar” and reflects its understanding in copying the RDF representation of SLTI.

As far as we know, we are among the first to tackle the problem of KGC for unstructured text data in the semiconductor chip design domain. Documents in such a company often involve terminologies not known to the outside world. Hence, it is intuitive to think that KGC for those texts requires a domain person to provide some background knowledge to at least cover those terminologies. This thinking motivated us to take the view of supplying BFs.

Knowledge graph construction is a rich field with many techniques having been proposed to solve the problem Yan et al. (2018); Ye et al. (2022). Conventional methods to constructing knowledge graphs follow a pipeline of NLP sub-tasks Luan et al. (2018) such as entity recognition Tjong Kim Sang and De Meulder (2003), entity linking Milne and Witten (2008), relation extraction Zelenko et al. (2002), and coreference resolution Zelenko et al. (2004) etc. Among the various tasks, named entity recognition (NER) provides a fundamental first step for domain knowledge acquisition. Standard off-the-shelf toolkits for NER Bird (2006); Manning et al. (2014); Finkel et al. (2005); Liao and Veeramachaneni (2009) combines machine learning models and rule-based components to label entities. Recent works solve the problem in an end-to-end fashion using deep learning models Mondal et al. (2021); Harnoune et al. (2021); Ye et al. (2022). However, pre-trained models often incur low accuracy since training data from general public domain rarely covers our domain specific patterns. It is hard to iteratively ingest domain experts’ knowledge to further improve the accuracy without dedicated retraining. Finetuning or retraining is often not a desirable option for many hardware companies because of the tremendous efforts required to create curated databases for the training tasks. Another potential route to our KGC problem is to implement customized rule-based extractors with features provided by existing constituency and/or dependency parsers Chen and Manning (2014); Zhu et al. (2013). However, to our experience the set of rules can quickly grow overly-complicated and it is difficult for the approach to scale.

Restricting the output of a generative LM into a formal representation is related to the problem of constrained semantic parsing Shin et al. (2021); Lu et al. (2021). A structured meaning representation is often chosen as the output format Wolfson et al. (2020). However, converting the meaning representation into a KG can be another potential barrier. In summary, prompting an LLM to directly generate an RDF, if practical, can bypass all the complications mentioned above. This would not be feasible without the latest developments of the LLMs.

Despite that automatic knowledge graph construction in specific domain still remains an open challenge problem Yan et al. (2018), a major difference of this work is that we are not trying to propose another KGC solver. Rather, we focus on verifying the result given by such a solver, in our case the GPT3.5. In other words, our work is not about being a technology provider as those surveyed in Yan et al. (2018); Ye et al. (2022). Instead, we take the perspective of being a technology consumer. From this perspective, we study what features are required for a practical KGC solver.

Our Oracle-Checker (OC) view was inspired by the theoretical model of Interactive Proofs (IP) Arora and Barak (2012). An IP system comprises a prover and a verifier. The prover is assumed to be an all-powerful machine. The verifier is a probabilistic machine. The IP approach was developed to characterize computational complexity classes.

In an IP system, the verifier interrogates the prover through a sequence of communications. At the end the verifier either is convinced that the answer provided by the prover is correct or reject it. An important aspect in the communications is to keep the prover honest. Because verifier’s computational power is limited, it is mostly prover’s job to make the verification task as easy as possible.

Our OC view is different from the IP approach though. This is because what we consider the oracle (corresponding to the prover) has a limited power in practice. In addition, our oracle is probabilistic. On the other hand, our checker still needs a way to keep the oracle “honest”, i.e. a way to verify the answer provided by the oracle. However, because our oracle is not all powerful, we can no longer expect the oracle to give a form of answer that is always easily verifiable. This makes the verification harder than that in the theoretical IP model.

Figure 3 depicts our OC scheme. In our scheme we introduce a human verifier. The verifier comprises two parts: the simple checker and the human verifier. The ultimate decision to accept or reject an answer (RDF) stays with the human verifier. The job of the simple checker is to analyze the answer and provide feedback to help the human verifier.

Instead of asking the oracle to make the verification task easier for the verifier, if needed we require the verifier to make the task easier for the oracle. In our OC scheme, there are only two ways the verifier can do this: (1) by providing BFs and (2) occasionally by splitting a paragraph into multiple sub-paragraphs. Note that making the task easier is opposite to that in the theoretical IP model where the task is made easier for the verifier. Therefore, we can think that in our OC scheme, the oracle is powerful but not all powerful, and some of the power still resides with the human verifier.

We focus our discussion with paragraphs from the first two chapters of the RISC-V Spec. The first chapter provides a general introduction. The second chapter provides specification of the instructions from the RV32I integer instruction set. The rest of the chapters are similar to the second chapter, providing specification for a particular instruction set defined in RISC-V. The example in Figure 1 is from chapter 2. Because the descriptions from chapter 1 are more high-level, we expected that KGC would be more difficult for those paragraphs. However, as our analysis will show later, we find no significant difference on the GPT3.5’s performance for paragraphs from the two chapters.

We let BF$\phi$ refer to the KGC without BFs, and BF$A$ refer to the KGC with BFs added. Further, BF$\phi$-Pass refers to those paragraphs whose RDFs pass the entailment check, and BF$\phi$-Fail refers to those failing the check. Next we focus on comparing the the changes of RDFs from BF$\phi$ to BF$A$.

There can be several metrics to measure the RDF changes from BF$\phi$ to BF$A$, including: (1) the number of entities (entity coverage), (2) the set of subject entities, (3) the number of triples (fact coverage), and (4) the number of predicates (relations or features or both). In addition, we can consider those metrics separately from Facts passing and from Facts failing the entailment check.

From the KGC process, in addition to consistency we can consider another metric measuring the variations of subject entities across the 10 RDFs. We use a conformity score defined as the ratio between the sum of individual numbers of subject entities and the size of the union set of the subject entities, across the 10 RDFs. A score 10 means every RDF uses the same set of subject entities. A score 1 means everyone uses a different set. We found no obvious trend based on the changes of conformity scores from BF$\phi$ to BF$A$. We also found no obvious correlation between the conformity score changes and the changes on the number of entities from BF$\phi$ to BF$A$ (see Section A.3).

In general we found the number of predicates a less effective metric. This is because the same predicate can be used in many triples. Hence the number of predicates used in an RDF reveals little information about each predicate’s usage frequency.

Note that for a given metric, separating its numbers based on passing and failing the entailment check can be difficult. This is because entailment check is applied to a Fact. As a result, pass/fail is applied to the entire Fact and may not reflect the pass/fail of a particular triple, entity, or predicate.

We did find that separating the scenario BF$\phi$-Pass from the scenario BF$\phi$-Fail was helpful, enabling us to observe some interesting trends.

There are two primary tasks for the human verifier: (1) deciding when to split a paragraph into sub-paragraphs, and (2) deciding what BFs to provide.

Empirically, splitting a paragraph can be due to three reasons: (1) When a paragraph is too lengthy (e.g. a long paragraph followed by a list of bullet points), splitting can help. This is the obvious case. (2) If a paragraph contains a question raised, followed by an answer author provides, then it is helpful to separate the question from the answer. (3) When a paragraph contains statements regarding other architectural domains (e.g. MIPS, SPARC, etc), it is helpful to separate those non-RSIC-V descriptions from the RISC-V descriptions.

To our experience, the results from BF$\phi$ can be informative for choosing BFs. Further, preparing BFs can follow several guidelines: (1) For an abbreviation or convention defined earlier or somewhere else, a BF needs to be provided. If not, GPT3.5 may supply its own meaning which can be wrong. (2) When we want to guide the KGC to focus on an entity as the main topic, we can provide a BF about the entity (see the example in Section A.6.1). (3) When the paragraph involves several concept described in long phrases, providing BFs that emphasize each long phrase as a single concept can help reduce the KGC complexity (see the example in Section A.6). (4) When we desire to include a missing fact detail involving an entity, we can “remind” GPT3.5 by providing a BF about the entity (e.g. Figure 2). However, this might not always work as occasionally GPT3.5 can choose ignore a BF completely.

In general, we found that adding too many unnecessary BFs could degrade the quality of the resulting RDF. Hence, the BFs should not be excessive. We also found that we should avoid adding a BF describing a relation between two entities which are already related by the paragraph. This superimposition of relations could cause the KGC process to fail or even enter a repeated loop.

As the first step, our work shows the feasibility of the proposed OC scheme. We have not demonstrated how to improve its automation. Manual efforts are required to prepare the BFs and review the entailment check results. Although we have seen several guidelines to prepare BFs, the manual process remains ad hoc at this stage.

Note that with more familiarity of the content described in the Spec, we found that preparing the BFs could be done quickly (minutes for a section). Reviewing the results from the entailment check was not a time-consuming task either. The most time-consuming task was to deal with those difficult cases when the RDF remained unsatisfied after several trials. We could spend over an hour on each of those cases (counting the GPT3.5 calling time).

This work demonstrates the feasibility to use GPT3.5 for KGC on texts in the semiconductor chip design domain. We propose an OC scheme to use GPT3.5 as an oracle and the essence is using BFs to influence the oracle’s behavior. The communications to GPT3.5 are through a simple checker that imposes two checks: the consistency check and the entailment check. We consider them as requirements for an LLM to be used as an oracle.

Our current OC scheme requires a human verifier whose primary job is to review the results of the entailment check and prepare BFs. To what extent this manual process can be automated and how to do it are interesting questions for further research.