You can deploy this model and start earning money today!

skyeen623/
RAGDemo

Views

No views yet

Với một dự án LangGraph kiểu RAG production như bạn mô tả:

text

layout_analysis
chunk
embedding
qdrant
llm

thì cách tổ chức folder rất quan trọng.

Vì LangGraph project KHÔNG nên tổ chức kiểu:

script-based
notebook-style
"mọi thứ trong 1 file"

Mà nên tổ chức theo:

workflow orchestration + domain module separation

1. Kiến trúc folder production-grade tôi khuyên dùng

Tôi sẽ đề xuất structure kiểu này:

text

project_root/
│
├── README.md
├── pyproject.toml
├── langgraph.json
├── .env
│
├── src/
│   └── rag_system/
│
│       ├── graph/
│       │   ├── builder.py
│       │   ├── nodes/
│       │   │   ├── ingest.py
│       │   │   ├── retrieve.py
│       │   │   ├── rerank.py
│       │   │   ├── generate.py
│       │   │   └── summarize.py
│       │   │
│       │   ├── edges/
│       │   │   └── routing.py
│       │   │
│       │   └── state.py
│       │
│       ├── services/
│       │   ├── layout_analysis/
│       │   │   ├── parser.py
│       │   │   ├── ocr.py
│       │   │   └── models.py
│       │   │
│       │   ├── chunking/
│       │   │   ├── semantic_chunk.py
│       │   │   ├── recursive_chunk.py
│       │   │   └── splitter.py
│       │   │
│       │   ├── embedding/
│       │   │   ├── embedder.py
│       │   │   ├── bge.py
│       │   │   └── e5.py
│       │   │
│       │   ├── vectordb/
│       │   │   ├── qdrant_client.py
│       │   │   ├── schema.py
│       │   │   └── retrieval.py
│       │   │
│       │   └── llm/
│       │       ├── openai_client.py
│       │       ├── prompts.py
│       │       └── generation.py
│       │
│       ├── pipelines/
│       │   ├── ingestion_pipeline.py
│       │   ├── indexing_pipeline.py
│       │   └── query_pipeline.py
│       │
│       ├── configs/
│       │   ├── settings.py
│       │   └── models.yaml
│       │
│       ├── schemas/
│       │   ├── document.py
│       │   ├── chunk.py
│       │   └── retrieval.py
│       │
│       ├── utils/
│       │   ├── logging.py
│       │   ├── tokenizer.py
│       │   └── metrics.py
│       │
│       └── api/
│           ├── main.py
│           └── routes/
│
├── tests/
│
└── scripts/
    ├── ingest.py
    └── evaluate.py

2. Tư duy QUAN TRỌNG nhất

Bạn phải tách:

Layer	Vai trò
graph	orchestration
services	business logic
pipelines	end-to-end flows
schemas	data contract
configs	configuration
api	serving

3. LangGraph chỉ nên làm orchestration

Đây là mistake phổ biến.

Nhiều người viết:

python

node():
    parse pdf
    chunk
    embed
    store qdrant
    retrieve

=> sai kiến trúc.

LangGraph node nên:

python

def retrieve_node(state):
    docs = retrieval_service.search(...)
    return {...}

Tức là:

node = orchestration
service = implementation

4. Graph folder

Đây là layer workflow.

Ví dụ:

graph/

chứa:

`state.py`

Shared state:

python

class RAGState(TypedDict):
    query: str
    retrieved_docs: list
    reranked_docs: list
    answer: str

`builder.py`

python

builder = StateGraph(RAGState)

builder.add_node(...)
builder.add_edge(...)

`nodes/`

Mỗi file:

1 logical node

Ví dụ:

text

retrieve.py
generate.py
rerank.py

5. `services/` mới là trái tim hệ thống

Đây là nơi chứa actual implementation.

A. `layout_analysis/`

Ví dụ:

OCR
PDF parsing
table extraction
layout detection

Bạn từng làm CV nên chắc quen kiểu:

text

PDF
 → detect block
 → title
 → paragraph
 → table

B. `chunking/`

Tách riêng chunking rất quan trọng.

Vì production thường có:

semantic chunk
recursive chunk
markdown chunk
layout-aware chunk

C. `embedding/`

Abstract embedding provider.

Ví dụ:

python

class Embedder:
    embed(texts)

Sau này swap:

BGE
E5
OpenAI
VoyageAI

rất dễ.

D. `vectordb/`

Tách Qdrant riêng.

Không được để Qdrant code khắp project.

Ví dụ:

python

class QdrantRepository:
    upsert()
    search()

Đây là repository pattern.

E. `llm/`

LLM wrapper layer.

Ví dụ:

prompt
generation
structured output
retry
streaming

6. `pipelines/`

Đây là abstraction cao hơn service.

Ví dụ:

ingestion_pipeline.py

text

pdf
 → layout analysis
 → chunk
 → embed
 → qdrant

query_pipeline.py

text

query
 → retrieve
 → rerank
 → generate

7. Tại sao phải tách `pipeline` và `graph`

Vì:

Pipeline	Graph
reusable	orchestration
deterministic	agentic
callable directly	workflow runtime

8. Qdrant nên nằm ở đâu?

NÊN:

services/vectordb/

KHÔNG nên:

qdrant/

vì sau này:

Milvus
Weaviate
Elasticsearch

có thể swap.

Tên folder nên abstract:

vectordb
retrieval

9. Kiến trúc ingestion flow thực tế

text

PDF
 ↓
layout analysis
 ↓
document structure
 ↓
chunking
 ↓
embedding
 ↓
qdrant upsert

10. Query flow thực tế

text

User Query
 ↓
query rewrite
 ↓
retrieve
 ↓
rerank
 ↓
context compression
 ↓
LLM generation
 ↓
citation formatting

11. Nếu dùng LangGraph

Graph nên chỉ orchestration query-time.

KHÔNG nên orchestration ingestion-time trừ khi:

ingestion async lớn
distributed workflow
retry phức tạp

12. Ví dụ LangGraph cho query

text

START
  ↓
rewrite_query
  ↓
retrieve_docs
  ↓
rerank_docs
  ↓
generate_answer
  ↓
END

13. Nếu muốn scale production lớn

Bạn sẽ cần thêm:

text

infra/
deployment/
observability/
evaluation/

Ví dụ:

tracing
LangSmith
Prometheus
benchmark
offline eval

14. Với background của bạn

Tôi nghĩ bạn nên follow architecture này:

text

services/
    layout_analysis/
    chunking/
    embedding/
    retrieval/
    llm/

