Step 5: learning while recognizing, asking only when unsure
The step 5 establishes a loop between recognition and learning, marking the first instance where the system learns about composite objects while simultaneously identifying them. I consider this—along with the initial step of perceiving the object as a whole—to be the most critical components of this framework. Once this loop is in place, the system can autonomously fill in gaps in its knowledge and learn about previously unseen composite objects. The recognition accuracy approaches that of a system that already knows the true identities of the objects; throughout the entire process, the system only queried an external source for the correct identity once (in the experiment, this was handled by a program providing the ground truth, effectively simulating the presence of a teacher).
|
After first learning (start) |
With the loop |
Filled with true identities (reference) |
| Training set, recognized correctly (39 episodes) |
30 (77%) |
35 (90%) |
36 (92%) |
| Test set, recognized correctly (30 episodes, not in the loop) |
— |
28 (93%) |
29 (97%) |
| Two never-seen composites, recognized after being learned (6 episodes) |
0 |
4 |
not learned |
| Identities asked from outside |
— |
1 in the whole batch |
one for every write |
The key to successful integration lies in the system’s ability to determine an object’s identity autonomously. Previously, when an object wasn’t correctly identified—often because its data record was incomplete—its identity had to be manually provided from an external source for each instance. Furthermore, any composite encountered for the first time was simply labeled as “new,” with no mechanism to recognize it upon subsequent encounters. Now, the system evaluates each object three poses and determines its identity based on a majority vote. If the object is identified as one already present in the library, the current observations are used to fill in any missing data in its existing record; if it is deemed new, a fresh record is created. It is important to note that the part library itself remains unchanged during this process: the system learns the record for the composite , but individual components that have not been seen before are not yet added to the part library as standalone entries. In the initial library, 13 out of 23 records had gaps; 7 of these were in the training batch. After a full cycle of iterations, all gaps were successfully filled—with zero errors and no redundant records created.
The trade-off is that learning new tasks can impair performance on previously learned ones—an issue that still requires a solution. For instance, after the “Pyramid on Cube” task was mastered, the new record was added to the candidate list; however, this resulted in a reduction of one episode for training and two episodes for testing.
Allowing the system to perform its own “gap-filling” carries a major risk: it might misidentify an object and then record data based on that error. To prevent this, a two-layered safeguard is in place: multiple verification checks are conducted before any data is written, and if an error is detected, the entire batch of entries can be retracted. In an early version, a pyramid-like structure atop a cube was confidently misidentified as a cone atop a cube; this passed a close-up visual inspection, and the data was subsequently recorded under the “cone” category.The two-layered check works as follows: if the observed surface orientation fails to match the recorded data (e.g., multiple flat planes mapped to a single curved surface), that specific entry is invalidated; furthermore, if the existing record is already complete, no additional data is added. The retraction mechanism functions by grouping each set of entries into a “batch.” When the object is re-examined, the system checks whether the points in that batch align with the current observations. In the case of the misidentified cone, for instance, half of the recorded points were visible but never matched the actual surface, while only about a quarter were correctly mapped. By deleting the entire batch, the system removes the erroneous data, leaving behind only the original, accurate points. Since the incorrectly recorded points are often just a few millimeters away from the actual surface—making it impossible to distinguish them on an individual, point-by-point basis—the only viable solution is to retract the entire batch.
There is no need to verify the identity after every single entry; I only ask for clarification when the system itself is uncertain. This approach yields the same results while cutting the total time by more than half. Previously, I would perform a spot check against the ground truth for potentially confusing entries every single time—a process that accounted for over half the total duration, yet never once revealed a regression across 50 iterations. I initially considered providing feedback only when an error occurred, but that would effectively mean having someone scrutinize every single response. Now, I only intervene when the system cannot reach a confident consensus from three episodes—and even then, only after a closer manual review fails to resolve the ambiguity. If the answer exists in the database, it is retrieved and added as usual; if it is missing, it is labeled as “new,” and a fresh record is created. Since replacing the spot-check routine, the results have remained consistent across every batch, and the total processing time has dropped from 8 hours and 13 minutes to 3 hours and 42 minutes—further optimized to 2 hours and 24 minutes. In the entire batch, the only instance requiring manual intervention involved an entry—“pyramid”—that was flagged during the initial screening.
Loop can bridge some gaps, but it cannot compensate for “thin” initial learning—that is, when the recorded data is too sparse. In the first step, relying solely on overall shape for ranking can cause the true object to be discarded. By halving the angular range of the initial observation—reducing the time required from 75 seconds to 36 seconds—I ended up with less than half the recorded data points, mostly confined to a single side. Consequently, the right number of training batch dropped from 35 to 18, with two errors occurring during the process. Since the observation spans a full circle, most of it falls outside the scope of these “thin” records; instead, the data appears more similar to other records that happen to share the same component and are well-represented on that specific side. The number of instances where the true object ranked first fell from 29 out of 39 to 18. This is how a bolt ends up being misidentified as a block atop a cylinder—a result that is also reflected in the observation data (Figure 1).
Looking back at the two ideas at the end of post 3, a small amount of feedback has worked out, and learning roughly at first hasn’t yet. It is enough to give feedback only when the system itself is unsure, but it won’t ask about a mistake it is confident in: the pentagonal-prism rod was recognized as the bolt in all three episodes, and it was stopped only because the bolt’s record happened to be complete already. Learning roughly has to wait until matching by whole shape alone can tolerate incomplete records; people can recognize things from a rough impression, and the system can’t do that yet.
Looking back, the two ideas mentioned at the end of the third post have been partially validated—though the concept of “learning just the gist” hasn’t quite panned out yet. The system currently triggers a request for feedback only when it’s uncertain; it won’t ask for clarification regarding errors it feels “confident” about. For instance, it misidentified a pentagonal-prism rod as a standard bolt across three episodes—a mistake that was only caught because the entry for “bolt” happened to be complete. To truly “learn the gist,” the system would need to be able to tolerate incomplete records by relying on overall shape matching—a capability it currently lacks, unlike humans, who can easily recognize objects based on a rough impression.