Introduction

Graph collections in TensorFlow were mainly a TensorFlow 1 graph-mode mechanism for organizing tensors, variables, losses, summaries, and other graph elements. Their purpose was to make large static graphs easier to manage by letting code add and retrieve related objects by category instead of manually tracking every tensor reference.

What a Graph Collection Is

In TensorFlow 1, a computational graph could contain thousands of operations and tensors. Collections gave the graph named buckets where objects could be stored and later retrieved.

Typical examples included:

• Trainable variables.
• Global variables.
• Update operations.
• Summaries.
• Loss tensors.

This made graph construction more modular because separate parts of the model could register important tensors without passing every reference through every function.

Built-In Collections

TensorFlow defined several standard collection keys, often accessed through tf.GraphKeys.

Example:

1import tensorflow.compat.v1 as tf
2
3tf.disable_eager_execution()
4
5x = tf.Variable(1.0, name="x")
6y = tf.Variable(2.0, name="y")
7loss = x + y
8
9tf.add_to_collection(tf.GraphKeys.LOSSES, loss)
10
11with tf.Session() as sess:
12    sess.run(tf.global_variables_initializer())
13    print(tf.get_collection(tf.GraphKeys.LOSSES))

The important idea is that the loss tensor was not just a local variable. It was also registered in the graph under a known collection key.

Why Collections Were Useful

Collections helped in a few recurring situations:

• Libraries could add losses or summaries without tightly coupling to the training loop.
• Model-building code could retrieve all trainable variables or update ops later.
• Save and restore workflows could identify groups of graph elements consistently.

This was especially valuable in big TensorFlow 1 codebases where graph construction happened across multiple modules.

Custom Collections

You were not limited to the built-in keys. You could create your own named collection.

1import tensorflow.compat.v1 as tf
2
3tf.disable_eager_execution()
4
5weights = tf.Variable([1.0, 2.0], name="weights")
6tf.add_to_collection("my_custom_objects", weights)
7
8print(tf.get_collection("my_custom_objects"))

This let developers build their own organization scheme for domain-specific graph pieces.

Why They Matter Less in TensorFlow 2

TensorFlow 2 defaults to eager execution and object-oriented Keras workflows. In that world, graph collections are much less central because state is usually held by Python objects, layers, models, and explicit attributes rather than by a giant global graph registry.

So if you are reading older TensorFlow 1 code, graph collections are important. If you are writing modern TensorFlow 2 code, you will usually solve the same organizational problem through model objects and explicit Python structure instead.

Think of Them as Graph Metadata

A good mental model is that collections were a way to attach metadata and reusable lookup points to a graph. Instead of asking "where did this loss tensor come from," the training code could ask the graph for everything in the losses collection.

That pattern made static-graph programming more manageable, even though it now feels less natural in eager execution.

Common Pitfalls

• Treating graph collections as a core TensorFlow 2 concept when they are mainly associated with TensorFlow 1 graph mode.
• Adding objects to a collection and then forgetting that retrieval depends on the active graph context.
• Assuming collections replace clear code structure rather than support it.
• Reading old TensorFlow examples without noticing they rely on compat.v1 behavior.
• Mixing eager-execution expectations with graph-collection APIs and getting confused by the programming model mismatch.

Summary

• Graph collections were a TensorFlow 1 mechanism for organizing graph elements by category.
• They helped large static graphs track losses, variables, summaries, and custom objects.
• Built-in collection keys handled common framework needs, and custom collections handled project-specific ones.
• They are far less central in modern TensorFlow 2 eager workflows.
• Their real purpose was to make static-graph programs easier to structure and query.