vì bạn đang thiên:

computer vision
multimodal
document AI

nên layout-aware RAG sẽ rất hợp.

15. Một điều QUAN TRỌNG

Rất nhiều người build LangGraph sai kiểu:

LangGraph = whole backend

Thực ra đúng hơn là:

LangGraph = orchestration runtime

Nó không nên chứa:

embedding logic
qdrant logic
OCR logic
business logic

Mà chỉ:

coordinate
route
retry
manage state
parallelize tasks

Đây là mindset production-grade AI system.

trong module src/graph, tôi thấy bạn chia ra builder.py, nodes/, edges/ state.py. thì tôi hiểu state là để chứa các state trao đổi giữa các node (hoặc các agent), nhưng tại sao lại có cải file edges. tôi thường thấy người ta chỉ định nghĩa các hàm node, rồi add node (tức là add tên hàm đó) vào graph, rồi gắn edge giữa các node, tại sao bạn lại cần cả 1 file edge riêng?

Bạn đang chạm đúng vào một điểm kiến trúc rất hay của LangGraph.

Thực tế:

phần lớn project LangGraph KHÔNG có folder edges/.

Và đúng như bạn nói, người ta thường viết:

builder.add_edge("retrieve", "generate")

hoặc:

builder.add_conditional_edges(...)

ngay trong builder.py.

Điều này hoàn toàn bình thường.

1. Vậy tại sao tôi vẫn tách `edges/`?

Vì tôi đang nghĩ theo hướng:

production orchestration logic

chứ không phải:

demo workflow
linear agent.

2. Edge trong LangGraph thực ra không chỉ là “đường nối”

Đây là insight QUAN TRỌNG nhất.

Trong workflow đơn giản:

A → B → C

edge chỉ là:

static transition.

Nhưng trong production agent:

edge thường chứa:

text

routing logic
branching logic
retry policy
conditional flow
dynamic dispatch
tool selection
multi-agent coordination

Lúc này edge bắt đầu trở thành:

orchestration policy.

3. Ví dụ đơn giản

Static edge

builder.add_edge("retrieve", "generate")

Không cần file riêng.

Conditional edge

Ví dụ:

python

if confidence < threshold:
    return "web_search"

if no_docs:
    return "rewrite_query"

return "generate"

lúc này:

routing logic bắt đầu phức tạp.

4. Một production routing function thường như này

Ví dụ:

python

def retrieval_router(state):
    if not state["docs"]:
        return "rewrite_query"

    if state["confidence"] < 0.7:
        return "web_search"

    if state["requires_multihop"]:
        return "decompose_query"

    return "generate"

Lúc này:

edge không còn “simple edge” nữa,
nó là policy engine rồi.

5. Tại sao tôi thích tách `edges/`

Vì routing logic thường:

grow rất nhanh,
khó maintain,
dễ spaghetti hơn node logic.

6. Node và Edge có role khác nhau

Thành phần	Vai trò
node	làm việc
edge	quyết định đi đâu tiếp
state	shared memory

Ví dụ:

Node

retrieve_docs()

→ thực hiện retrieval.

Edge

should_retry_retrieval()

→ quyết định workflow.

7. Trong AI Agent system hiện đại

Routing là phần KHÓ nhất.

Không phải prompt.

Ví dụ:

query decomposition
fallback model
retry
hallucination detection
tool selection

đều là edge logic.

8. Khi nào KHÔNG cần `edges/`

Nếu workflow:

text

START
 → retrieve
 → generate
 → END

thì:

KHÔNG cần.

Để trong builder.py là đẹp nhất.

9. Khi nào NÊN có `edges/`

Khi có:

A. Conditional routing

text

if confidence low
if docs empty
if timeout

B. Multi-agent orchestration

text

planner
 → researcher
 → coder
 → verifier

C. Dynamic dispatch

Ví dụ:

text

legal question → legal agent
finance question → finance agent

D. Retry policy

text

retry retrieval
retry tool
fallback model

10. Open Deep Research có cần `edges/` không?

Thực ra:

hiện tại chưa cần nhiều,
vì workflow của họ khá linear.

Nên họ để:

routing logic inline luôn.

Điều đó hợp lý.

11. Nhưng nếu bạn build RAG thật

Bạn sẽ sớm gặp:

text

empty retrieval
low score
hybrid search fallback
web fallback
multimodal branch
OCR branch

Lúc này routing complexity sẽ tăng mạnh.

12. Ví dụ cực thực tế với hệ của bạn

Bạn có:

text

PDF
image
table
text

Bạn có thể có edge logic kiểu:

python

def ingestion_router(state):

    if state["doc_type"] == "pdf":
        return "layout_analysis"

    if state["doc_type"] == "image":
        return "ocr"

    if state["contains_table"]:
        return "table_parser"

    return "chunking"

Đây là orchestration logic.

13. Đây là lý do nhiều người gọi LangGraph là:

AI workflow state machine

vì:

node = state transition handler
edge = transition rule

14. Kiến trúc tôi khuyên cho bạn

Nếu project nhỏ

text

graph/
    builder.py
    nodes.py
    state.py

là đủ.

Nếu project vừa/lớn

text

graph/
    builder.py
    nodes/
    edges/
    state.py

sẽ dễ maintain hơn.

15. Insight QUAN TRỌNG nhất

Bạn không cần nghĩ:

edge = line nối

Mà nên nghĩ:

edge = workflow decision logic

Đó mới là mindset đúng khi build complex LangGraph systems.

à file edge này thực chất là chứa các hàm để conditional edge đúng không? chứ các hàm truyền thẳng thì không cần ghi vào đây?

Đúng rồi. Bạn hiểu chính xác rồi.

Trong đa số trường hợp:

edges/

thực chất là nơi chứa:

routing functions cho add_conditional_edges().

1. Static edge KHÔNG cần file riêng

Ví dụ:

builder.add_edge("retrieve", "generate")

Đây chỉ là:

transition cố định,
không có logic.

Thường viết trực tiếp trong builder.py.

2. Cái cần tách ra là:

python

builder.add_conditional_edges(
    "retrieve",
    retrieval_router
)

vì:

retrieval_router() chứa business workflow logic.

3. Tư duy đúng là:

Loại edge	Có cần file riêng?
static edge	thường không
conditional edge	thường có
dynamic routing	nên có
multi-agent dispatch	nên có

4. Ví dụ thực tế

Static edge

python

builder.add_edge("chunk", "embedding")
builder.add_edge("embedding", "store_qdrant")

Không cần:

