Skip to content

Setup and Programmatic Access

RAG Configuration: Private Cloud

Private cloud customers have two available methods for administering the RAG. The first is to use standard command line tools to populate an S3 bucket with data and trigger the database to be built. The second is a user-friendly webapp which PrimisAI provides as a docker container. Regardless of the method chosen, configuring Magnus to use RAG is straightforward. The API container uses the following environment variables to retrieve documents for the RAG:

  • aws_code_dka_uri - the URI of the S3 bucket
  • aws_bucket_name_dka - the name of the S3 bucket
  • dka_s3 - Must be set to True

Programmatic access

For users who are familiar with developing AWS solutions, the most powerful way to populate the RAG database is to build a custom solution. The Magnus API provides an endpoint, /refresh-knowledge, that reads data from an S3 bucket and builds the RAG database. The database is also refreshed when the API service restarts.

By using the standard AWS tools such as the AWS CLI, SDKs, or systems manager, customers may build a solution tailored to their business needs. This could be as simple as using the AWS console to upload objects to the RAG's S3 bucket and setting up a lambda trigger to send a POST request to the /refresh-knowledge endpoint whenever new objects are uploaded. This could also be something complex, for example a python script could retrieve HDL from a private source control system, select relevant modules (for example, excluding synthesized code, wrappers, etc), retrieve appropriate documentation from a cloud provider, extract keywords from the documentation with an NLP library, inject those keywords as comments into the matching HDL to help improve the RAG's accuracy, and then upload the modified files to S3.

When developing a solution, keep the following information in mind. The archive directory, s3://example-bucket/archive/*, is reserved and objects in it will be ignored. Otherwise, directory structure is up to the customer's RAG administrator and will not impact database generation. The following file types are supported:

  • .v
  • .sv
  • .vhd
  • .tcl
  • .txt
  • .md
  • .pdf
  • .doc
  • .docx
  • .ppt
  • .pptx
  • .csv

The API performs database generation based on the files in S3. The database itself is stored in the API container. Therefor the database must be rebuilt for changes in the S3 bucket to take effect. To rebuild the database, send a request to the API container's /refresh-knowledge endpoint with the following format:

1
2
3
4
curl -X 'POST' \
    'http://<api_container_host>:<api_container_port>/refresh-knowledge' \
    -H 'accept: application/json' \
    -d ''

Viewing RAG Logs on AWS

The administrator managing the Magnus and RAG deployment may occasionally find it useful to inspect API service logs, as they contain information about the documents used in answering each user query. This can be done in many ways, and customers with existing AWS infrastructure should configure Magnus as they would any other service. For customers unfamiliar with collecting logs in AWS, the following sample configuration is a starting point.

Assuming that the container is running in an EC2 instance and that logs will be monitored through CloudWatch, start the container with the following flags.

1
docker run -d --log-driver=awslogs --log-opt awslogs-region=myLogRegion --log-opt awslogs-group=myLogGroup --log-opt awslogs-create-group=true <any other docker flags>  magnus:latest

The credentials used to launch docker must have a IAM policy attached that allows the following actions:

logs:CreateLogStream
logs:PutLogEvents
logs:CreateLogGroup

If an appropriate log group already exists, the awslogs-create-group flag and associate IAM permissions may be omitted. Following this configuration, logs can be viewed by loggroup in the AWS CloudWatch console, either line-by-line or as a live tail.

On Premise

On-premise customers may populate the RAG database by adding files to a directory called data located in the root Magnus directory. The database will be (re)built when the API service restarts.