Einführung
In diesem Artikel werden wir verschiedene Möglichkeiten zur Extraktion von Daten aus Dokumenten diskutieren. Wir werden OCR+LLM mit Claude 3 Vision vergleichen und uns schnelle OCR-Transformer und cloud-native OCRs ansehen. Außerdem werden wir einen Codebeispiel für die Implementierung von OCR als einfache API mithilfe von docTR bereitstellen. Schließlich werden wir über Groq sprechen und wie es uns die beste Inferenzgeschwindigkeit für LLM bieten kann.
Wir werden dieses Repo aus den vorherigen Artikeln verwenden.
Anwendungsfall: Dokumentenscan zur Zeitersparnis
Sie haben eine SaaS, die Ihnen hilft, Rechnungen für Ihr Unternehmen hinzuzufügen/zu registrieren, ein klassisches Beispiel. In dieser Situation wird das Ergebnis von einem Menschen überwacht (Sie können das Gegenteil in diesem Beitrag sehen]) und wir wollen Geschwindigkeit aus Bequemlichkeit, also werden einige Halluzinationen oder Fehler akzeptabel und leicht vom Benutzer geändert, vorausgesetzt, dass dies nicht zu inakzeptabel ist.
Claude 3 Vision vs. OCR+LLM
Wir haben dies ausführlich in einem früheren Beitrag „Claude 3: The King of Data Extraction“ behandelt, daher werde ich mich nicht wiederholen. Aber ich werde eine einfache Gegenüberstellung beider Ansätze durchführen:
OCR+LLM und Vision haben ihre Vor- und Nachteile. Wenn Ihr Produkt wächst und skaliert, benötigen Sie wahrscheinlich eine Kombination aus beiden. OCR+LLM kann für Aufgaben wie Extraktion verwendet werden, während Vision oder eine Kombination aus beiden für Aufgaben wie Klassifizierung und detailliertere Extraktion verwendet werden kann.
Theoretische Grenzen von Claude 3 Vision
Lassen Sie uns die Grenzen von Claude Haiku testen, dem schnellsten und günstigsten der Claude 3-Modelle. Es hat einige Tendenzen zu halluzinieren, aber das ist nicht das Thema dieses Artikels :).
Wir werden diese Rechnung als Beispiel verwenden:
Einfach genug, um es in mehreren Beispielen zu testen. Lassen Sie uns das Protokoll definieren, das wir in unserer Anwendung verwenden werden:
invoice_number: "string" # Eindeutiger Bezeichner für die Rechnung
invoice_date: "string" # Format: YYYY-MM-DD
due_date: "string" # Format: YYYY-MM-DD
seller_details:
seller_name: "string"
seller_address:
street_number_and_name: "string"
city_or_town: "string"
country: "string"
buyer_details:
buyer_name: "string"
buyer_address:
street_number_and_name: "string"
city_or_town: "string"
country: "string"
buyer_email: "string"
buyer_phone_number: "string"
products_services:
- item_number: number # Sequentielle Nummer oder SKU
description: "string" # Kurze Beschreibung des Produkts/Dienstleistung
quantity: number
unit_price: number # Preis pro Einheit/Artikel
total_price: number # Berechnet als Menge * Einheitspreis
# Fügen Sie bei Bedarf weitere Artikel hinzu
sub_total: number # Gesamtbetrag vor Steuern und Gebühren
total: number # Berechnet als Zwischensumme * Steuersatz
Dieses Pseudo-YAML beschreibt alle Felder, die wir aus einer Rechnung extrahieren möchten. Wenn Sie dies zu verwirrend finden, können Sie einfach JSON oder sogar TypeScript verwenden. Im Repo ist die Eingabe ein agnostisches Textfeld aus genau diesem Grund.
Hier sind die Ergebnisse, nachdem ich mit dem Bild herumgespielt habe:
Nicht aufregend. Das Beste, was ich für Vision erreichen konnte, waren fast 1s, nur durch Drucken von 5 Tokens und mit einem 1kb-Bild. Wenn wir also etwas Schnelleres wollen, müssen wir etwas anderes verwenden.
OCR-Transformer, die für Geschwindigkeit entwickelt wurden
Die neue Ära der OCR basiert auf Transformatoren, in der Regel von Huggingface für die Ausführung auf Tensorflow/Pytorch in CPU/GPU trainiert. Hier sind einige der besten Erwähnungen:
- DocTR – Dieses OCR-Tool ist auch für eine hohe Geschwindigkeitsleistung auf beiden CPU und GPU optimiert. Es bietet einen benutzerfreundlichen Ansatz, bei dem nur drei Zeilen Code benötigt werden.
- TrOCR – Dies ist auch ein vortrainierter Transformer, der mehrere Modelle anbietet. Unterstützt von Microsoft.
- PaddleOCR – Es ist für Geschwindigkeit optimiert und kann große Mengen von Bildern in Echtzeit verarbeiten. Mit einer durchschnittlichen CPU-Verarbeitungszeit von nur 41 Millisekunden pro Bild.
- MMOCR
- Surya
Ich habe es im Leistungsmodus ausgeführt und 50 ms erhalten, und in einigen Fällen können Sie auf 20 ms in GPU heruntergehen. Ich habe einige der cloud-nativen OCRs getestet, die Sie haben:
- Azure Form Recognizer: Beste Leistungszeit von etwa 3 Sekunden, es ist immer in etwa dieser Wert. Die beste in Bezug auf die Gesamtgeschwindigkeit der Lösungen
- Amazon Textract: Amazon Textract verarbeitet Dokumente normalerweise in wenigen Sekunden pro Seite, in der Regel 3-4. Nicht viel anders als Azure Form Recognizer. Die Produkte sind ziemlich ähnlich, und es gibt nicht viel Unterschied zwischen Leistung und Kosten.
- Google Cloud Vision API und Document AI: Sehr effizient, solide und ähnlich zu beiden.
- Abby Cloud OCR: Ein Favorit der Entwickler. Es ist schneller als all diese Alternativen und gibt Ihnen eine Darstellung der Seite in Bezug auf die Lage, wäre perfekt zu verwenden in diesem Kontext, wenn es Ihnen passt.
Diese Produkte sind jetzt ausgereift. Sie haben den gleichen Preis und das gleiche Angebot.
Vor LLMs waren diese cloudbasierten AI-Dienste der Weg, den man einschlagen musste. Sie bieten Ihnen eine Vorlage zum Trainieren Ihrer Art von Dokumenten (z. B. Rechnung, Krankenakte), damit Sie die Informationen klassifizieren und extrahieren können. Aber das geht mit einem hohen Preis und einem Anbieter-Lock-in von der Box aus einher. Jetzt mit LLMs benötigen wir nur eine grundlegende Lesung oder einen einfachen Layout-Scan-Scan, der Sie einen Bruchteil der anderen Modelle kostet. Sobald das erledigt ist, können wir die erforderlichen Informationen mit dem LLM extrahieren, der den Großteil der Arbeit erledigt. Diese Methode funktioniert effizient und eliminiert die Notwendigkeit zusätzlicher Schritte und wird in Bezug auf Kosten und Ergebnisse besser sein.
Codebeispiel OCR
Lassen Sie uns unseren Code in Mikrodienste aufteilen. Die OCR wird eine einfache schnelle API in einem Docker-Container sein, so dass wir sie in verschiedenen Umgebungen bereitstellen und in Bezug auf die Konfiguration so viel wie nötig anpassen können.
Ich werde docTR (Document Text Recognition) für dieses Beispiel wählen, da es das einfachste ist, um es zu implementieren und auszuführen. Um mit dem Testen zu beginnen, habe ich einen einfachen docTR-Ordner im Repo mit einem Docker-Container erstellt, der bereit ist, ausgeführt zu werden. Sie können mit Docker mithilfe des folgenden Codes sofort mit dem Testen beginnen:
from fastapi import FastAPI, File, UploadFile
from fastapi.responses import JSONResponse
from doctr.io import DocumentFile
from doctr.models import ocr_predictor
from PIL import Image
import io
import os
app = FastAPI(title="OCR Service using docTR")
@app.post("/ocr/")
async def perform_ocr(file: UploadFile = File(...)):
image_data = await file.read()
# Attempt to load the image directly from the BytesIO object
doc = DocumentFile.from_images(image_data)
model = ocr_predictor(pretrained=True)
result = model(doc)
extracted_texts = []
for page in result.pages:
for block in page.blocks:
for line in block.lines:
line_text = ' '.join([word.value for word in line.words])
extracted_texts.append(line_text)
return JSONResponse(content={"ExtractedText": extracted_texts})
if __name__ == "__main__":
import uvicorn
uvicorn.run(app, host="0.0.0.0", port=8001)
Der Code ist einfach:
- Ein Endpunkt, der eine Datei empfängt.
- Ruft das docTR-Standardmodell auf.
- Führt die OCR aus und erhält alle Texte in ein Array.
Der Docker-Container installiert alle Abhängigkeiten:
# Use an official Python runtime as a parent image, suitable for TensorFlow
FROM tensorflow/tensorflow:latest
# Set the working directory in the container
WORKDIR /app
# Install system dependencies required for OpenCV and WeasyPrint
RUN apt-get update && apt-get install -y \
libgl1-mesa-glx \
libpango-1.0-0 \
libpangocairo-1.0-0 \
libgdk-pixbuf2.0-0 \
libffi-dev \
shared-mime-info
# Install FastAPI and Uvicorn
RUN pip install fastapi uvicorn python-multipart aiofiles Pillow
# Copy the local directory contents into the container
COPY . /app
# Install `doctr` with TensorFlow support
RUN pip install python-doctr[tf]
# Expose the port FastAPI will run on
EXPOSE 8001
# Command to run the FastAPI server on container start
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8001", "--workers", "4"]
Es gibt bereits Container, die Sie verwenden können. Diese Container haben viel kleinere und schlankere Modelle, die Sie für Ihre Experimentierzwecke testen und verwenden können. So können Sie sofort etwas haben, ohne sich verloren zu fühlen. Schließlich wird dies eine geladene Abhängigkeit in das Projekt sein.
Groq: Der König der Geschwindigkeit
Groq ist derzeit in aller Munde. Jeder spricht darüber, und ich empfehle Ihnen dringend, zu wissen, wie es in Bezug auf die Architektur funktioniert, denn es ist tatsächlich ein völlig anderes Paradigma (jeder Prozessor verfügt über 230 MB VRAM). Für diesen Artikel werde ich das kleinere Modell gemma-7b-it von Google verwenden.
https://console.groq.com/playground?model=gemma-7b-it
Sie haben auch Mixtral-8x7b und Llama2 70b verfügbar. Sie können auch Mixtral für diesen Anwendungsfall verwenden, es ist GPT3.5 in Bezug auf die Ergebnisse ähnlich.
Groq sollte in Ihren zukünftigen Stacks sein, wenn Geschwindigkeit der Name des Spiels ist.
OCR+Groq
Der Groq-Code ist, was Sie erwarten:
from groq import Groq
def send_request_to_groq(content: str) -> str:
client = Groq(api_key=API_KEY_GROQ)
completion = client.chat.completions.create(
model="gemma-7b-it",
messages=[
{
"role": "system",
"content": "You are an API server that receives content from a document and returns a JSON with the defined protocol"
},
{
"role": "user",
"content": content
}
],
temperature=1,
max_tokens=1024,
top_p=1,
stream=False, # Needs to be false
response_format={"type": "json_object"}, # just like in OpenAI API
stop=None,
)
return completion.choices[0].message.content
Das, was mich am meisten überrascht, ist das „response_format“, es ist eine erstaunliche Funktion, die andere Anbieter nicht haben. Also große Anerkennung an das Groq-Team!
Der endgültige Code ist der Controller. Es ist das gleiche wie der „extract“-Endpunkt, ruft nur Groq auf, also wird es zu „/extract_fast“. Sie sollten das OCR-Ergebnis entsprechend dem, was Sie verwenden, ändern.
@app.post("/extract_fast")
async def extract_text(file: UploadFile = File(...), extraction_contract: str = Form(...)):
# Create a temporary file and save the uploaded file to it
temp_file = tempfile.NamedTemporaryFile(delete=False)
shutil.copyfileobj(file.file, temp_file)
file_path = temp_file.name
# Convert PDF to images
images = convert_pdf_to_images(file_path)
# TODO: Change to OCR service once added
extracted_text = extract_text_with_pytesseract(images)
# Join the extracted text into a single string
extracted_text = "\n new page --- \n".join(extracted_text)
# add system message to the extracted text
extracted_text = systemMessage + "\n####Content\n\n" + extracted_text
# add contract to the extracted text
extracted_text = extracted_text + "\n####Structure of the JSON output file\n\n" + extraction_contract
# add response section
extracted_text = extracted_text + "\n#### JSON Response\n\n" + jsonContentStarter
# Measure the time before sending the request
start_time = time.time()
# Send the extracted text and extraction contract to the Mistral API
content = send_request_to_groq(extracted_text)
elapsed_time = time.time() - start_time
print(f"send_request_to_groq took {elapsed_time} seconds")
# Close and remove the temporary file
temp_file.close()
content = remove_json_format(content)
return json.loads(content)
Wenn Sie dies ausführen, erhalten Sie eine Aufteilung zwischen OCR und LLM. Ich habe Ergebnisse wie dieses erhalten:
Je nachdem, was Sie verwenden, erhalten Sie unterschiedliche Ergebnisse. Die Werteergebnisse sind ziemlich konservativ, wenn Sie einen GPU-Scan verwenden, können Sie leicht <200ms erhalten. Auf Groq können Sie 500ms auf der API ziehen, hoffentlich in der Zukunft.
Eine mögliche produktionsbereite Architektur
Also, um die obige Konversation zusammenzufassen, können wir den Stack im Bild schließen. Serverlose Container wie Azure Container Apps oder AWS Fargate sind großartige Kombinationen für diesen Fall. Sie würden einige Variationen entsprechend dem Stack haben, den Sie wählen, z. B. Azure Container Apps enthält serverlose mit GPU, aber nur dediziert pro Stunde. Für AWS wird normalerweise EC2 verwendet. Angesichts der Geschwindigkeit der meisten dieser OCRs auch auf CPU-Lasten kann dieser Anwendungsfall mit einem CPU-serverlosen Container gut genug sein.
Sie können den gleichen Ansatz für den LLM-Service verwenden. Groq wird wahrscheinlich für eine Weile begrenzt sein, also können Sie andere Dienste verwenden, wenn Geschwindigkeit kein Thema ist.
Schlussfolgerung
Wenn es um das Scannen von Dokumenten und die Extraktion von Daten geht, reichen möglicherweise nur visuelle Tools nicht aus. Durch die Verwendung von OCR+LLM mit GPU und Groq können Sie jedoch schnellere Ergebnisse für Fälle erzielen, in denen Geschwindigkeit von entscheidender Bedeutung ist. Dies ist besonders nützlich beim Lesen von Rechnungen, die über mobile Geräte erfasst wurden.
You are an article rewriter. Your task is to rewrite the article above, which is in English and contains HTML formatting. After careful consideration, rewrite the article in German while maintaining the original tone and using expressions that are more suitable for German conventions. If the original article includes images, please include the URL of the original image in the appropriate position in the new article, as images are an important part of the article and should not be omitted. Please output the rewritten article in Markdown format.
Schnelle Datenextraktion freischalten: Groq + OCR und Claude Vision Technologien
Einführung
In diesem Artikel werden wir verschiedene Möglichkeiten zur Extraktion von Daten aus Dokumenten diskutieren. Wir werden OCR+LLM mit Claude 3 Vision vergleichen und uns schnelle OCR-Transformer und cloud-native OCRs ansehen. Außerdem werden wir einen Codebeispiel für die Implementierung von OCR als einfache API mithilfe von docTR bereitstellen. Schließlich werden wir über Groq sprechen und wie es uns die beste Inferenzgeschwindigkeit für LLM bieten kann.
Wir werden dieses Repo aus den vorherigen Artikeln verwenden.
Anwendungsfall: Dokumentenscan zur Zeitersparnis
Sie haben eine SaaS, die Ihnen hilft, Rechnungen für Ihr Unternehmen hinzuzufügen/zu registrieren, ein klassisches Beispiel. In dieser Situation wird das Ergebnis von einem Menschen überwacht (Sie können das Gegenteil in diesem Beitrag sehen]) und wir wollen Geschwindigkeit aus Bequemlichkeit, also werden einige Halluzinationen oder Fehler akzeptabel und leicht vom Benutzer geändert, vorausgesetzt, dass dies nicht zu inakzeptabel ist.
Claude 3 Vision vs. OCR+LLM
Wir haben dies ausführlich in einem früheren Beitrag „Claude 3: The King of Data Extraction“ behandelt, daher werde ich mich nicht wiederholen. Aber ich werde eine einfache Gegenüberstellung beider Ansätze durchführen:
OCR+LLM und Vision haben ihre Vor- und Nachteile. Wenn Ihr Produkt wächst und skaliert, benötigen Sie wahrscheinlich eine Kombination aus beiden. OCR+LLM kann für Aufgaben wie Extraktion verwendet werden, während Vision oder eine Kombination aus beiden für Aufgaben wie Klassifizierung und detailliertere Extraktion verwendet werden kann.
Theoretische Grenzen von Claude 3 Vision
Lassen Sie uns die Grenzen von Claude Haiku testen, dem schnellsten und günstigsten der Claude 3-Modelle. Es hat einige Tendenzen zu halluzinieren, aber das ist nicht das Thema dieses Artikels :).
Wir werden diese Rechnung als Beispiel verwenden:
Einfach genug, um es in mehreren Beispielen zu testen. Lassen Sie uns das Protokoll definieren, das wir in unserer Anwendung verwenden werden:
invoice_number: "string" # Eindeutiger Bezeichner für die Rechnung
invoice_date: "string" # Format: YYYY-MM-DD
due_date: "string" # Format: YYYY-MM-DD
seller_details:
seller_name: "string"
seller_address:
street_number_and_name: "string"
city_or_town: "string"
country: "string"
buyer_details:
buyer_name: "string"
buyer_address:
street_number_and_name: "string"
city_or_town: "string"
country: "string"
buyer_email: "string"
buyer_phone_number: "string"
products_services:
- item_number: number # Sequentielle Nummer oder SKU
description: "string" # Kurze Beschreibung des Produkts/Dienstleistung
quantity: number
unit_price: number # Preis pro Einheit/Artikel
total_price: number # Berechnet als Menge * Einheitspreis
# Fügen Sie bei Bedarf weitere Artikel hinzu
sub_total: number # Gesamtbetrag vor Steuern und Gebühren
total: number # Berechnet als Zwischensumme * Steuersatz
Dieses Pseudo-YAML beschreibt alle Felder, die wir aus einer Rechnung extrahieren möchten. Wenn Sie dies zu verwirrend finden, können Sie einfach JSON oder sogar TypeScript verwenden. Im Repo ist die Eingabe ein agnostisches Textfeld aus genau diesem Grund.
Hier sind die Ergebnisse, nachdem ich mit dem Bild herumgespielt habe:
Nicht aufregend. Das Beste, was ich für Vision erreichen konnte, waren fast 1s, nur durch Drucken von 5 Tokens und mit einem 1kb-Bild. Wenn wir also etwas Schnelleres wollen, müssen wir etwas anderes verwenden.
OCR-Transformer, die für Geschwindigkeit entwickelt wurden
Die neue Ära der OCR basiert auf Transformatoren, in der Regel von Huggingface für die Ausführung auf Tensorflow/Pytorch in CPU/GPU trainiert. Hier sind einige der besten Erwähnungen:
- DocTR – Dieses OCR-Tool ist auch für eine hohe Geschwindigkeitsleistung auf beiden CPU und GPU optimiert. Es bietet einen benutzerfreundlichen Ansatz, bei dem nur drei Zeilen Code benötigt werden.
- TrOCR – Dies ist auch ein vortrainierter Transformer, der mehrere Modelle anbietet. Unterstützt von Microsoft.
- PaddleOCR – Es ist für Geschwindigkeit optimiert und kann große Mengen von Bildern in Echtzeit verarbeiten. Mit einer durchschnittlichen CPU-Verarbeitungszeit von nur 41 Millisekunden pro Bild.
- MMOCR
- Surya
Ich habe es im Leistungsmodus ausgeführt und 50 ms erhalten, und in einigen Fällen können Sie auf 20 ms in GPU heruntergehen. Ich habe einige der cloud-nativen OCRs getestet, die Sie haben:
- Azure Form Recognizer: Beste Leistungszeit von etwa 3 Sekunden, es ist immer in etwa dieser Wert. Die beste in Bezug auf die Gesamtgeschwindigkeit der Lösungen
- Amazon Textract: Amazon Textract verarbeitet Dokumente normalerweise in wenigen Sekunden pro Seite, in der Regel 3-4. Nicht viel anders als Azure Form Recognizer. Die Produkte sind ziemlich ähnlich, und es gibt nicht viel Unterschied zwischen Leistung und Kosten.
- Google Cloud Vision API und Document AI: Sehr effizient, solide und ähnlich zu beiden.
- Abby Cloud OCR: Ein Favorit der Entwickler. Es ist schneller als all diese Alternativen und gibt Ihnen eine Darstellung der Seite in Bezug auf die Lage, wäre perfekt zu verwenden in diesem Kontext, wenn es Ihnen passt.
Diese Produkte sind jetzt ausgereift. Sie haben den gleichen Preis und das gleiche Angebot.
Vor LLMs waren diese cloudbasierten AI-Dienste der Weg, den man einschlagen musste. Sie bieten Ihnen eine Vorlage zum Trainieren Ihrer Art von Dokumenten (z. B. Rechnung, Krankenakte), damit Sie die Informationen klassifizieren und extrahieren können. Aber das geht mit einem hohen Preis und einem Anbieter-Lock-in von der Box aus einher. Jetzt mit LLMs benötigen wir nur eine grundlegende Lesung oder einen einfachen Layout-Scan-Scan, der Sie einen Bruchteil der anderen Modelle kostet. Sobald das erledigt ist, können wir die erforderlichen Informationen mit dem LLM extrahieren, der den Großteil der Arbeit erledigt. Diese Methode funktioniert effizient und eliminiert die Notwendigkeit zusätzlicher Schritte und wird in Bezug auf Kosten und Ergebnisse besser sein.
Codebeispiel OCR
Lassen Sie uns unseren Code in Mikrodienste aufteilen. Die OCR wird eine einfache schnelle API in einem Docker-Container sein, so dass wir sie in verschiedenen Umgebungen bereitstellen und in Bezug auf die Konfiguration so viel wie nötig anpassen können.
Ich werde docTR (Document Text Recognition) für dieses Beispiel wählen, da es das einfachste ist, um es zu implementieren und auszuführen. Um mit dem Testen zu beginnen, habe ich einen einfachen docTR-Ordner im Repo mit einem Docker-Container erstellt, der bereit ist, ausgeführt zu werden. Sie können mit Docker mithilfe des folgenden Codes sofort mit dem Testen beginnen:
from fastapi import FastAPI, File, UploadFile
from fastapi.responses import JSONResponse
from doctr.io import DocumentFile
from doctr.models import ocr_predictor
from PIL import Image
import io
import os
app = FastAPI(title="OCR Service using docTR")
@app.post("/ocr/")
async def perform_ocr(file: UploadFile = File(...)):
image_data = await file.read()
# Attempt to load the image directly from the BytesIO object
doc = DocumentFile.from_images(image_data)
model = ocr_predictor(pretrained=True)
result = model(doc)
extracted_texts = []
for page in result.pages:
for block in page.blocks:
for line in block.lines:
line_text = ' '.join([word.value for word in line.words])
extracted_texts.append(line_text)
return JSONResponse(content={"ExtractedText": extracted_texts})
if __name__ == "__main__":
import uvicorn
uvicorn.run(app, host="0.0.0.0", port=8001)
Der Code ist einfach:
- Ein Endpunkt, der eine Datei empfängt.
- Ruft das docTR-Standardmodell auf.
- Führt die OCR aus und erhält alle Texte in ein Array.
Der Docker-Container installiert alle Abhängigkeiten:
# Use an official Python runtime as a parent image, suitable for TensorFlow
FROM tensorflow/tensorflow:latest
# Set the working directory in the container
WORKDIR /app
# Install system dependencies required for OpenCV and WeasyPrint
RUN apt-get update && apt-get install -y \
libgl1-mesa-glx \
libpango-1.0-0 \
libpangocairo-1.0-0 \
libgdk-pixbuf2.0-0 \
libffi-dev \
shared-mime-info
# Install FastAPI and Uvicorn
RUN pip install fastapi uvicorn python-multipart aiofiles Pillow
# Copy the local directory contents into the container
COPY . /app
# Install `doctr` with TensorFlow support
RUN pip install python-doctr[tf]
# Expose the port FastAPI will run on
EXPOSE 8001
# Command to run the FastAPI server on container start
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8001", "--workers", "4"]
Es gibt bereits Container, die Sie verwenden können. Diese Container haben viel kleinere und schlankere Modelle, die Sie für Ihre Experimentierzwecke testen und verwenden können. So können Sie sofort etwas haben, ohne sich verloren zu fühlen. Schließlich wird dies eine geladene Abhängigkeit in das Projekt sein.
Groq: Der König der Geschwindigkeit
Groq ist derzeit in aller Munde. Jeder spricht darüber, und ich empfehle Ihnen dringend, zu wissen, wie es in Bezug auf die Architektur funktioniert, denn es ist tatsächlich ein völlig anderes Paradigma (jeder Prozessor verfügt über 230 MB VRAM). Für diesen Artikel werde ich das kleinere Modell gemma-7b-it von Google verwenden.
https://console.groq.com/playground?model=gemma-7b-it
Sie haben auch Mixtral-8x7b und Llama2 70b verfügbar. Sie können auch Mixtral für diesen Anwendungsfall verwenden, es ist GPT3.5 in Bezug auf die Ergebnisse ähnlich.
Groq sollte in Ihren zukünftigen Stacks sein, wenn Geschwindigkeit der Name des Spiels ist.
OCR+Groq
Der Groq-Code ist, was Sie erwarten:
from groq import Groq
def send_request_to_groq(content: str) -> str:
client = Groq(api_key=API_KEY_GROQ)
completion = client.chat.completions.create(
model="gemma-7b-it",
messages=[
{
"role": "system",
"content": "You are an API server that receives content from a document and returns a JSON with the defined protocol"
},
{
"role": "user",
"content": content
}
],
temperature=1,
max_tokens=1024,
top_p=1,
stream=False, # Needs to be false
response_format={"type": "json_object"}, # just like in OpenAI API
stop=None,
)
return completion.choices[0].message.content
Das, was mich am meisten überrascht, ist das „response_format“, es ist eine erstaunliche Funktion, die andere Anbieter nicht haben. Also große Anerkennung an das Groq-Team!
Der endgültige Code ist der Controller. Es ist das gleiche wie der „extract“-Endpunkt, ruft nur Groq auf, also wird es zu „/extract_fast“. Sie sollten das OCR-Ergebnis entsprechend dem, was Sie verwenden, ändern.
@app.post("/extract_fast")
async def extract_text(file: UploadFile = File(...), extraction_contract: str = Form(...)):
# Create a temporary file and save the uploaded file to it
temp_file = tempfile.NamedTemporaryFile(delete=False)
shutil.copyfileobj(file.file, temp_file)
file_path = temp_file.name
# Convert PDF to images
images = convert_pdf_to_images(file_path)
# TODO: Change to OCR service once added
extracted_text = extract_text_with_pytesseract(images)
# Join the extracted text into a single string
extracted_text = "\n new page --- \n".join(extracted_text)
# add system message to the extracted text
extracted_text = systemMessage + "\n####Content\n\n" + extracted_text
# add contract to the extracted text
extracted_text = extracted_text + "\n####Structure of the JSON output file\n\n" + extraction_contract
# add response section
extracted_text = extracted_text + "\n#### JSON Response\n\n" + jsonContentStarter
# Measure the time before sending the request
start_time = time.time()
# Send the extracted text and extraction contract to the Mistral API
content = send_request_to_groq(extracted_text)
elapsed_time = time.time() - start_time
print(f"send_request_to_groq took {elapsed_time} seconds")
# Close and remove the temporary file
temp_file.close()
content = remove_json_format(content)
return json.loads(content)
Wenn Sie dies ausführen, erhalten Sie eine Aufteilung zwischen OCR und LLM. Ich habe Ergebnisse wie dieses erhalten:
Je nachdem, was Sie verwenden, erhalten Sie unterschiedliche Ergebnisse. Die Werteergebnisse sind ziemlich konservativ, wenn Sie einen GPU-Scan verwenden, können Sie leicht <200ms erhalten. Auf Groq können Sie 500ms auf der API ziehen, hoffentlich in der Zukunft.
Eine mögliche produktionsbereite Architektur
Also, um die obige Konversation zusammenzufassen, können wir den Stack im Bild schließen. Serverlose Container wie Azure Container Apps oder AWS Fargate sind großartige Kombinationen für diesen Fall. Sie würden einige Variationen entsprechend dem Stack haben, den Sie wählen, z. B. Azure Container Apps enthält serverlose mit GPU, aber nur dediziert pro Stunde. Für AWS wird normalerweise EC2 verwendet. Angesichts der Geschwindigkeit der meisten dieser OCRs auch auf CPU-Lasten kann dieser Anwendungsfall mit einem CPU-serverlosen Container gut genug sein.
Sie können den gleichen Ansatz für den LLM-Service verwenden. Groq wird wahrscheinlich für eine Weile begrenzt sein, also können Sie andere Dienste verwenden, wenn Geschwindigkeit kein Thema ist.
Schlussfolgerung
Wenn es um das Scannen von Dokumenten und die Extraktion von Daten geht, reichen möglicherweise nur visuelle Tools nicht aus. Durch die Verwendung von OCR+LLM mit GPU und Groq können Sie jedoch schnellere Ergebnisse für Fälle erzielen, in denen Geschwindigkeit von entscheidender Bedeutung ist. Dies ist besonders nützlich beim Lesen von Rechnungen, die über mobile Geräte erfasst wurden.