chunk_to_embedding_edge.py

vì vô nghĩa.

Conditional edge

python

builder.add_conditional_edges(
    "retrieve",
    retrieval_router
)

THÌ nên tách.

5. Vì conditional edge thực ra là policy logic

Ví dụ:

python

if score low:
    retry

if image detected:
    multimodal branch

if table:
    table parser

Đây không còn là:

graph structure thuần nữa.

Nó là:

workflow intelligence.

6. Một insight QUAN TRỌNG

Trong LangGraph:

text

node = execution
edge = control flow

Conditional edge chính là:

control-flow engine.

7. Thực tế nhiều project không có folder `edges/`

Họ viết luôn:

python

def route(state):
    ...

builder.add_conditional_edges(
    "retrieve",
    route
)

ngay trong builder.py.

Điều này hoàn toàn OK nếu:

project nhỏ,
routing ít.

8. Tôi thường chỉ tách `edges/` khi có:

A. nhiều routing function

Ví dụ:

text

retrieval_router
agent_router
tool_router
retry_router
fallback_router

B. routing logic dài

Ví dụ:

python

if ...
elif ...
elif ...
elif ...

C. cần unit test routing riêng

D. multi-agent orchestration

Ví dụ:

supervisor chọn subagent,
planner chọn workflow.

9. Với project RAG của bạn

Tôi nghĩ ban đầu bạn có thể:

text

graph/
    builder.py
    nodes/
    state.py

là đủ.

10. Sau này khi complexity tăng

Ví dụ:

OCR branch
image branch
table branch
fallback retrieval
web search fallback
hallucination retry

thì mới thêm:

edges/

11. Một pattern production rất phổ biến

builder.py:

python

builder.add_conditional_edges(
    "retrieve",
    retrieval_router
)

edges/retrieval_router.py

python

def retrieval_router(state):

    if state["score"] < 0.5:
        return "rewrite"

    return "generate"

Đây là clean nhất.

12. Điều QUAN TRỌNG nhất

Đừng over-architect sớm.

LangGraph repo thường intentionally:

flat,
simple,
procedural.

Và điều đó đúng.

Bạn chỉ nên tách:

khi orchestration logic thật sự bắt đầu phức tạp.

services/ └── layout_analysis/ │ ├── ocr/ │ ├── base.py │ ├── paddle_ocr.py │ ├── vietocr.py │ ├── predictor.py │ ├── preprocess.py │ ├── postprocess.py │ └── schemas.py │ ├── parser/ │ ├── pdf_parser.py │ └── image_parser.py │ └── layout/ ├── layout_detector.py └── layout_models.py

giả dụ service/ocr/paddleocr.py và service/layout-analysis/paddlelayout.py của tôi đều là model convert sang tensorrt, đều chung format load engine, allocate bufffer, nhưng nó lại thuộc 2 service khác nhau, thì tôi vẫn nên để mỗi service 1 base.py riêng, hay nên có 1 base chung? vì bạn biết mà, model tensorrt infrene thì na ná giống nhau, chứ khác với model pytorch thông thường

Trong case này, bạn đang gặp một tình huống rất điển hình của production AI/CV systems:

domain khác nhau:
- OCR
- Layout Detection

NHƯNG:

inference runtime lại giống nhau:
- TensorRT engine
- CUDA buffer
- stream
- enqueueV3
- bindings
- memory management

Và đây chính là lúc:

shared infrastructure abstraction

bắt đầu có ý nghĩa.

1. Câu trả lời ngắn gọn

Tôi khuyên:

✅ VẪN giữ:

ocr/base.py
layout/base.py

cho domain contract.

NHƯNG:

✅ thêm một:

shared TensorRT infrastructure base

ở tầng thấp hơn.

2. Đây là điều QUAN TRỌNG nhất

Bạn đang có HAI loại abstraction khác nhau:

Abstraction	Vai trò
domain abstraction	OCR/Layout
runtime abstraction	TensorRT

3. Domain abstraction

Ví dụ:

OCR

python

class BaseOCR:

    def predict(
        self,
        input: OCRInput
    ) -> OCROutput:
        pass

Layout

python

class BaseLayoutDetector:

    def predict(
        self,
        input: LayoutInput
    ) -> LayoutOutput:
        pass

Đây là:

business/domain contract.

4. Runtime abstraction

Đây là thứ shared.

Ví dụ:

python

TensorRT engine loading
buffer allocation
cuda stream
bindings
context.execute_async_v3()

5. Kiến trúc clean nhất cho bạn

Tôi cực kỳ khuyên:

text

services/
│
├── inference/
│   └── tensorrt/
│       ├── base.py
│       ├── engine.py
│       ├── buffers.py
│       └── utils.py
│
├── layout_analysis/
│   ├── ocr/
│   │   ├── base.py
│   │   ├── paddle_ocr_trt.py
│   │   └── schemas.py
│   │
│   └── layout/
│       ├── base.py
│       ├── paddle_layout_trt.py
│       └── schemas.py

6. Shared TensorRT base

Ví dụ:

python

# services/inference/tensorrt/base.py

class TensorRTModel:

    def __init__(self, engine_path):

        self.engine = self.load_engine(engine_path)

        self.context = self.engine.create_execution_context()

        self.allocate_buffers()

    def load_engine(self, path):
        ...

    def allocate_buffers(self):
        ...

    def infer(self, inputs):
        ...

7. OCR kế thừa runtime base

Ví dụ:

python

# paddle_ocr_trt.py

from services.inference.tensorrt.base import TensorRTModel
from .base import BaseOCR


class PaddleOCRTensorRT(
    TensorRTModel,
    BaseOCR
):

    def predict(self, input):

        tensor = self.preprocess(input)

        outputs = self.infer(tensor)

        return self.postprocess(outputs)

8. Layout detector cũng reuse

python

class PaddleLayoutTensorRT(
    TensorRTModel,
    BaseLayoutDetector
):

9. Đây là production-grade architecture thật sự

Vì bạn đang tách:

tầng infrastructure

text

TensorRT runtime
CUDA
memory

khỏi tầng business/domain

text

OCR
layout detection

10. Đây là mindset rất QUAN TRỌNG

Đừng nghĩ:

OCR vs Layout

mà hãy nghĩ:

text

Domain Layer
↓
Inference Runtime Layer
↓
CUDA/TensorRT Layer

11. TensorRT project production thường rất giống nhau ở tầng thấp

Ví dụ:

YOLO TRT
OCR TRT
SAM TRT
CLIP TRT

đều có:

