Skip to main content
This notebook covers how to load documents from Docugami. It provides the advantages of using this system over alternative data loaders.

Prerequisites

  1. Install necessary python packages.
  2. Grab an access token for your workspace, and make sure it is set as the DOCUGAMI_API_KEY environment variable.
  3. Grab some docset and document IDs for your processed documents, as described here: help.docugami.com/home/docugami-api

Quick start

  1. Create a Docugami workspace (free trials available)
  2. Add your documents (PDF, DOCX or DOC) and allow Docugami to ingest and cluster them into sets of similar documents, e.g. NDAs, Lease Agreements, and Service Agreements. There is no fixed set of document types supported by the system, the clusters created depend on your particular documents, and you can change the docset assignments later.
  3. Create an access token via the Developer Playground for your workspace. Detailed instructions
  4. Explore the Docugami API to get a list of your processed docset IDs, or just the document IDs for a particular docset.
  5. Use the DocugamiLoader as detailed below, to get rich semantic chunks for your documents.
  6. Optionally, build and publish one or more reports or abstracts. This helps Docugami improve the semantic XML with better tags based on your preferences, which are then added to the DocugamiLoader output as metadata. Use techniques like self-querying retriever to do high accuracy Document QA.

Advantages vs other chunking techniques

Appropriate chunking of your documents is critical for retrieval from documents. Many chunking techniques exist, including simple ones that rely on whitespace and recursive chunk splitting based on character length. Docugami offers a different approach:
  1. Intelligent Chunking: Docugami breaks down every document into a hierarchical semantic XML tree of chunks of varying sizes, from single words or numerical values to entire sections. These chunks follow the semantic contours of the document, providing a more meaningful representation than arbitrary length or simple whitespace-based chunking.
  2. Semantic Annotations: Chunks are annotated with semantic tags that are coherent across the document set, facilitating consistent hierarchical queries across multiple documents, even if they are written and formatted differently. For example, in set of lease agreements, you can easily identify key provisions like the Landlord, Tenant, or Renewal Date, as well as more complex information such as the wording of any sub-lease provision or whether a specific jurisdiction has an exception section within a Termination Clause.
  3. Structured Representation: In addition, the XML tree indicates the structural contours of every document, using attributes denoting headings, paragraphs, lists, tables, and other common elements, and does that consistently across all supported document formats, such as scanned PDFs or DOCX files. It appropriately handles long-form document characteristics like page headers/footers or multi-column flows for clean text extraction.
  4. Additional Metadata: Chunks are also annotated with additional metadata, if a user has been using Docugami. This additional metadata can be used for high-accuracy Document QA without context window restrictions. See detailed code walk-through below.

Load documents

If the DOCUGAMI_API_KEY environment variable is set, there is no need to pass it in to the loader explicitly otherwise you can pass it in as the access_token parameter.
The metadata for each Document (really, a chunk of an actual PDF, DOC or DOCX) contains some useful additional information:
  1. id and source: ID and Name of the file (PDF, DOC or DOCX) the chunk is sourced from within Docugami.
  2. xpath: XPath inside the XML representation of the document, for the chunk. Useful for source citations directly to the actual chunk inside the document XML.
  3. structure: Structural attributes of the chunk, e.g. h1, h2, div, table, td, etc. Useful to filter out certain kinds of chunks if needed by the caller.
  4. tag: Semantic tag for the chunk, using various generative and extractive techniques. More details here: github.com/docugami/DFM-benchmarks
You can control chunking behavior by setting the following properties on the DocugamiLoader instance:
  1. You can set min and max chunk size, which the system tries to adhere to with minimal truncation. You can set loader.min_text_length and loader.max_text_length to control these.
  2. By default, only the text for chunks is returned. However, Docugami’s XML knowledge graph has additional rich information including semantic tags for entities inside the chunk. Set loader.include_xml_tags = True if you want the additional xml metadata on the returned chunks.
  3. In addition, you can set loader.parent_hierarchy_levels if you want Docugami to return parent chunks in the chunks it returns. The child chunks point to the parent chunks via the loader.parent_id_key value. This is useful e.g. with the MultiVector Retriever for small-to-big retrieval. See detailed example later in this notebook.

Basic use: Docugami loader for document QA

You can use the Docugami Loader like a standard loader for Document QA over multiple docs, albeit with much better chunks that follow the natural contours of the document. There are many great tutorials on how to do this, e.g. this one. We can just use the same code, but use the DocugamiLoader for better chunking, instead of loading text or PDF files directly with basic splitting techniques.
The documents returned by the loader are already split, so we don’t need to use a text splitter. Optionally, we can use the metadata on each document, for example the structure or tag attributes, to do any post-processing we want. We will just use the output of the DocugamiLoader as-is to set up a retrieval QA chain the usual way.

Using docugami knowledge graph for high accuracy document QA

One issue with large documents is that the correct answer to your question may depend on chunks that are far apart in the document. Typical chunking techniques, even with overlap, will struggle with providing the LLM sufficient context to answer such questions. With upcoming very large context LLMs, it may be possible to stuff a lot of tokens, perhaps even entire documents, inside the context but this will still hit limits at some point with very long documents, or a lot of documents. For example, if we ask a more complex question that requires the LLM to draw on chunks from different parts of the document, even OpenAI’s powerful LLM is unable to answer correctly.
At first glance the answer may seem reasonable, but it is incorrect. If you review the source chunks carefully for this answer, you will see that the chunking of the document did not end up putting the Landlord name and the rentable area in the same context, and produced irrelevant chunks therefore the answer is incorrect (should be 13,500 sq ft) Docugami can help here. Chunks are annotated with additional metadata created using different techniques if a user has been using Docugami. More technical approaches will be added later. Specifically, let’s ask Docugami to return XML tags on its output, as well as additional metadata:
We can use a self-querying retriever to improve our query accuracy, using this additional metadata:
Let’s run the same question again. It returns the correct result since all the chunks have metadata key/value pairs on them carrying key information about the document even if this information is physically very far away from the source chunk used to generate the answer.
This time the answer is correct, since the self-querying retriever created a filter on the landlord attribute of the metadata, correctly filtering to document that specifically is about the DHA Group landlord. The resulting source chunks are all relevant to this landlord, and this improves answer accuracy even though the landlord is not directly mentioned in the specific chunk that contains the correct answer.

Advanced topic: Small-to-Big retrieval with document knowledge graph hierarchy

Documents are inherently semi-structured and the DocugamiLoader is able to navigate the semantic and structural contours of the document to provide parent chunk references on the chunks it returns. This is useful e.g. with the MultiVector Retriever for small-to-big retrieval. To get parent chunk references, you can set loader.parent_hierarchy_levels to a non-zero value.