deserialize engine
allocate buffer
memcpy
stream synchronize

Nên shared layer rất hợp lý.

12. Nhưng KHÔNG nên làm thế này

Sai:

class BaseAIModel:

rồi:

OCR kế thừa
Embedding kế thừa
Retrieval kế thừa

=> abstraction quá generic.

13. Shared base chỉ nên dùng khi có:

✅ runtime behavior giống nhau thật.

TensorRT đúng là trường hợp như vậy.

14. Tôi còn khuyên thêm 1 tầng nữa cho bạn

Ví dụ:

text

services/
└── inference/
    ├── tensorrt/
    ├── pytorch/
    └── onnxruntime/

Sau này:

TRT
ONNXRuntime
TorchScript

có thể coexist.

15. Một kiến trúc cực đẹp cho CV systems

text

domain
    ↓
runtime
    ↓
hardware

Ví dụ:

text

OCR
  ↓
TensorRT
  ↓
CUDA

16. Điều QUAN TRỌNG nhất

Bạn nên tách:

Layer	Ownership
OCRInput/OCROutput	domain
TensorRT engine	infrastructure
CUDA buffer	infrastructure
OCR postprocess	domain
TRT inference	runtime

17. Với background Jetson/TensorRT của bạn

Tôi nghĩ architecture đúng nhất sẽ là:

text

services/
    inference/
        tensorrt/

    layout_analysis/
        ocr/

    embedding/

    retrieval/

vì TensorRT runtime chắc chắn sẽ được reuse rất nhiều trong tương lai.

ô hóa ra có kiểu kế thừa từ 2 base thế này à

Đúng rồi 😄 Đây gọi là:

multiple inheritance (đa kế thừa)

trong Python.

Và trong các AI/CV production systems, pattern này dùng khá nhiều khi bạn muốn combine:

domain behavior
infrastructure/runtime behavior

1. Trong ví dụ của bạn

python

class PaddleOCRTensorRT(
    TensorRTModel,
    BaseOCR
):

thực ra class này đang combine:

Parent class	Vai trò
TensorRTModel	runtime/inference engine
BaseOCR	OCR contract/domain interface

2. Tư duy rất QUAN TRỌNG

Bạn không còn nghĩ:

class = object

mà nên nghĩ:

class = composition of capabilities

3. `TensorRTModel`

Cho capability:

text

load engine
allocate buffers
infer()
cuda stream

4. `BaseOCR`

Cho capability:

predict(input: OCRInput) -> OCROutput

5. Class cuối cùng combine cả hai

python

class PaddleOCRTensorRT(
    TensorRTModel,
    BaseOCR
):

=> cực hợp lý.

6. Đây là pattern rất phổ biến trong AI systems

Ví dụ:

python

class YOLOTensorRT(
    TensorRTModel,
    BaseDetector
)

hoặc:

python

class CLIPONNX(
    ONNXRuntimeModel,
    BaseEmbedder
)

7. Multiple inheritance KHÔNG xấu

Nhiều người backend truyền thống sợ multiple inheritance.

Vì trong OOP classic:

dễ diamond problem,
hard debugging.

NHƯNG:

Trong AI engineering:

mix capability rất common,
đặc biệt inference/runtime layer.

8. Điều QUAN TRỌNG là:

Mỗi base phải:

có responsibility rõ ràng,
ít overlap.

9. Trong ví dụ của bạn

Đây là GOOD multiple inheritance.

Vì:

TensorRTModel

phụ trách:

text

runtime
hardware
inference engine

BaseOCR

phụ trách:

business/domain interface

Không overlap.

=> clean.

10. Đây là thứ rất giống mixin pattern

Bạn có thể nghĩ:

TensorRTModel = inference mixin

11. Production AI repo dùng pattern này rất nhiều

Đặc biệt:

TensorRT
ONNXRuntime
Accelerate
distributed inference
async serving

12. Ví dụ thực tế rất đẹp

Shared runtime

python

class TensorRTModel:

    def infer(self, tensor):
        ...

Domain contract

python

class BaseOCR:

    def predict(self, input):
        ...

Final implementation

python

class PaddleOCRTRT(
    TensorRTModel,
    BaseOCR
):

13. Một insight cực kỳ production-grade

Bạn đang tách:

WHAT the model does

khỏi:

HOW the model runs

Ví dụ:

Layer	Meaning
BaseOCR	WHAT
TensorRTModel	HOW
PaddleOCRTRT	concrete implementation

14. Đây là abstraction rất mạnh

Vì sau này bạn có thể:

cùng OCR

nhưng:

text

PyTorch
TensorRT
ONNXRuntime

Ví dụ:

python

class PaddleOCRTorch(
    TorchModel,
    BaseOCR
)

15. Đây chính là "orthogonal abstraction"

Tức là:

runtime
domain

là hai chiều độc lập.

16. Một lưu ý QUAN TRỌNG

Đừng abuse multiple inheritance.

GOOD

runtime + domain

BAD

text

BaseAI
BaseVision
BaseInference
BasePredictor
BaseLogger
BaseManager

=> spaghetti inheritance.

17. Rule rất hay

Nếu:

hai base giải quyết hai concern độc lập,
không share state lộn xộn,

THÌ multiple inheritance rất ổn.

18. Trong AI/CV systems

Tôi thấy pattern này đặc biệt hợp với:

Shared capability	Domain
TensorRT	OCR
ONNXRuntime	Detection
batching	Embedding
async inference	VLM
streaming	LLM

19. Với background TensorRT/Jetson của bạn

Tôi nghĩ bạn sẽ rất hợp với architecture kiểu:

text

domain abstraction
+
runtime abstraction

vì TensorRT runtime thực sự reusable cực mạnh giữa:

OCR
detection
segmentation
embedding
multimodal encoder.

Tức là: services/

trả lời:

HOW to do something workflows/

trả lời:

WHEN and IN WHAT ORDER

Với project của bạn

Tôi nghĩ structure hiện tại rất hợp lý:

src/ │ ├── services/ │ ├── graph/ │ ├── workflows/ │ └── bootstrap/ 8. Ý nghĩa từng layer services/ business/infrastructure capabilities

Ví dụ:

qdrant search, embedding, parser, llm generation. workflows/ business flows

Ví dụ:

rag, ingestion, log analysis. graph/ LangGraph orchestration infra bootstrap/ application lifecycle

Tức là:

Workflow nên đọc như:

business story

Ví dụ:

embed query ↓ retrieve chunks ↓ expand chunks ↓ build prompt ↓ generate answer

KHÔNG nên đọc như:

build MatchAny filter ↓ build SearchParams ↓ query_points

Điều tôi chỉ muốn tweak nhẹ

Tôi sẽ recommend:

workflows/

nên chứa:

graph-level orchestration.

Ví dụ:

workflows/ │ ├── rag/ │ ├── graph.py │ ├── nodes.py │ ├── state.py │ └── prompts.py

THAY VÌ:

generic graph/ folder riêng. 17. Vì sao?

Hiện tại bạn có:

graph/

Nhưng graph nào?

rag graph? ingestion graph? log graph?

=> eventually:

graph/

sẽ become ambiguous.

Tôi recommend future structure BETTER workflows/ │ ├── rag/ │ ├── graph/ │ │ ├── builder.py │ │ ├── state.py │ │ ├── nodes/ │ │ └── edges/ │ │ │ ├── prompts/ │ └── service.py │ ├── ingestion/ │ ├── graph/ │ └── service.py │ └── log_analysis/ ├── graph/ └── service.py

src/ ├── bootstrap/ ├── configs/ ├── services/ # Các service dùng chung toàn hệ thống (DB, LLM Client, VectorDB Client) ├── utils/ └── workflows/ # Mỗi workflow là một thực thể độc lập, đóng gói hoàn chỉnh ├── rag/ │ ├── graph/ │ │ ├── builder.py # Nơi compile graph, add_node, add_edge │ │ ├── state.py # Định nghĩa State (TypedDict/Pydantic) của riêng RAG │ │ ├── nodes/ # Thư mục chứa logic các bước xử lý │ │ └── edges/ # Logic điều hướng (Conditional edges) │ ├── prompts/ # System prompts, few-shot examples cho RAG │ └── service.py # Giao diện gọi ngoài: def run_rag_flow(query): ... │ └── ingestion/ ├── graph/ └── service.py

Nhưng RAG của tôi có nhiều kiểu RAG, RAG lên DB question-answer sẽ khác, RAG lên DB production info sẽ khác, đây là code hiện tại của tôi. Nếu tôi thêm 1 thư mục graph, rồi có builder rồi state vào đây, có làm độn lên không?

Không 😄 THỰC RA lúc này bạn đang bắt đầu chạm tới:

multi-RAG architecture

Và đây là lúc:

workflow,
graph,
retrieval strategy,

bắt đầu cần được tách đúng.

1. Điều QUAN TRỌNG nhất

Bạn đang có:

RAG != retrieval

RAG workflow có thể:

giống nhau về orchestration,
nhưng khác retrieval strategy.

Ví dụ bạn nói:

Type	Khác nhau
QA RAG	search QA db
Production-info RAG	search docs
Log RAG	search logs
Multi-doc RAG	doc_id filter
Agentic RAG	iterative

=> cái khác thực ra là:

retrieval policy

KHÔNG nhất thiết:

khác toàn workflow.

2. Vì vậy hiện tại

Tôi KHÔNG recommend:

text

workflows/rag/
    graph/
        builder.py
        state.py

vì với scale hiện tại:

hơi overkill,
đúng như bạn nói:
- dễ “độn”.

3. Tôi nghĩ bạn đang ở sweet spot này:

KEEP SIMPLE

text

workflows/
└── rag/
    ├── retrieval.py
    ├── filtering.py
    ├── expansion.py
    ├── qa_curation.py

=> rất hợp lý.

4. Thứ bạn THỰC SỰ cần thêm là:

rag graph variants

KHÔNG phải:

giant graph folder.

5. Tôi recommend structure này

CLEAN VERSION

text

workflows/
└── rag/
    │
    ├── retrieval.py
    ├── filtering.py
    ├── expansion.py
    ├── qa_curation.py
    │
    ├── graphs/
    │   ├── simple_rag.py
    │   ├── qa_rag.py
    │   ├── production_rag.py
    │   └── agentic_rag.py
    │
    ├── state.py
    └── prompts.py

6. Đây là VERY scalable

Vì:

retrieval.py

chứa:

retrieval primitives

Ví dụ:

python

search_documents()

search_qa()

expand_chunks()

filter_by_doc()

7. Còn:

graphs/simple_rag.py

orchestrate:

text

embed
↓
retrieve
↓
generate

graphs/qa_rag.py

orchestrate:

text

classify
↓
retrieve QA db
↓
generate

graphs/agentic_rag.py

orchestrate:

text

rewrite
↓
retrieve
↓
judge
↓
retry retrieve
↓
generate

8. Đây là separation đúng

Layer	Responsibility
retrieval.py	HOW retrieve
graph/*.py	WHEN retrieve

9. Điều bạn KHÔNG nên làm

BAD

text

rag_qa/
rag_docs/
rag_logs/
rag_agentic/

=> duplicated retrieval code.

10. Điều đẹp nhất của architecture hiện tại

Là bạn đã có:

atomic retrieval primitives

Ví dụ:

filtering,
expansion,
qa_curation.

=> graph chỉ compose chúng 😄

11. Vậy state.py thì sao?

Tôi nghĩ hiện tại:

ONE SHARED RAG STATE

là đủ.

Ví dụ:

python

class RagState(TypedDict):

    user_query: str

    query_vector: list

    retrieved_chunks: list

    reranked_chunks: list

    answer: str

    retrieval_mode: str

12. Vì semantic vẫn là:

RAG semantic state

KHÔNG phải:

ingestion state,
log analysis state.

13. Tức là:

SAME DOMAIN

RAG

=> cùng state vẫn OK.

14. Chỉ khi nào:

completely different semantics

mới nên:

subgraph riêng,
state riêng.

15. Ví dụ:

ingestion

IngestionState

log analysis

LogAnalysisState

=> hoàn toàn khác.

16. Nhưng:

Workflow	Same RAG semantic?
QA RAG	✅
production docs RAG	✅
multi-doc RAG	✅
hybrid retrieval RAG	✅

=> cùng:

RagState,
retrieval primitives.

17. Tôi nghĩ architecture đẹp nhất cho bạn hiện tại là:

text

workflows/
└── rag/
    │
    ├── retrieval.py
    ├── filtering.py
    ├── expansion.py
    ├── qa_curation.py
    │
    ├── graphs/
    │   ├── simple_rag.py
    │   ├── qa_rag.py
    │   ├── hybrid_rag.py
    │   └── agentic_rag.py
    │
    ├── state.py
    └── prompts.py

18. Đây là scalable nhưng chưa over-engineering 😄

Bạn đang dùng graph đúng chỗ 😄 Workflow Graph? conversational rag ✅ log analysis ✅ document ingestion ❌ qa insertion ❌ delete document ❌

Tôi nghĩ đây là chỗ cực kỳ quan trọng để phân biệt:

text

workflow orchestration
vs
backend business pipeline

Câu trả lời ngắn gọn 😄

Query / Retrieval

→ rất hợp với LangGraph.

Insert / Ingestion

→ chưa chắc cần graph 😄

1. Vì sao retrieval rất hợp graph 😄

Vì retrieval có:

branching,
routing,
retry,
conditional flow,
memory shortcut,
prompt orchestration,
multi-step reasoning.

Nó là:

dynamic execution flow

2. Nhưng ingestion thường 😄

lại là:

deterministic pipeline

Ví dụ:

text

upload file
→ parse
→ chunk
→ embed
→ insert

Đây thực ra giống:

ETL pipeline

KHÔNG phải:

reasoning graph.

3. Tôi nghĩ hiện tại 😄

Bạn KHÔNG nên cố graph everything.

Đây là lỗi rất nhiều người dùng LangGraph mắc phải 😄

4. Tôi recommend 😄

KEEP SIMPLE

text

src/workflows/
├── rag/
├── log_analysis/
└── ingestion/

nhưng:

conversational_rag

→ graph.

log_analysis

→ graph (vì có map-reduce reasoning).

ingestion

→ normal service pipeline.

5. Ví dụ ingestion của bạn 😄

document ingestion

python

parse
→ chunk
→ embed
→ upsert

=> linear deterministic.

qa ingestion

python

question
→ embed
→ insert

=> càng không cần graph 😄

6. Khi nào ingestion nên dùng graph 😄

Chỉ khi có:

conditional parsing,
OCR routing,
async retries,
fallback embedding models,
human approval,
dynamic validation,
distributed ingestion.

Ví dụ:

text

if pdf scanned
→ OCR

if table-heavy
→ table parser

if image-heavy
→ vision parser

THÌ graph mới đáng 😄

7. Nhưng hiện tại 😄

Backend sẽ call:

text

POST /insert-document
POST /insert-qa

=> simple service là đẹp nhất.

8. Tôi recommend architecture này 😄

GOOD

text

src/workflows/
├── rag/
├── log_analysis/
└── ingestion/
    ├── document_ingestion.py
    ├── qa_ingestion.py
    └── service.py

service.py

python

insert_document()

insert_question_answer()

delete_document()

delete_temporary_document()

9. Và backend layer 😄

sẽ gọi:

text

FastAPI
→ ingestion service

KHÔNG cần:

graph invoke.

10. Một insight QUAN TRỌNG 😄

LangGraph mạnh nhất khi:

execution path is uncertain

KHÔNG phải:

mọi thứ multi-step.

11. Bạn đang dùng graph đúng chỗ 😄

Workflow	Graph?
conversational rag	✅
log analysis	✅
document ingestion	❌
qa insertion	❌
delete document	❌

Đây là architecture rất hợp lý 😄

12. Một recommendation nữa 😄

Tôi nghĩ ingestion nên tách:

workflow

ra khỏi:

api layer

Ví dụ:

text

src/api/
src/workflows/
src/services/

để sau này:

Celery,
Kafka,
async queue,

rất dễ scale 😄

13. Điều QUAN TRỌNG 😄

Đừng biến LangGraph thành:

general backend framework

Nó không optimize cho:

CRUD,
deterministic ETL,
synchronous APIs.

Nó optimize cho:

stateful AI orchestration

Và hiện tại bạn đang dùng đúng hướng 😄

Bạn có cần docker cho integration test không 😄

Có. Rất nên.

Ví dụ:

docker-compose.test.yml services:

qdrant: image: qdrant/qdrant ports: - "6333:6333"

Rồi pytest chạy:

pytest tests/integration 9. KHÔNG nên 😄

Không nên integration test bằng:

production qdrant

vì:

flaky polluted data race conditions slow ==>

đoạn nội dung này nghĩa là thế nào? Tức là tôi nên tạo 1 qdrant mới để test intergraion ư?

Đúng rồi 😄 Ý là:

Integration test nên có môi trường riêng

đặc biệt với:

Qdrant
Redis
Postgres
Kafka
MinIO

Vì sao?

Integration test là test:

service thật + networking thật + database thật

Ví dụ:

Python app thật
Qdrant thật
insert vector thật
retrieval thật

Nhưng KHÔNG nên test trên production Qdrant

Ví dụ:

localhost:6333

đang chứa:

dữ liệu dev thật
collection thật
documents thật

Vì sẽ xảy ra rất nhiều vấn đề

1. Polluted data

Test insert:

test_doc_001

xong không cleanup.

Sau vài tuần:

production collection đầy rác test

2. Race conditions

Ví dụ:

app dev đang insert thật
test cũng insert

cùng collection:

documents

=> nondeterministic.

3. Flaky test

Hôm nay pass:

retrieved_count == 5

mai fail vì:

dữ liệu production thay đổi.

4. Slow

Production DB:

nhiều data
nhiều index
nhiều segment

=> test chậm.

5. Test có thể phá production

Ví dụ test:

delete_collection()

💀

Vì vậy best practice là:

tạo environment riêng cho test

Với Docker thì cực dễ

Ví dụ:

yaml

# docker-compose.test.yml

services:

  qdrant-test:

    image: qdrant/qdrant

    ports:
      - "6339:6333"

Test connect tới:

localhost:6339

KHÔNG phải:

production qdrant
dev qdrant.

Flow chuẩn

Khi test bắt đầu

docker compose -f docker-compose.test.yml up -d

Pytest chạy

pytest tests/integration

Sau test

docker compose -f docker-compose.test.yml down

Đây gọi là:

ephemeral test environment

Production engineering rất thích cách này

Vì:

reproducible
isolated
deterministic
CI-friendly

Với project RAG của bạn

Mình cực kỳ khuyên:

Unit test

Mock:

qdrant
embedding
llm

Integration test

Dùng:

Qdrant Docker thật
collection thật
insert/query thật

NHƯNG:

database riêng.

Ví dụ integration test rất đẹp

python

def test_qdrant_retrieval():

    client.create_collection(...)

    client.upsert(...)

    results = retriever.search(...)

    assert len(results) > 0

Thường người ta dùng collection test riêng

Ví dụ:

test_documents

hoặc:

test_<uuid>

CI/CD thực tế

GitLab pipeline:

yaml

services:
  - qdrant/qdrant

rồi:

spin up container
chạy pytest
destroy container

mọi thứ isolated hoàn toàn.

Một insight rất quan trọng

AI/RAG integration test KHÔNG chỉ là:

API có chạy không

mà còn:

retrieval consistency
metadata filtering
chunk expansion
vector dimension compatibility
ANN behavior

Tóm tắt

Đúng 😄

Bạn nên có:

Qdrant riêng cho integration test

thường bằng:

Docker container riêng
port riêng
collection riêng
dữ liệu fixture riêng

Đây là best practice production/backend engineering thật sự.

CI/CD 😄

Đây là phần cực quan trọng.

Flow thực tế 😄 AI Team 😄

push code lên:

GitLab GitLab CI 😄

trigger:

.gitlab-ci.yml Pipeline thường 😄 stages:

lint
unit-test
workflow-test
integration-test
build
deploy Ví dụ 😄 unit-test: stage: unit-test

script: - pytest tests/unit Integration 😄 integration-test: stage: integration-test

services: - qdrant/qdrant

script: - pytest -m integration Docker build 😄 docker-build: stage: build

script: - docker build -t rag-service . ==>

ủa chưa build docker thì làm sao chạy test unit và integration được, phải có môi trường env mới chạy được chứ.

Đây chính là chỗ nhiều người mới làm DevOps/CI hiểu nhầm 😄 Bạn đang nghĩ:

Muốn chạy test thì phải build Docker app trước

Nhưng thực tế CI có nhiều strategy khác nhau.

Flow bạn đang thấy là kiểu:

text

test source code trước
→ build artifact sau

Đây là workflow rất phổ biến.

Hãy hiểu CI runner là gì trước

GitLab CI khi chạy pipeline sẽ tạo:

1 môi trường Linux sạch tạm thời

Ví dụ:

Ubuntu container
Docker runner
Kubernetes pod

Trong đó:

clone source code của bạn
setup environment
chạy commands.

Nghĩa là test KHÔNG nhất thiết phải chạy trong app Docker

Ví dụ CI:

yaml

unit-test:

  image: python:3.11

  script:
    - pip install -r requirements.txt
    - pytest tests/unit

Flow thật bên dưới

text

GitLab Runner
    ↓
start python:3.11 container
    ↓
git clone repo
    ↓
pip install dependencies
    ↓
pytest

Đây đã là environment rồi 😄

Chỉ là:

ephemeral CI environment
không phải app Docker image của bạn.

Tại sao test trước build?

Vì:

Nếu test fail thì khỏi build image

tiết kiệm:

CI time
Docker build time
registry storage.

Flow chuẩn production thường là

text

lint
  ↓
unit test
  ↓
integration test
  ↓
build docker image
  ↓
deploy

Vì sao integration test vẫn chạy được?

Do:

yaml

services:
  - qdrant/qdrant

Ý nghĩa thật

GitLab sẽ spin up thêm:

sidecar container

cho test.

Kiến trúc thật sự

text

CI Runner Container
    |
    |--- pytest
    |
    |--- qdrant service container

Tức là

Python test chạy ở:

CI container

Qdrant chạy ở:

sidecar service container

Giống docker-compose mini

Ví dụ thực tế

yaml

integration-test:

  image: python:3.11

  services:
    - qdrant/qdrant

  script:
    - pip install -r requirements.txt
    - pytest -m integration

GitLab tự tạo network nội bộ

Test của bạn có thể connect:

http://qdrant:6333

Đây là cực kỳ phổ biến

Không cần build app Docker trước.

Vậy khi nào mới test Docker image?

Đó là:

container/system/e2e test

Ví dụ

text

build image
→ run container
→ test API

Ví dụ CI thật

Stage 1 — unit

pytest tests/unit

Stage 2 — integration

pytest -m integration

Stage 3 — build image

docker build

Stage 4 — container smoke test

yaml

docker run ...
curl localhost:8000/health

Một insight rất quan trọng

Có 2 loại environment:

1. Runtime environment

Docker image production của app.

2. CI execution environment

Temporary environment để:

test
lint
build

Chúng không bắt buộc giống hệt nhau.

Tuy nhiên production team mạnh sẽ cố sync chúng

Ví dụ:

image: my-rag-base-image

để:

CI env gần production hơn.

Với AI project của bạn

Mình khuyên:

Unit test

KHÔNG cần Docker app.

Chỉ cần:

yaml

python:3.11
pip install
pytest

Integration test

Cần:

qdrant service
maybe redis/postgres

E2E/container test

Lúc này mới:

build Docker app
run app container
test API thật.

Production-grade flow cho bạn sau này

text

lint
↓
unit tests
↓
integration tests
↓
graph workflow tests
↓
build docker image
↓
container smoke test
↓
deploy staging
↓
eval tests
↓
deploy prod

Điều cực hay ở CI hiện đại

CI không chỉ test code.

Nó test:

infra
orchestration
networking
containers
workflows
deployment contracts

luôn 😄

ừ tôi biết rồi, nhưng AI của tôi có nhiều requirement lắm, giả sử OCR thì có ultralytics (detect text), rồi paddlex[ocr], rồi torch, vậy thì tôi chỉ cần ghi hết các dependencies này ở file requirements trong repo của tôi là được đúng không? Bên CI env sẽ tự tạo env chứa các dependencies này?

Đúng rồi 😄 Đó chính là ý tưởng của CI/CD hiện đại:

repo = source of truth cho environment

Nghĩa là

Bạn commit:

requirements.txt

hoặc:

pyproject.toml
poetry.lock
environment.yml

Rồi CI runner sẽ:

text

tự tạo environment sạch
→ cài dependencies
→ chạy test

Flow thật

Ví dụ:

yaml

unit-test:

  image: python:3.11

  script:
    - pip install -r requirements.txt
    - pytest tests/unit

Bên dưới GitLab sẽ làm

text

create fresh container
    ↓
clone repo
    ↓
pip install -r requirements.txt
    ↓
pytest

Nghĩa là environment được recreate mỗi pipeline 😄

Đây là điểm cực mạnh:

reproducible

Với AI project của bạn

Đúng là dependencies sẽ rất nhiều 😄

Ví dụ:

text

torch
transformers
ultralytics
paddlex[ocr]
onnxruntime-gpu
qdrant-client
langgraph
opencv-python

Và đúng 😄

Bạn chỉ cần đảm bảo:

requirements.txt đầy đủ

Ví dụ thực tế

txt

torch==2.7.1
transformers==4.52.0
ultralytics==8.3.0
paddlex[ocr]
qdrant-client==1.14.0
langgraph
opencv-python

Nhưng AI project có vài vấn đề đặc biệt 😄

1. CI rất chậm nếu install full AI stack mỗi lần

Ví dụ:

torch
CUDA
OCR models

có thể:

vài GB
install 10-20 phút.

Production team giải quyết thế nào?

Cách 1 — cache pip

Ví dụ GitLab cache:

yaml

cache:
  paths:
    - .cache/pip

Cách 2 — base Docker image (RẤT PHỔ BIẾN)

Ví dụ build sẵn:

my-ai-base-image

đã chứa:

torch
cuda
ultralytics
OCR libs

Sau đó CI dùng:

image: my-ai-base-image

Flow sẽ nhanh hơn cực nhiều

Vì:

không phải reinstall torch mỗi lần.

2. GPU dependency rất tricky

Ví dụ:

text

torch==cu126
onnxruntime-gpu
tensorrt

CI runner thường KHÔNG có GPU

Nên production AI teams thường:

CPU-only test trong CI

Ví dụ:

text

onnxruntime
torch cpu

GPU tests riêng

Trên:

self-hosted GPU runner
nightly pipeline

3. OCR model download

Ví dụ:

PaddleOCR
HuggingFace
Ultralytics

thường auto download model.

CI có thể fail vì:

internet
timeout
nondeterminism

Production best practice

preload model

Hoặc:

cache model
artifact model
bake vào Docker image.

4. AI dependency conflict rất phổ biến 😄

Ví dụ:

torch
torchao
xformers
cuda
onnxruntime

conflict nhau.

Như bạn vừa gặp:

torchao incompatible torch version

Vì vậy AI project nên pin version

KHÔNG nên:

torch

Mà nên:

torch==2.7.1

Với project của bạn

Mình khuyên:

requirements/base.txt

text

fastapi
pydantic
qdrant-client
langgraph

requirements/ai.txt

text

torch==2.7.1
transformers
ultralytics
paddlex[ocr]

requirements/dev.txt

text

pytest
pytest-cov
ruff
mypy

CI có thể chọn install phù hợp

Unit test nhẹ

bash

pip install -r requirements/base.txt
pip install -r requirements/dev.txt

Full AI integration

pip install -r requirements/ai.txt

Đây là practice rất production-oriented

Vì:

CI nhanh hơn
dependency rõ hơn
ít conflict hơn

Một insight cực kỳ quan trọng

Trong AI backend:

environment reproducibility

khó gần ngang:

code correctness 😄

Vì:

AI stack phụ thuộc:

CUDA
GPU driver
torch
onnxruntime
model weights
native libs

rất nhiều.

Tóm lại

Đúng 😄

Bạn chỉ cần:

commit dependency files vào repo
CI sẽ tự tạo env sạch
tự install dependencies
tự chạy test

Đó chính là:

reproducible CI
infrastructure-as-code mindset.

skyeen623/RAGDemo

1. Kiến trúc folder production-grade tôi khuyên dùng

2. Tư duy QUAN TRỌNG nhất

3. LangGraph chỉ nên làm orchestration

4. Graph folder

state.py

builder.py

nodes/

5. services/ mới là trái tim hệ thống

A. layout_analysis/

B. chunking/

C. embedding/

D. vectordb/

E. llm/

6. pipelines/

ingestion_pipeline.py

query_pipeline.py

7. Tại sao phải tách pipeline và graph

8. Qdrant nên nằm ở đâu?

9. Kiến trúc ingestion flow thực tế

10. Query flow thực tế

11. Nếu dùng LangGraph

12. Ví dụ LangGraph cho query

13. Nếu muốn scale production lớn

14. Với background của bạn

15. Một điều QUAN TRỌNG

1. Vậy tại sao tôi vẫn tách edges/?

2. Edge trong LangGraph thực ra không chỉ là “đường nối”

3. Ví dụ đơn giản

Static edge

Conditional edge

4. Một production routing function thường như này

5. Tại sao tôi thích tách edges/

6. Node và Edge có role khác nhau

Node

Edge

7. Trong AI Agent system hiện đại

8. Khi nào KHÔNG cần edges/

9. Khi nào NÊN có edges/

A. Conditional routing

B. Multi-agent orchestration

C. Dynamic dispatch

D. Retry policy

10. Open Deep Research có cần edges/ không?

11. Nhưng nếu bạn build RAG thật

12. Ví dụ cực thực tế với hệ của bạn

13. Đây là lý do nhiều người gọi LangGraph là:

14. Kiến trúc tôi khuyên cho bạn

Nếu project nhỏ

Nếu project vừa/lớn

15. Insight QUAN TRỌNG nhất

à file edge này thực chất là chứa các hàm để conditional edge đúng không? chứ các hàm truyền thẳng thì không cần ghi vào đây?

1. Static edge KHÔNG cần file riêng

2. Cái cần tách ra là:

3. Tư duy đúng là:

4. Ví dụ thực tế

Static edge

Conditional edge

5. Vì conditional edge thực ra là policy logic

6. Một insight QUAN TRỌNG

7. Thực tế nhiều project không có folder edges/

8. Tôi thường chỉ tách edges/ khi có:

A. nhiều routing function

B. routing logic dài

C. cần unit test routing riêng

D. multi-agent orchestration

9. Với project RAG của bạn

10. Sau này khi complexity tăng

11. Một pattern production rất phổ biến

12. Điều QUAN TRỌNG nhất

1. Câu trả lời ngắn gọn

2. Đây là điều QUAN TRỌNG nhất

3. Domain abstraction

OCR

Layout

4. Runtime abstraction

5. Kiến trúc clean nhất cho bạn

6. Shared TensorRT base

7. OCR kế thừa runtime base

8. Layout detector cũng reuse

skyeen623/
RAGDemo

`state.py`

`builder.py`

`nodes/`

5. `services/` mới là trái tim hệ thống

A. `layout_analysis/`

B. `chunking/`

C. `embedding/`

D. `vectordb/`

E. `llm/`

6. `pipelines/`

7. Tại sao phải tách `pipeline` và `graph`

1. Vậy tại sao tôi vẫn tách `edges/`?

5. Tại sao tôi thích tách `edges/`

8. Khi nào KHÔNG cần `edges/`

9. Khi nào NÊN có `edges/`

10. Open Deep Research có cần `edges/` không?

7. Thực tế nhiều project không có folder `edges/`

8. Tôi thường chỉ tách `edges/` khi có:

3. `TensorRTModel`

4. `BaseOCR`